Tuesday, December 7, 2010

W3C Mobile Web Best Practices and HAT-Based Mobile – Part 11

A recommendation regarding graphics…

25. [LARGE GRAPHICS] – Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.

Whether to show graphics has always been a design issue in online help/doc, but one graphics issue that hasn’t been a problem until now is size. Desktop and laptop displays are large enough to show all but the largest graphics; the few that were too large usually needed just minimal scrolling. This ease of use often leads authors to add graphics with abandon. However…

Mobile device screens, except perhaps those on iPads, are so tiny that all but the smallest graphics require scrolling. And there doesn’t seem to be any good technical solution; the solution is information management – re-examine our projects to see if the graphics are really necessary and:

• If a graphic is not necessary, delete it.

• If a graphic is necessary, try to crop it to eliminate extraneous information and focus on just the salient portion.

• If the entire graphic is necessary, see if it can be scaled down.

• If scaling fails because the result is too small to read, accept the idea that some content just may not fit your design but still has to be included because the content is more important than the design.

• If a graphic works on large-screen devices and is nice to have, but causes design and usability problems on mobile devices, you can use conditionality to flag and exclude that graphic from mobile outputs. This is just one more way to use the conditionality feature in our help authoring tools.

MadCap Flare does offer one partial technical solution – the thumbnail attribute for the img tag. This feature lets authors display a graphic as a thumbnail until viewers click on or hover over the image, at which point it expands to a pre-defined size. It’s a nice way to insert graphics in topics but minimize their space requirements until viewers want to see them. However, the hover or popup display effect converts to a jump link in Flare’s mobile output, presumably because MadCap could not be sure if a particular mobile device supported hover or popup – presumably none did at the time – and so converted the thumbnail display effect to a safe, regular jump link.

• If you must include an entire, large graphic, you might use image maps to link areas of the graphic to other pages that offer more detail. But many mobile devices don’t support image maps. Those that do may not offer any way to reach a hotspot except by using the up, down, left, or right movement function. This type of movement works but is tedious if you need to reach a hotspot far down on a hotspot-rich image map.

• It is also possible to eliminate the whole too-large-graphic issue by simply including the graphic at whatever size is necessary and zooming the display. The problem with this approach, however, is that it re-introduces horizontal and vertical scrolling.

(I’ve often wondered why virtual reality glasses never took off since they solve the whole problem of limited screen size. But they haven’t.)

So the best way to deal with large graphics on mobile devices is to re-evaluate the content to see if those graphics, or any graphics, are really needed, get rid of those that aren’t, modify those that are, and accept the result. This may take a lot of work in large projects. But bear in mind that if you’re going to output your online help/doc to mobile, you may be doing so many other “clean-up” steps, such as eliminating hard returns between paragraphs or changing CSS size settings to relative units, that re-evaluating graphics may be just one more task in the shift to mobile.

More to come…

No comments: