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

Four separate but closely related recommendations regarding any text entry…

5. [URIs] – Keep the URIs of site entry points short.

54. [MINIMIZE KEYSTROKES] – Keep the number of keystrokes to a minimum.

55. [AVOID FREE TEXT] – Avoid free text entry where possible.

56. [PROVIDE DETAULTS] – Provide pre-selected default values where possible.

The gist of these points is that it’s hard to type on a mobile device keyboard, whether real or virtual. Mobile device users text like mad so it’s certainly possible, but if you have big hands or are in unstable environments, you’re likely to have problems typing. This is true especially where accuracy is important, such as typing URLs as opposed to text. (Speaking from experience with my latest smartphone, a Samsung Captivate with a large virtual keyboard, I still have to tap the keys with a fingernail and watch what I type very carefully.)

What this suggests is eliminating any free text entry if possible, and minimizing the rest. More specifically, with regard to the four points above…

Minimize the length of any URI that viewers have to type. The W3C recommends setting up any target web sites so that viewers can access them without having to type a sub-domain as part of the URI. For example, rather than requiring users to type this:

http://www.example.org/index.html

Let them type:

http://example.org

The “www.’ portion isn’t hard, and many mobile device keyboards have pre-set “www.” keys anyway. It’s more the length of what follows the www, such as:

http://www.economist.com/node/17722664?story_id=17722664

One easy, albeit tedious step, is to run URLs through a URL compressor like TinyURL, www.tinyurl.com. For example, it compressed the long and hard-to-type URL above from 56 characters to 26, as shown below:

http://tinyurl.com/28hzyj6

It’s still no treat to type, but there less of it. And if you can replace the typing of URIs with pre-defined links, so much the better.

More to come…

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…