So it’s been asked, more than a few times… How do you come up with a feature graphic? I’m not exactly sure how to explain it. It’s like explaining how to ride a bike to someone who has never ridden a bike before.
So to show you guys what we’re up against, I’m going to, probably for the next few weeks, pick a blurb from of our featured content, post it and I want you to read it and then tell me what keyword(s) pop out at you that could inspire a creative feature graphic. Then, next week, I will post the feature graphic that was created with a few words on why that word(s) popped out to me/us.
How does that sound? Like fun? It will be interesting to see what you guys see that I didn’t…
This weeks blurb is…
“This article describes how you can use a user exit to extend Optim Performance Manager to integrate DB2 for Linux, UNIX, and Windows database monitoring with enterprise monitoring
systems, using the Simple Network Management Protocol (SNMP) for system and network monitoring. The user exit is a simple general purpose mechanism that can be
configured to call any executable program making it possible for you to use DB2 database performance alerts in a wide variety of ways.”
Not sure if y'all are aware, but IBM is pushing for us (IBMers) to use Lotus Symphony these days, saying that we have our our version of a word processor, spreadsheet and presentation software, and we should use it. Or as an executive said "drink our own champange". hmph. ANYWAYS.
First things first, Symphony is NOT Word. Will never BE Word, so you should stop expecting to BE Word. It's a word processor and can string characters together to form words, sentences, paragraphs. In that essence, Symphony does it's job.
But what if you need it to do something that Word does easily, intuitively? Like extract images from a doc file?
I ran into this scenario as our newest addition to our team did not have the Office suite installed and was working with Symphony. developerWorks offers up a Word document template for our authors that are not comfortable working in XML code. When the author use this file, they also insert their images in their document. They submit it to the editors, the editors submit it to us to figure out how to extract them.
Normally, if we were working with Word, we would simply save the Word doc as an HTML file, which would extract the images and we would move along. This time wasn't normal, this time our new addition would be trying to figure out a way to extract them from Symphony.
Symphony doesn't have a "save for web" option straight out of the box - did you know that? I didn't until I opened it and tried to work with it.
What you need is a plugin. I found it! Here
! And the instructions on how to install a plugin
in Symphony as well. No point in you trying to find it, when it's already been found.
Once installed you will see a button at the top that will start the process on converting your document to html.
Click the document button that has a globe on it.
Navigate to the location of the document file you want to covert to html, then click Ok.
It will then convet your doc file to html, extract the images in a png format and put them in a subdirectory called html. This html directory will be housed in the same directory as the source file.
It's really very simple, once you get it figured out, found, and installed.
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." [1
] 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" [2
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 [3
] or Color Scheme Designer 3 [4
] 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 [5
] 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!
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.
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.
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
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
Here is one... messing with lighting to emphasize plans
within a framework.
One of the perks of being the team lead, you can pass on the torch of blogging every now and then.
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!
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
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?
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.
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?
Yes - they are interesting but at the same time they are distracting and take away from the larger message of the image.
Why didn't I use a dark background and keep the white text?
Where that might also have a high level of contrast, we prefer to use black text on a light color of background. If you took the time to look at ALL the graphics in the 40,000 pieces of content on developerWorks, I'm sure you will find the occasion where we did just that, but 99.995% of the time, we use black. Readability and contrast is important!
Other things to avoid in your artwork, besides dark backgrounds, white, italicized text, and gradients...
Just because the software you're using to capture your screen HAS these effects, IT DOES NOT mean they MUST be used. As your mother would say - if all your friends jumped off a bridge, would you?
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):
- Use lower-case letters for file names - UNIX and Mac systems are capital letter sensitive so Image001 isn't the same file name as image001.
- Don't use spaces to separate words in a file name - Web servers interpret a space as %20, and will look for files with the %20 in the file name not a space and will cause problems on servers running UNIX or Linux.
- If you need to separate words in the file name, use a hyphen (-). Why a hypen and not an underscore? Apparently, it's because what Google expects. And we should all do what Google expects - right? Don't believe me? Here's what the GoogleGuy said on April 22, 2004 in the webmasterworld.com forum:
"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. "
I like that last line - keep it simple...and he IS the GoogleGuy.
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.