In the ‘90s and early ‘00s, products like Newton and standards like WAP and CE tried to get mobile computing into the mass market. They all failed due to shortcomings in technology, usability, and interoperability. Never mind largely silly content…
In the early ‘00s, to help give mobile computing another crack at the mass market, the W3C (WorldWide Web Consortium) began an effort called the MWI (Mobile Web Initiative) in order to set technical and best practice standards.
I've followed this effort closely for years – I’ve been working with, training on, and looking for markets for mobile since ’98 (thanks to Joe Welinske, who introduced me to Windows CE in '97) and was the STC’s (Society for Technical Communication) representative to the W3C from ’02 to ’05 so I had a dual interest. But the mobile mass market never went anywhere until Apple brought out the iPhone and sent the market skyrocketing.
A side effect of mobile’s skyrocketing in the mass market has been a slow but steady rise in interest in using mobile for tech comm. Until recently, creating content for mobile, in the form of apps, was so different from “true” tech comm and online help that there was little or no overlap. Tech writers had to do “apps” to get into the mobile space.
That’s changed in the last year, as two well-known help authoring tools (HATs), MadCap Flare and Adobe RoboHelp, added support for mobile output. (There may be others too; I happen to support Flare and RoboHelp so they’re the ones I’ll focus on. But what follows applies to any HAT that offers mobile as an output.)
As part of the MWI, W3C created several standards including Mobile Web Best Practices Basic Guidelines, a Recommendation as of 29 July 2008. (www.w3.ord/TR/mobile-bp/) It offers 60 recommendations for creating, coding, and structuring of content.
It was NOT written with HAT- based mobile in mind, but many of the recommendations do in fact apply to HAT-based mobile, either directly or with some tweaking. Because of that, the rest of this post and a series to follow will examine these recommendations from the point of view of creating HAT-based mobile output. I’ll discuss the recommendations as I get to them, which means I won’t address them in the same order as they appear in the W3C document. But I will use the recommendation numbers for reference. Starting with…
4. [TESTING] – Carry out testing on actual devices as well as emulators.
Testing on emulators is convenient. Passing output to the emulator is built into the HAT’s interface, so it’s a matter of a few mouse clicks. Flare has its WebHelp Mobile emulator, and RoboHelp uses the Adobe Digital Editions (ADE) application as its ePub emulator. Both work fine, but both have the same issues as every other emulator I’ve seen. (In other words, this is not a criticism of either vendor’s emulator but an assessment of emulators in general.)
• They can’t simulate network traffic loads because they’re not on a network, so there’s none of the delays that might occur in the real world.
• They’re driven by the full processing power of the PC on which they’re being run, rather than by the more limited processor and memory of the real mobile device, so they run more quickly and smoothly.
• They may not offer the unique behaviors of the real devices, such as the touch-screen interface, so the user experience isn’t faithful to reality.
• You may also get some odd behaviors in different emulators, even those for the same standard. For example, if you output a RoboHelp project with multiple topics to ePub and display it in ADE, the result displays all the topics in ADE as one long scrolling file – basically a “book”. Display the same output in Firefox using its epub plug-in, however, and each topic from the project displays as a separate web page. This means that you’re going to get different behaviors for things like scrolling – through the whole book versus one topic at a time, for example.
So you’re ultimately going to have to buy examples of each device on which your mobile content is supposed to run and test accordingly. That’s nothing new for Engineering, but it may be a new experience for a doc group. The doc group would either have to set up its own publishing, testing, and QA processes and lab or work very closely with Engineering in a new and unusual way.
More to come…
No comments:
Post a Comment