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

Continuing the previous post, here’s the next recommendation…

22. [SCROLLING] – Limit scrolling to one direction, unless secondary scrolling cannot be avoided.

The screens on which we typically display help are large enough to fit almost any graphic or table without forcing users to scroll horizontally as well as vertically. When horizontal (“secondary”) scrolling is needed, it’s rare enough that we can excuse it as an unfortunate exception from our design.

It’s not that simple when we single-source help projects to mobile devices. Mobile device screens are so small that almost any graphic or table might need horizontal scrolling. This is okay technically, but it reduces usability. How to deal with this? Four ideas:

1. Accept it. That wide graphic or table may be necessary to convey the information.

2. Modify it. For a graphic, we may be able to crop out and display small sections of the graphic rather than the whole thing. For a table, we might be able to restructure it in order to narrow it. But modification is iffy, since it runs the risk of losing or confusing the original meaning of the material.

3. Conditionalize it. You may decide that you can live without the graphic or table in mobile output, or that you have to live without it because you can’t modify it to fit on a mobile device screen. You might define a condition called “mobile”, apply it to the graphic or table, and exclude anything conditionalized as “mobile” when you generate the output.

4. Define its size in relative instead of absolute units. Replace points, pixels, or other absolute size units with relative units like % or ems, among others. For example, you might change a graphic’s width from 180 pixels, which may add horizontal scrolling, to 100%. This says that the graphic’s width is 100% of the available space in the window, no matter what the device, and leaves it up to the browser to figure out exactly what that is, including on a mobile device. This approach works but has several quirks.

• It’s easy to shrink a graphic to fit into the space of a mobile device screen but the result may be too small to read. In that case, you might have to conditionalize it out after all. Ditto for tables.

• The graphic may show quirky behavior when inserted into a table and output to ePub format. This happened with an output from a RoboHelp project. I don’t know whether the problem was in the ePub standard itself, the RoboHelp converter, or my project specifically. To be investigated…

More to come…