- Review the developerWorks author guidelines.
- Use the content submission form to propose your idea to a developerWorks editor.
- A developerWorks editor will contact you, and if your idea is approved, you'll get further instructions on how to proceed with your content.
- Return to this article for advice on developing effective graphics for your content and eliminating time-consuming redraws.
The tips and instructions here can help you produce graphics that closely resemble the final published version. Prior to publication on the developerWorks site, all graphics you submit will be reviewed, revised, or returned to you for rework as needed by the developerWorks graphics design team.
Questions? Contact graphic designer Anna Gilbert.
Step 1. Select the types of graphics that will enhance your content
Graphics that will enhance your content include technical figures, screen captures, and in some cases, rich media files. Your developerWorks editor can help you determine what sorts of graphics will enhance your content. Here are some samples:
Figure 1. Technical figure
Figure 2. Screen capture
Figure 3. Technical figure merged with screen captures
Figure 4. Author photograph
Rich media files include audio, Flash, animated images, and video. developerWorks has a separate set of standards for these file types. Please contact your editor to discuss including rich media files in your content.
Step 2. Follow the 9 general guidelines for all types of graphics
- 1. Necessary?
- Graphics are used to explain or enhance the messages of the content. They should not be underused or overused. Think about how the reader will use the material. For example, if you want to include some code that readers can use in their applications, provide a code listing that readers can cut and paste into their applications, rather than a screen capture, which does not support cutting and pasting of code.
- 2. Appropriate for a worldwide audience?
- Avoid visual elements that are meaningful only to a particular geography or that could be construed as controversial. For example, don't use holiday symbols, religious symbols, hand gestures/images, mailboxes, country-specific flags and maps, jets or airplanes, or any kind of weapons-related symbols.
- 3. Readable?
- All graphics should be legible.
- 4. Accessible?
- For readers who are blind or vision challenged, text readers can read text, but images are another story. To make images accessible to readers who are vision challenged, be sure to include text before or after the image to describe the image. Also provide a short description of the image in the "alt" attribute of the <img> tag. Do not create images from tables or rely too heavily on text contained in an image. And avoid using color in an image to convey meaning. See the examples of these accessibility errors in images. To learn more about Web content accessibility, skim the Web Content Accessibility Guidelines 2.0 for tips and techniques.
- 5. No captions, borders, drop shadows, or numbered callouts?
- Please don't include captions, borders, drop shadows, or numbered callouts.
- 6. Web-safe colors?
- If you're using colors in your graphics, please select the colors from the developerWorks Web-safe color palette, which includes the RGB percentages so you can easily replicate them.
- 7. Proper width and height?
- In published content, images should not exceed 850
pixels in width and 800 pixels in height at 72 ppi (pixels per
inch), standard optimization for the Internet.
Make your image or screen capture as large as needed to be legible. If your graphic is less than 850 pixels wide, that's fine. If your graphic must exceed 850 pixels to be legible, submit the original image at the large size, and the graphics design team will resize it to avoid distortion.
- 8. Right format?
- These formats are ideal: jpg, gif, and png. If you wish to use other formats, check with graphic designer Anna Gilbert.
- 9. Proper file names?
- Keep file names short (less than 20 alphanumeric characters is ideal) and lower-cased (for example, figure1.gif and screen1.gif). Avoid symbols and spaces.
Avoiding accessibility errors
People who are blind or vision challenged rely on screen reader applications to hear the text-based contents of a web page. Tabular information presented as images—instead of as XML-coded elements (<tables>)—are inaccessible. If a table is presented as an image, the screen reader cannot read the content contained in the table image. It is always better to code a table using XML elements, because screen readers can read the text in the table.
Figure 5 shows a table presented as an inaccessible image.
Figure 5. Example of an inaccessible table presented as an image
There is another accessibility error with Figure 5. Color used in the image adds meaning to the content. Because the interpretation of color is dependent on vision, the representation of color has no meaning to someone who is blind or has limited vision. Furthermore, references to color can also be a challenge to people who are color-blind.
Figure 6 is an example of an image that uses color, but the color does not add meaning to the image or the content contained within the image.
Figure 6. Example of an image using color where color has no special meaning
All images must have a meaningful "alt" attribute on the <img> tag. The "alt" attribute is important for two reasons. First, it is what the screen reader reads when it encounters an image. Therefore, meaningful text for the "alt" attribute is critical for the vision-challenged person to understand what the image is and how it plays a role contextually. Second, images that do not contain "alt" content, or contain inadequate "alt" content, are considered inaccessible.
Figure 7 contains inadequate "alt" content. Notice that the "alt" content is viewable when you mouse over the image.
Figure 7. Example of an image with inadequate "alt" content
The image's "alt" content is inadequate in describing the image's purpose. "Image1" says nothing about what is contained in the image or what its purpose is within the web page. Though the presence of content within the "alt" attribute may satisfy a screen reader application (such as JAWS), non-descriptive text (such as Image1) is still considered inaccessible.
Figure 8 is an example of the same image with appropriate "alt" content being displayed.
Figure 8. Example of an image with appropriate "alt" content
In Figure 8, the "alt" content more clearly describes the image and its purpose.
Including adequate "alt" content is just one part of ensuring that images in the content meet accessibility standards. The contextual relationship between an image and the surrounding content is also vitally important for meeting accessibility standards.
Comments throughout the XML templates guide you in meeting accessibility standards for your content and images.
Creating technical figures
Beyond the 9 general guidelines for all types of graphics, these guidelines and tips are specific to technical figures.
Programs you can use
You can create your technical figures using Microsoft® Paint, Adobe Illustrator, Adobe Photoshop, Microsoft Word, and other graphics programs.
The most effective technical figures are simple, straightforward, and not heavily detailed:
- Arrows should use one common style.
- Lines should be one-point thick.
Figure 9. Examples of approved arrows and 1-point lines
- Shapes should have a one-pixel black border.
- Any text in the graphic, such as labels or unnumbered callouts,
- Use 12-point Arial font
- Use bold highlighting as needed for emphasis, but minimally
- Avoid italic highlighting, as it's hard to read
- Use sentence-style capitalization
- Use approved abbreviations and product names (check with your editor)
The graphic design team may adjust the text style in the graphic as needed.
- Include common images as needed from the collection below.
- Do not use drop shadows, gradients, or three-dimensional images.
- Do not include captions or image titles within the image.
- Do not include a border around the image.
An assortment of standard computer images (such as laptops, mobile phones, PDAs, and so on) are owned by the graphics design team (to avoid copyright issues). For consistency and simplicity, you can use any of these common images in your technical figures. To add them to your figure, download the zip file of all images, select the image you want, and insert it into your graphics application.
Figure 10. Examples of common images
Don’t see the image you need? Feel free to ask the graphics team—we have many other standard images and might have what you’re looking for. You can also use one of your own, but please keep the style simple as in the images shown here.
Creating screen captures
Beyond the 9 general guidelines for all types of graphics, these guidelines and tips are specific to screen captures.
The most important considerations for screen captures are size, file format, and available tools.
Sizing your screen capture
Try to take the smallest screen capture possible, while still legible, by adjusting the size of your browser window to include just the information you need to capture. Don't alter the original screen capture, even if it exceeds the width specified in the 9 general guidelines for all types of graphics. Simply submit the original source file when you submit your content draft; the screen capture will be resized as needed.
File formats for screen captures
The best formats for saving your screen captures are jpg, gif, or png because they are optimized for high-contrast graphics, such as application interfaces. Avoid compressed formats, such as the 24-bit bmp and the tif formats.
Tools for screen captures
Screen-capture tools are available for most software platforms. For example, SnagIt is a popular Windows®-based tool (see the link in Resources), and the built-in screen capture tools specific to your platform are fine to use also. For example, the tools that come with Microsoft® Windows, Apple Macintosh, and Linux® are sufficient for screen captures. (If you need to capture something other than a screen, such as the cursor or pointer, you might need another application.) Specific advice for flawless screen captures follows.
Optimizing your screen capture
Remove all toolbars prior to taking the screen capture. (For example, on a PC, select View > Toolbars > Unselect all toolbars. On a Mac, select View > Collapse Toolbars.)
Windows users can use SnagIt for screen captures (see the link in Resources). We recommend these settings to get the best results—and to ensure your graphics will match developerWorks' style and minimize rework:
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:
Figure 11. SnagIt settings for arrow style
- Emphasis areas
In 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:
Figure 12. SnagIt settings for emphasis areas
In the SnagIt Editor, select Paint Tools > Callout Tool. For Category, select Arrows or Balloons. For this example we're using callout balloons, but the same settings apply to callout arrows. Set Opacity to 100 (the default), and uncheck Drop shadow:
Figure 13. SnagIt settings for callouts
For callout color, select gray (R:192,G:192,B:192) for the foreground color (see Figure 14) and white (R:255,G:255,B:255) for the background color. (And for text in the callout, select black (R:0,G:0,B:0), Arial, 12 pt. font.)
Figure 14. SnagIt settings for callout color
Using Windows screen-capture tools
Windows offers two different key combinations to send screen captures to the clipboard. Using one of the following key combinations, you can paste the image into Microsoft Paint or another graphics program, and then save it:
Table 1. Capturing screens on Windows
|Alt+PrtSc (Alt + PrintScreen)||Captures the active window, including the window borders|
|PrtSc (PrintScreen)||Captures the entire screen display|
If you need to capture a menu display, you can left-click your mouse while pressing Alt+PrtSc or PrtSc. Different applications tend to treat these key combinations differently, so you'll need to try both key combinations.
Using Macintosh screen-capture tools
Three different key combinations can capture screens:
Table 2. Capturing screens on Macintosh
|CMD+SHIFT+3||Captures the entire screen|
|CMD+SHIFT+4||Allows you to drag and select an area for capture|
|CMD+SHIFT+4, then press the space bar||Captures a window, menu bar, dock, or other area (position the pointer so your selected area is highlighted, then click the mouse)|
Save screen shots as PDF files on the desktop or paste them into a graphics application or document.
The Mac OS X screen capture program, Grab, is also available on OSX and up.
Using Linux screen-capture tools
Most Linux distributions have several screen-capture tools. Graphical tools including the GIMP (GNU Image Manipulation Program) and ksnapshot. Command-line tools include the import command from ImageMagick.
With the GIMP, use the File > Acquire > Screen Shot... dialog to capture either a single window or the whole screen. Similarly, you may use ksnapshot to capture a single window or the whole screen. Both of these GUI programs allow you to set a delay after requesting the capture so you can get focus on the right window or open menus.
With ksnapshot, remember to save the capture after grabbing it. If you're
import command from ImageMagick, you
can combine it with the
sleep command to give
you a delay for window setup.
Table 3. Capturing screens on Linux
|sleep 5; import -frame snapshot1.png||Waits 5 seconds, then captures a window (including its frame) that you click with your mouse|
|sleep 7; import -frame -window 0x1e00079 snapshot2.png||Waits 7 seconds, then captures the window with id 0x1e00079. Use
|sleep 3; import -window root snapshot3.png||Waits 3 seconds, then captures the entire screen|
To check the sizes of your images, try the
identify command from ImageMagick.
Creating an author photograph
If you want your picture included at the conclusion of your content, please submit an unretouched digital photograph. A photo of you facing the camera, from the chest up, of vertical orientation, and taken against a light or white solid background is ideal. The picture should be at least 200 x 250 pixels, so there is room to adjust. Please name your file with your first and last name.
Step 3. Submit your graphics to developerWorks
When you submit the final draft of your content to your developerWorks editor, submit the graphics files also. Follow these tips:
- Do not alter your image source files in any way (including resizing).
- If you have used a word-processing program to develop your content and inserted the graphics, such as screen captures, into the document file, please deliver the image source files separately from the document file.
- If the total size of the source files you're attaching in an e-mail exceeds 10 MB, please save them in a zip/stuffit/infozip file before e-mailing.
- Include any special instructions regarding cropping, labeling, colors, or redrawing. If your graphics should not be altered (it's computer- or program-generated with UML, for example), let us know.
- If you want to merge different types of images (such as adding photographs or screen captures to a technical figure as shown in Figure 3, please submit all original screen captures and photographs, as well as the altered image, so it can be revised as necessary while still retaining legibility.
After your graphics are delivered
Your developerWorks editor will review all images you submit and then forward them to the graphics design team. The graphics design team may recolor, resize, reformat, crop, revise, or return the images as appropriate. It typically takes 5 to 7 days to complete this process.
The developerWorks web-safe color palette is shown in Figure 8. If a color needs to be altered, the graphic designer will attempt to match it as closely as possible to the original.
Figure 15. The developerWorks color palette
developerWorks wants to get your vital content out to its readers as quickly as possible! If you have any questions on illustrating your content, please contact graphic designer Anna Gilbert. We look forward to working with you!
|Common computer images||techarticons.zip||109KB|
- "Authoring with the developerWorks XML templates" (developerWorks, April 2010): Begin your developerWorks authoring experience with our complete instructions and downloadable authoring package.
- "Authoring with the developerWorks Word and Writer templates" (developerWorks, April 2010): If, instead of using the XML templates, you prefer to compose your content in Microsoft Word or OpenOffice.org Writer, we also offer Word and Writer templates for your use.
- developerWorks author guidelines and editorial policy: Learn more about our editorial policy and peek at each developerWorks editor's content wish list.
- developerWorks on-demand demos: Watch demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
- developerWorks on Twitter: Follow us.
Get products and technologies
- SnagIt: Purchase or download a trial copy of SnagIt from TechSmith. With it, you can capture anything on your screen, such as an entire screen, a section of a screen, or even a scrolling screen.
- GIMP and ImageMagick: These graphical programs are included on most Linux distributions and are available for other platforms as well, including Microsoft Windows and Apple Macintosh.
- Evaluate IBM products: Download a product trial, try a product online, or use a product in a cloud environment.
- Content submission form: Submit an article idea to developerWorks, and start talking with a developerWorks editor. Check to see what content is most desired in the content wish list.
- developerWorks editor contact info: If you have questions, contact the editor for the technology or product zone you're interested in.
- developerWorks Community: Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.