Behind the pixels
My name is Victoria Ovens, and I'm the graphics team lead for developerWorks, and this group and blog is a way for you to peek "behind the pixels" of devleoperWorks and ask any questions that you may have. I can't say I'm going to ONLY talk about graphics on developerWorks, but that is the main focus. So yes - in the intro paragraph, I'm giving myself permission to digress, and will probably do so regularly.
My plans are to update this blog weekly on Wednesdays. So here I am, setting expectations early and hoping I meet them. Nothing is worse, in my opinion, to have a blog, blog a few times, and then.... nothing.
SO - with intros out of the way and expectations set, I hope to educate, occasionally entertain, and ultimately try to make developerWorks better, one pixel at a time.
This blog entry will be a multi part one, because there is too much to be said on the topic to do it in one concise, brief blog posting. No need to drag it on longer than need be, right? Right.
So this week's Part 1 topic is - SCREEN CAPTURES (a.k.a. screen caps) - determining what's really important on your screen.
I've been team lead for roughly two years, but I've been working on the graphics team since March 23, 2006 (a pivotal moment in my working life) - so needless to say, since then I've seen A LOT of screen caps. And I've seen some really great ones and ones... yeah... notsomuch.
So here I am, hoping to educate you bit by bit on how to create exceptional screen caps.
When you get ready to make a screen cap, ask yourself a couple of questions as you look at the window on the screen:
1 - Is it relevant?
Do the people who are reading your article/tutorial REALLY need to see your tool bar? Tabs in your browser on unrelated topics? A partially drafted e-mail to your mother or signifcant other in the background? The answer is simple - NO
Our readers aren't THAT interested in what's going on in your background for you to include it in the screen cap. So make sure you only run that program/browser, or only screen cap the one you mean to without the party going on behind it.
2 - How much of the screen is ABSOLUTELY necessary to convey your message?
Do your readers really need to see the bottom right hand side of the screen cap? What about all the empty white space?
Focus your screen cap on what you're... well... focusing on. If you capture your entire screen for one little icon, so you can then point six red arrows to it - that's too much information (as well as being inaccessible - which is a blog topic for another time)! Try to capture just the icon itself or even just the toolbar section with the icon highlighted. If it's an error message, capture just the error message window - not the error message window over the entire window. If it's the upper left hand side of the screen for the menu, then capture just the left-hand hand side of the screen for the menu; the rest of the window is irrelevent. Noticing a trend yet?
Keep your screen caps concise and focused. So much more information can be conveyed to your readers and they will spend less time visually editing out the extraneous pixels, if they don't get distracted in the meantime.
3 - How big is the screen cap?
So your screen capture is 1400 pixels wide x 800 pixels high. You've asked yourself, is all of this screen cap relevent? And you've answered - YES! You've also asked yourself - Is ALL of this screen ABSOLUTELY NECESSARY? And you've also answered yourself - YES! (amazingly enough). So you think you're good to go - don't you? Well guess what? YOU'RE WRONG! O_O
The dimensions that work within our templates (both article AND tutorials) are 580 pixels wide. ::does some quick math:: So you're 820 pixels OVER! So what can we do? As the graphics team, we can take this image and scale it to 905 pixels wide and include it in a sidefile in your article. But you're still 495 pixels too big! Let me give you a visual here - since I'm a visual person and it makes sense, at least to me.
Your original image is 1400 x 800. Mythbusters style, we're going to scale this down to 1/3 scale, for the sakes of all our monitors - so it's now 400 x 229.
Now if we take that and try to cram it into 193 pixels (580/3 = 193.3333) - this is what we get.
Notice the difference in size? Look at how much of the image is lost! So we would be scaling your image to fit that - which means all legibility would be lost - and that's not good.
"But wait!" you say. "You mentioned something about a side file!!" I did... and this is what you would get...
So if you MUST go larger to convey your message in your graphic remember that developerWorks' max size is 905 pixels - and let the professionals handle the rest. :D
So after reading this rather lengthy blog post what have you learned today?
Make sure you focus your screen caps on what's relevant, and omit anything that isn't (this also includes your background). And remember - size matters when it comes to graphics.
Well - this is lovely. My blog post got eaten, and now I will try to recreate -
My husband and I were out digesting at Wal-mart after dinner (don't ask, it's just something we do, because we love the Wal-mart). And I came across this in the camping section...
Interesting, no? It's a folding aluminum table! We have one on our patio for our little Webster grill, but again, that's besides the point... look closer...
Do you see it now? The "Spanish Here" SHOULD ACTUALLY BE SPANISH!
Let this be a lesson - you should ALWAYS proof your work, doens't matter if it's graphics or not or even SPANISH or not, just proof it.
"...That which we call a rose by any othe rname would smell as sweet" - Wm. Shakespear "Romeo and Juliet"
Sorry for that throw back to 10th grade English. But I'm not talking roses, but files and file names to be more specific.
It occured to me, as I've been working over the last week with files that had names that seemed to be longer than "Atlas Shrugged"; people don't think much about their file names. File names are important, but not more important than what you're writing about. More than a word or three - it's too much.
Seriously - if your file name rivals the longest sentance in your content, has a noun, verb, AND a dangling participle, it's time to rethink your file name.
A few things to consider when you name your files (and this is good for all files, not just graphic files):
I like that last line - keep it simple...and he IS the GoogleGuy.
"Most people seem to prefer hyphens. If you use an underscore '_' character, then Google will combine the two words on either side into one word. So bla.com/kw1_kw2.html wouldn't show up by itself for kw1 or kw2. You'd have to search for kw1_kw2 as a query term to bring up that page. ... My rule of thumb is to keep it simple where you can. "
Let me give you some examples of what to do and not to do -
Don't use names like:
Dependencies between Requirement- and Logical Model for whole
Dependency between Requirement- and Logical Model for one Measure
Use names like:
See the difference? What if you were coding your article and you had to input
<heading refname="fig1" type="figure">Figure 1. Initial UML model with types and their properties</heading>
<img alt="Dependency between Requirement- and Logical Model for one Measure" height="208" src="Dependency between Requirement- and Logical Model for one Measure.jpg" width="571"/>
<heading refname="fig1" type="figure">Figure 1. Initial UML model with types and their properties</heading>
<img alt="Dependency between Requirement- and Logical Model for one Measure" height="208" src="model1.gif" width="571"/>
You could literally use the file name as the alt text for that image!
So to quote GoogleGuy one more time because it's so good - "keep it simple where you can" - especially in your file names.
VictoriaO 06000145NY Tags:  bueller illustrations color dropshadows graphics captions dosdon't callouts 1 Comment 1,630 Visits
I've been training a new graphics person for our little graphics team over the past two weeks, and during that time, I've told him that we take the artwork provided with the submitted content and extract every ounce of personality from it.
At developerWorks, we want our tech art and screen caps to look like they came from the economics teacher (Ben Stein) in "Ferris Bueller's Day Off"... Bueller?... Bueller?... Bueller? ::snicker:: One of the great movies of the 80's.
Why?, you ask. Simple - we like things...well... simple and legible.
Let me show you what I mean. The top image is the one that was provided by the author, the bottom is the one created by the graphics team (read - ME.).
Which one is more legible? Is there sufficient contrast from the background color and the font color?
These are important in technical illustrations - if your reader can't read or understand your illustration, the point of it is lost.
Why did I remove the gradients? Aren't they pretty and make it more visually interesting?
Why didn't I use a dark background and keep the white text?
Other things to avoid in your artwork, besides dark backgrounds, white, italicized text, and gradients...
If it's there, we will remove it and the drop shadow that goes with it. Period. And with my example, that would mean some of the text would be lost too - hope it wasn't important.
Which leads me on to my next point - DROP SHADOWS
I realize that some operating systems have a drop shadow built in and your screen shots might have that - it's fine, we'll just crop it out. Not a big deal. What is a big deal is when you have drop shadows all over your screen cap and under your arrows, your ellipses, rectangles, etc. It's distracting, especially when it goes over important bits of your screen cap.
Notice the difference between the two? While it's certainly cooler to have the effect, at developerWorks, in our content, we're not cool - remember - we're that economy teacher in Ferris Bueller's day off...
Like I said - NOT COOL. (We don't REALLY look like that, and we're all actually pretty interesting, once you get to know us, but that's besides the point.)
Call outs work the same way - use neutral colors (gray) for the balloon/box/cloud/arrow, black text, 12 pt font, and no drop shadows.
Captions are also not needed in your artwork, but rather they should be in your text. Captions will be removed from your artwork and coded in.
And finally - what happens if you have any of these things in your content?
Simple - they will get sent back to you, with a note from your editor basically stating that the graphics people are mean, cruel people and want you to remove the unwanted elements from the noted screen caps. Now the first part about us being mean and cruel might not be in the note, but asking for new screen caps will be.
Trust me, mean is when authors submit 140 screen caps that are 80% covered in drop shadows that need to be removed. Cruel is when you spend 3+ days removing those drop shadows and then vowing to never do that again - and I haven't.
VictoriaO 06000145NY Tags:  developerworks photo graphics opinion question author 7 Comments 2,457 Visits
In so many social media sites, you're given a opportunity to put a profile picture up on your profile, so you have a visual marker of who you are. We also like to do that with our content - we figure you put so much time and effort into your piece, you should have you picture next to it.
But here's the question that has me thinking... if you're an author and have a My developerWorks profile, would you want those pictures to be the same? Would that make you, as the author, more conscious of the picture you choose, because you would know they would be linked? Or would you not care?
As a reader, do you want to see a picture of the author? Or if it was a picture of the author's cat/dog/kid/whatever, would that matter? Would that make what you read have any less relevance or importance if it looked like a cat/dog/kid/whatever wrote it? Would you rather see a cat/dog/kid/whatever versus a default no profile picture?
Talk amongst yourselves. I'll give you a topic: Author photos, important or not. Discuss.
VictoriaO 06000145NY Tags:  top10 developerworks top graphics feature favorite 3 Comments 2,156 Visits
One of the comments from last weeks post made sparked something, and got me thinking about a few of my favorite feature graphics (Thanks Bob!). Now mind you, developerWorks has been around 9 years, and I've been with developerWorks going on 4 years.
A lot has been published in that time, and I can say that in our current content management system that we have over 3000 feature graphics, which doesn't even include the feature graphics created BEFORE we moved over to this content management system. Below you will find MY top 10, ones that I'm proud of because they're kinda' cool, at least to me.
I like to play on words when it comes to feature graphics - take a word and literally run with it, Derby plug-in, Linux on the half-shell, using UML to create SOA... fun ways to look at technical content!
The editor for the Linux zone always seems to have fun with his feature graphic suggestions, so his are some of my favorite. And any time you can set code on fire, at least graphically, you should. It just LOOKS cool.
Which feature graphics have you seen lately (or not) that have made you want to click on it and see what that article was all about?
VictoriaO 06000145NY Tags:  guestblogger features top top11 graphics stephanierichardson 6 Comments 1,979 Visits
Today's entry is done one of my team mates - STEPHANIE RICHARDSON.
Stephanie is a graduate of Iowa State University with a BFA in Graphic Design, minor in Entrepreneurial Studies, and an emphasis in Advertising, Marketing, and Psychology. She graduated in May of 2007 and joined our little graphics team! She was the lucky person to share an office with me, but unfortunately was moved half way across the country to sit in her home office and dream about the day she can come back. Apparently she's sick of the snow and ice, although it's not been much better here this winter!
Let's give a round of applause and see what are HER favorite feature graphics that she's created in her time here...
This one was one of my first features with dW - learning to play off of the 'keywords' of front end
Sometime i like to use layers of images to create a style and catch the viewers eye.
XML gives a lot of really great ideas for features that are always unique. It might be using a previously published image with a few tweaks to better fit the article, or combining all new ideas of images into one. The recycling bin image was created completely from scratch and is a great example of how the graphics team can execute keywords or even the editor's thought process if communicated well.
Here is one... messing with lighting to emphasize plans within a framework.
That's 11!One of the perks of being the team lead, you can pass on the torch of blogging every now and then. THANKS STEPHANIE!!!!
VictoriaO 06000145NY Tags:  graphicdesign graphics careerday highschoolers 5 Comments 1,475 Visits
Every year, about this time, a good friend and coworker of mine comes to me and says - you going to the career fair this year? And how can I tell Barb no? As much as I groan about it, it's kinda' fun - but after I've run through my spiel about a dozen times, I'm ready for a break.
A local high school has a career fair for sophomores and juniors. They get to miss class (this year it was Civics and English) to listen to various talks about the various jobs that are out there, to help them get an idea of what they want to do when they "grow up". I obviously was talking about graphic design, but we had editors, and web developers show up to talk about what it takes to put a site together - specifically our site, developerWorks, but there were also some generalities. Some of the kids are curious and ask questions, which is a lot more fun than the ones that are comatose - but what can you do?
Barb is great - she always has fun hats and lots of goodies. Can't wait 'til next year!
And that is why this blog post was late - I was catching up on my "homework" after a morning/afternoon of fun.
VictoriaO 06000145NY Tags:  captures caps howto drop dropshadows standards shadow screen screencaps cloud snagit specs 3 Comments 2,518 Visits
Not any more! This week has been a bit hectic - the launch of our cloud sitelet/zone (you should go check it out, by the way, AFTER you're done reading this blog entry), meetings out to wazoo - and part two in a four part lecture series that I attended yesterday. Needless to say, it didn't seem like a very productive day, but a lot ended up getting done. Just not this blog entry.
And I will digress from Cloud to this weeks topic - drop shadows.
I've seen an increased trend lately of drop shadows in our tech art, which is not a part of developerWorks' graphic style, period. There is no getting around this, and it's better to understand this upfront, so you can avoid such elements and turn in clean screen caps and get published in a timely manner. If you don't - we WILL send them back to you for recapture without drop shadows and will delay publication of your piece.
Why will we send them back to you? Because it's easier for you to recapture your screen shot than it is for us to spend all day removing them. Hopefully, while you're recapturing them, you think to yourself - I won't use drop shadows next time and avoid this rework. Maybe one of these days I will walk you through, step by step what we do to remove drop shadows, so you can see the time intense work that goes into it - maybe next week - but this week - I'm going to go over the simple settings that you will need if you're using a great little program called Snag-It to take your screen caps.
Snag-It is a screen capture program offered by TechSmith. I highly recommend it, because it's simple to use, intuitive, and does the job for a reasonable price. Now that I'm done pimpin' their software, we'll move on to what settings you'll use when enhancing your screen captures.
Say you want an arrow on your screen cap to point something out. Make your screen cap with SnagIt, and in the SnagIt Editor, select Paint Tools > Arrow Tool. Click the Style button, and select the first arrow. Set the Width to 1 and the Opacity to 100 (the default), check Antialias, and uncheck Drop shadow.
That last part is CRUCIAL - antialias will smooth out the pixels, making lines smooth instead of a jagged step look - and by UNCHECKING the drop shadow box - you will not run the chance of having drop shadows! BRILLIANT!
Let's continue on with our brilliance - what do you think?
Now say you want to emphasize an icon or other portion of your screen cap. Again, make your screen cap with SnagIt, and with the SnagIt Editor, select Paint Tools > Shape Tool. Select the shape you wish to use, preferably a rectangle or circle. Set the Width to 1, the Opacity to 100 (the default), check Antialias, and uncheck Drop shadow.
Noticing a trend here? Again, we checked the antialias box and UNCHECKED the drop shadow box.
I know, what we ask for is SO HARD, and we are INCREDIBLY demanding. /sarcasm
BUT with this nitpicky attention to detail, we've been able to bring you clear, readable graphics to accompany our content - which you seem to appreciate, since you keep on coming back and reading it.
So until next week, I wish you good productivity and excellent time management and will see if I can't eek some of both out for myself.
VictoriaO 06000145NY Tags:  questions constructive feedback critiscm smarter 5 Comments 2,200 Visits
Being a graphics person, you will come across people who have opinions. LOTS of opinions. Sometimes you ask for them, sometimes you don't. Helpful or not, everyone seems to have
one. The question is - what do you do with that information?
Opinion: The graphic needs to be smarter.
First thought: Riiiiiiiiight. Ok then.
If you're lucky, you're in the room when the opinion is given and you can ask open-ended questions to clarify their meaning. There is meaning there - where? - I don't know, but asking questions can get you to understand the meaning behind their statement. If you're not so lucky, then you have to use some powerful interpret-fu to figure out what they meant and move in that direction.
If you've gone through art school for 4.5 years, and sat through endless hours of "constructive criticism", your skin gets thicker over time and you can get some good feedback, as long as it's communicated properly and you're open to such constructive criticism.
How do you communicate such constructive critiscm properly? I try to follow these simple rules.
1. Look at the creation, and then ask yourself some questions to get your thoughts in order:
2. Hate it, love it, or meh - find SOMETHING nice to say about it - period. Even if it's the smallest of things, let that person know you've found something POSITIVE about their work.
3. Give CONSTRUCTIVE critiscm. This means, while being polite and helpful, you offer up the creator ways that you would improve their creation.
What not to say -
Say things like -
Statements like these, will make the creator, who is open to such constructive critiscm, think about things in a different way. Possibly explaining to you how it was meant to be interpreted,
opening the lines of communication, brainstorming, correcting the confusion, and -- hopefully -- producing a better end product.
Maybe for a future topic, I will go over the proper etiquette on recieving constructive critiscm, but in the mean time - I'm going to try to use some of my interpret-fu and figure out how to make a graphic, smarter.
You thought I was going to post yesterday, didn't you? lol FOOLED YA!
Anyway - my question of the day is this: What do you when you need inspiration? How do you keep those creative juices flowing?
Everyone is creative - just in different ways. Developers use coding to create creative solutions to a problem, where as designers use pixels, artists use paint, charcoal, crayons, markers to show their creativity. Creativity can be subtle or screaming loud. How I'm creative is different from how you're creative.
But at some point we all come to a screeching halt, and the creative juices stop flowing.
What do you do then?
Me? I stop. If I've iterated designs to the nth degree, I just stop with what I have, submit whatever I was working on for review, and wait to see what happens. The worse thing that can happen is that they don't like what I've done, and I'll have to start over. Not ideal, but something I can work with. Maybe they will come back with more CONSTRUCTIVE criticism or feedback and it will spark an idea and I can move forward, maybe they won't. Either way, I've given myself the most important thing to get the creative juices going - TIME.
Creativity is like a muscle - you need to exercise it to make it better; but like REAL muscles, there comes a time when you just can't do any more. You need a break, time for your muscles to recover from running 26 miles, biking 50 miles, or being creative for 3 days straight. Basically, it's your creative side telling you that your "creative muscle" need a break. You've been thinking too hard on this one thing and you need to focus on something else, watch tv, take a nap, do something analytical if you were being creative, or creative if you were being analytical. Take a walk outside, go get some ice cream, fish, have lunch - do SOMETHING that's no way related to what you were doing before. Just stop thinking about it.
My go to? I knit. After pushing pixels all day and some of the night - I want something tangible. A finished object that I can touch, feel and say - "I did this".
What do you do to give your creative muscle a break? How do you keep it toned?
Trying to string together words to get sentences, that will actually have some sort of meaning this week has been difficult. How? Not sure, but for once I've not had a lot going on that I've been wanting to comment on. Usually something comes up during the week that I feel the urge to comment on, and this week - NADA.
So digging deep - contrast popped out at me, which is a bit ironic because the contrast I'm speaking of is defined as the ratio of the luminance of the brightest color (white) to that of the darkest color (black).
Notice the difference in the flowers? Which ones look better, brighter, more inviting?
Now that I'm done showing off my Photoshop "skillz" - next week - more about contrast and why it's important with graphics.
I know last week I spoke briefly about contrast from a visual sense and how that effects an image, and draws a viewer in. In the course of doing that, I "discovered" there are different TYPES of color blindess. Under these types, there are underlying catagories "based on the number of primary hues needed to match a given sample in the visible spectrum."  So depending on the color blindness and the subcatagory of it, it will completely affect how an image will appear. The sub catagories are monochromacy, dichromacy, and anomlous trichromacy. I'm not going to go into the details on each, but rather the visual effects some of the subcatagories have on visuals - but if you're interested in more details, Google it.
This kind of blew my mind, because all that I've ever heard of is red-green and blue-yellow. So if you take a rainbow and how a normal person would see it, it would look like this:
If a person has no perception of red what so ever, which would be a type of dichromacy, and red would appear dark, almost like a dark brown:
If a person has no perception of green, it will also affect the ability to tell the difference in the red and green hues, which mean the yellow and blue pigments are the primary colors seen:
AND THEN if there is a total absence of blue pigment receptors the rainbow will look like this:
Fascinating stuff, isn't it? A bit mind boggling at the same time. But why is this important to consider, as a designer, as a developer? Because we put stuff on the web to be consumed, and we want it to be consumed by everyone and be accessible to everyone, and we can do that with contrast, "the percieved difference in colors that are in close proximity to each other" !
There are different ways to approach this. Some designers will start a design in black, white, and shades of gray. Others would use tools like graybit.com  or Color Scheme Designer 3  to make sure the color scheme would work. The latter sucked me in for a bit, as I played with it - good times.
I also tested some of our current feature graphics with Fujitsu ColorDoctor  to see how we've done with our contrast in the grayscale conversion, and I've noticed that we need to up the contrast on the background color, for some of them.
We've got a bit of work to do, but learning new (to me) stuff is fascinating!
*Image samples of the rainbows are from the wikipedia.com entry on color-blindness