W3C Mobile Web Best Practices and HAT-Based Mobile

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…

A Business Side to Tech Comm “Initiatives”

Changing how a doc group works – new tools, new output formats, a new development methodology, etc. – has long-term strategic effects on the group and its relationship with groups like Engineering or Sales. These effects mean that such changes need to be “sold” – what’s their strategic and financial effect on the overall business? Will they lead to lower costs, higher sales or market share, more efficiency, better regulatory compliance, or some other benefit?

There’s so much information about this business aspect of proposal writing that it can be hard to know where to start. One good starting point that I recently found is a book called Maximizing Project Value by Jeff Berman, from AMACOM (www.amacombooks.org).

The book describes a project proposal methodology called Speed2Value, but the write-up is generically applicable to any project. It focuses on the strategic rather than the tactical, stressing a proposed project’s effect on the company rather than just looking at whether the project was finished on time and on budget.

The book also provides an overview of cost-justification methodologies like ROI (Return on Investment), NPV (Net Present Value), Payback Period, and IRR (Internal Rate of Return). It doesn’t go into a lot of technical detail, just enough to provide a starting point for further research or actually writing a proposal. The book is presented in lay terms, is clearly written, and is a quick read (I read it on a plane between Boston and Phoenix). It’s worth buying.

Why Use Twitter For Tech Comm?

Excellent blog post on why to use Twitter for tech comm. See http://tinyurl.com/yg3f76p

Thanks to Cheryl Landes for this recommendation.

The Future Arrives Earlier Than Expected

One sure-fire aspect of writing trends articles is knowing that I’m going to be wrong about something. What’s entertaining is seeing just how quickly that can happen...

In December, 2009, I wrote an article about trends for STC’s Intercom magazine in which I predicted, among other things, “dynamically reconfigurable outputs,” which I described as follows:

“One problem with documentation is our inability to create one output to handle everyone’s needs. We can use conditions to create multiple outputs from one project, but this creates multiple outputs to which we then have to steer readers. It works, but the development is inefficient and can be confusing. Instead, what we need is the ability to create one output that dynamically reconfigures itself based on readers’ login permissions, requests (“Only show me material related to Idaho.”), or external stimuli (like an aircraft maintenance manual whose content varies depending on whether the outside temperature is above or below freezing). This technology will simplify distribution of information by reducing the number of outputs. It would also let us create output that responds to readers’ needs rather to our estimate of their needs.

Assessment – This technology is under development now, but every effort that I know of is still proprietary. I expect it to appear in mainstream tools in the next few years…”

Four months later, at the WritersUA conference in Seattle in March, 2010, I mentioned this idea to a representative of AuthorIT. After he stopped laughing, he said AuthorIT had come up with just such a product in mid-2009 but hadn’t gotten around to serious marketing until WritersUA. So I basically had the prediction right but the timeline badly wrong.

The product is Dynamic Assistance Platform, or DAP, one of whose components is called Aspect. As the AuthorIT site describes it “…The content is personalized for the person viewing it by matching information in the content with their login profile. This means that when a user views content, it is content that has been filtered for their profile…”

From what I got at WritersUA, Aspect may not be for everyone – as an enterprise-level product, its cost may be too high for small doc groups or applications. But it is the first commercial implementation I’ve run across of what sounds like a really useful idea. Even if you use another authoring tool, it’s worth reading about. See http://www.author-it.com/index.php?page=aspect.

Blog About Mobile eLearning

Interesting blog re mobile, specifically SMS-based, eLearning at http://tinyurl.com/27ag2my.

I agree with the third commenter, Sue Cloud, who argues that the blog is talking about bits of communication rather than true learning per se, but I suppose this is a matter of definition - e.g. if you consider the Tip of the Day that appears when you start an application to be "learning," then this can indeed be considered "learning."

Thanks to Cheryl Landes for this tip.

Questions from Captivate Course in Orlando

Chris and Anthony,

To delete misspelled terms that you accidentally add to the dictionary - This is mentioned in the help. Terms that you add to the dictionary during a spell-check go into your personal dictionary, userdic.tlx, which you should find at \\Documents and Settings\\Local Settings\Application Data\Adobe\Adobe Captivate\Spelling.

To delete the Adobe logo from the movie playbar - You'll have to use a different skin. To do so, select Project > Skin Editor and select any other skin listed in the Skin field in the upper left corner of the dialog box.

Enjoy...

Workshop – Creating Mobile Device Output Using Flare

Need to create output to run on mobile devices from a Flare project but not sure how? You could create an app, but the process may be unfamiliar to your developers and call for new tools. Or you could use Flare itself to create the mobile output, in the form of a "site" that should run on most mobile devices that have a microbrowser.

Generating mobile output from a Flare project is simple mechanically. Where things can get tricky is in the design and control of the content – deciding what content to show or not show in mobile form and controlling that, controlling formatting by making full use of possibly unfamiliar CSS features like mediums and relative sizes, and more.

This half-day, hands-on, web-based class is aimed at Flare 6 users who need to quickly get up to speed on converting existing projects to Flare WebHelp Mobile output. Prior experience on at least one Flare project is necessary.

- Date - Monday, July 12, 9 AM to 12:30 PM ET.

- Cost - US$150 per person, includes workbook and working files.

- Location - Remote, via GoToMeeting.

- Outline – see www.hyperword.com/FlareMobile.htm.

Contact Neil Perlin at nperlin@nperlin.cnc.net to register or for information about payment.