Behind the pixels
VictoriaO 06000145NY Tags:  graphicdesign careerday graphics highschoolers 5 Comments 1,487 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:  guestblogger features top11 top stephanierichardson graphics 6 Comments 1,994 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:  top10 developerworks feature graphics top favorite 3 Comments 2,178 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:  developerworks photo graphics opinion question author 7 Comments 2,471 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:  bueller color illustrations dropshadows graphics dosdon't captions callouts 1 Comment 1,641 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.
"...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.
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.
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.
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.