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

The next recommendation, again in the order in which I’m getting to them…

6. [NAVBAR] – Provide only minimal navigation at the top of the page.

For years, help authors have used the “tri-pane” window created by Microsoft for HTML Help in 1997. This model, adapted for the web-oriented WebHelp model created by eHelp, original vendor of RoboHelp, in 1998, put the major navigation controls – TOC, index, and search – in a vertical pane at the left side of the help window. It added a horizontal toolbar for the nav function labels and custom functions, as shown below:

The problem with this model on mobile devices is that the tiny window can only show a tiny part of the screen; it can take many (irritating) horizontal and vertical scrolls to get past the toolbar and navigation controls to the actual content. What to do about this?

The W3C suggests “provide basic navigation… on the top of the page… secondary navigational element[s] may be placed at the bottom of the page if really needed… users should be able to see page content once the page has loaded without scrolling.”

This is a perfectly sound recommendation. However, when it comes to HAT-based online documentation or help created using tools like Flare or RoboHelp, the navigation options can use a lot of screen space even without the horizontal toolbar.

A solution implemented by Flare in WebHelp Mobile and RoboHelp in ePub is to revert to the old (pre-HTML) Windows Help model. This output had the content and navigation in separate, single-pane windows, only one of which could display at a time.

For example, start a WebHelp Mobile online document and the navigation pane displays. Select a topic, from the TOC for example, and the content pane replaces the navigation pane. ePub takes a similar approach on the devices I’ve seen. (This may be modifiable in the interface. It’s on my list of things to check.)

Some observations about this model:

• Users can only see content or navigation – not both simultaneously, unlike the tri-pane model that they may have become accustomed to over the years. This may take some getting used to. Not much, but people rarely expect “books” to change their format.

• Flare’s mobile output skin is more limited than its regular skins because there’s less screen space. This is important if you created custom navigation or other buttons for your regular WebHelp output only to find that there isn’t room for them in mobile. Ditto for a RoboHelp project that you output to ePub. (And ePub’s navigational interface is largely fixed.)

• Finally, an example of why you can’t just test your mobile output on emulators. If you output a RoboHelp project to ePub and test it on the ADE (Adobe Digital Editions) reader, you’ll find that ADE uses a left-right split screen model that shows the navigation features on the left and the content on the right. Open the same eBook on a physical device, however, and you’re back to single-pane mode. This may be modifiable through the ePub code, but the need for any custom coding makes the HAT-based output less convenient.

In summary, if you’ve stuck to the basic navigation offered by your HAT, you should be okay when you convert to mobile. But if you’ve created custom features on the navigation pane or toolbar, you may have to re-think your design when you go out to mobile.

More to come…