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…
Thursday, September 30, 2010
Monday, September 27, 2010
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…
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…
Thursday, September 16, 2010
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.
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.
Thanks to Cheryl Landes for this recommendation.
Subscribe to:
Posts (Atom)