Upcoming mlearning (Mobile Learning) Conference

mLearnCon, a mlearning (mobile learning) conference in San Diego June 15-17:

http://www.elearningguild.com/mLearnCon/content/1603/mlearncon---home

Thanks to Cheryl Landes

Interesting Review of the iPad in Time Magazine

Here's the link - www.time.com/time/business/article/0,8599,1976932,00.html

Thanks to Deb Sauer, Deborah Sauer Consulting

TE SIG Mobile Content Session - Demos via GoToMeeting

As I said at the TE SIG meeting last night after my laptop wouldn't sync up to the projector, I'm going to show the live demos of various authoring tools and emulators via my GoToMeeting account instead.

In order to try to take people's schedules into account, I'm going to run the demo twice in 45 minutes sessions on the following days:

Wednesday, June 2, from 9 to 9:45.
Friday, June 4, from 1 to 1:45.

If you can make either of these sessions, email me at nperlin@nperlin.cnc.net and I'll send you the meeting ID. If you can't make either of these sessions, let me know at the same email and we'll try to work something out.

MadCap Flare Goes Mobile

In a recent post, I discussed how RoboHelp 8 has added support for mobile output. In this post, I’ll look at Flare 6 and its support for mobile output. Again, some background about the mobile space…

Mobile debuted in the early ‘90s with Apple’s Newton. Newton was revolutionary, but its problems turned it into a footnote in computer history. Windows CE Help and Wireless Markup Language followed several years later, but failed in the mass market for, in my opinion, three reasons. One was an unattractive output, shown below in a real screen from a presentation that I gave in 1998:



That problem has been corrected, as evidenced by the examples below – iPhone apps for star charting and birding:

Another problem was that vendors didn’t know what content to offer so they offered anything, much of it “fluffy” novelties whose charm wore off quickly and that lacked staying power for the mass market. Many apps today share that problem, but there are a lot more apps so there’s a better chance of finding something good amid the fluff.

The third problem in ‘98 was a rough authoring environment, often requiring hand coding. Authoring can still be difficult, but there’s a decade’s worth of improvement in the tools.

So, in general, mobile has become easier to create and more attractive to use.

For today’s technical communicators, there’s a new problem however. Do we create apps, or help or doc to be read on mobile devices? App development is new for many technical communicators and can take them into unfamiliarly complex authoring issues. But the help authoring tools, or HATs, offer another approach – letting us put online content into a format that works on mobile devices and either stands on its own, like an online procedure manual for use in the field, or help for a real mobile app. (If you think today’s mobile apps are so simple as to need little or no help, you’re right. But as mobile device power keeps increasing, I expect increasingly powerful apps to appear that will need help.)

Flare offered mobile output as an option in the interface when it released v. 6 in March. In this post, I’ll give an overview of the feature set and results. Another article will appear in a forthcoming issue of the Communicator, the journal of the ISTC (Institute of Scientific and Technical Communications) at www.istc.org.uk.

Flare 6 supports mobile output through its WebHelp Mobile output target. The target is integrated into the Flare interface, so using it mechanically simply involves creating the target, selecting WebHelp Mobile as the output type, setting or selecting various options, and generating the output. Most of the options are familiar ones in Flare, such as skins, TOCs, CSS mediums, and so on.

How well does it work? Here’s my test project, output as standard WebHelp:

And here’s the same project output in mobile form:

What’s striking about this test is that I made no changes to the project except for the skin settings; Flare just gave me the material in a different format. This has strategic effects for development. If you’ve wondered what your online help or doc would look like in mobile form, you no longer have to buy and learn new tools. Instead, just select mobile as the target. And if mobile proves not to be what you need, just delete the mobile target and try something else. In other words, there’s no risk to trying mobile.

More specifically:

• WebHelp Mobile produces a “mobile site” rather than a “mobile app” so it’s not tied to a specific device. It’s simply a web site accessible from any device with a microbrowser.

• The code is “pared-down” XHTML, so it’s open-source.

• WebHelp Mobile automatically adjusts to a microbrowser’s features. For example – no JavaScript support means no search capability or dynamic text features. This automatic adaption to the microbrowser’s capabilities simplifies project planning, design, and management.

• Flare has pre-defined mobile skins, so skin definition is just point-and-click.

• There’s a generic emulator to preview WebHelp Mobile, shown below:



• All standard navigation options are available on the home page, as shown below.



Mechanically, outputting a project to mobile is a snap. The problems arise in design. This isn’t a problem in Flare but rather in the need to fit output designed for large-screens onto a screen the size of a sticky note. My test project has a fairly typical feature set. Here’s a summary of what happened on conversion…

• Text and variables (which are text) converted smoothly because they reflow to fit the screen sizes.

• Objects that are too big converted but added horizontal and/or vertical scrolling. (Scrolling reduces usability but isn’t necessarily evil, but avoid combining both types of scrolling at the same time if you can.) You can expect this problem with tables, graphics, drop-downs and togglers that contain tables or graphics, master pages, wide head styles, and SWFs. Snippets and project import link items can also be troublesome because they may have the same problems but you won’t “see” it as you insert them – basically “out of sight, out of mind.”

• Popup links converted to jumps. Some microbrowsers don’t display popups, so making the popups work as jumps supports the lowest common denominator microbrowser.

• The only other problems I’ve found or heard about so far are due to the limitations of the display devices themselves. For example, WebHelp Mobile should be able to use a regular project’s header and alias files to create context-sensitive help for mobile apps, but the device must support multitasking or else opening the help closes the app.

• Finally, there’s the design problem of deciding what information to omit from the mobile output.

Except for the last point, you can deal with most of the other problems by making fuller use of Flare features. For example, style properties should be relative rather than absolute – % or ems for text size instead of points for example. This isn’t unusual for text, but what may be unusual is the need to do so for tables and images. (You’ll want to create a CSS medium for the mobile output.) For example, here are two versions of the same page, one with the graphic displaying at its default size and the other with the height and width set to 50%. Note how the second one eliminated the horizontal scroll bar.

This isn’t that difficult, but it will require you to look more closely at your styles and properties and maybe try some features of the Stylesheet Editor that you’ve ignored until now. You’ll also make greater use of conditionality, and perhaps variables in order to use full names in the regular output but abbreviations in mobile. You may also have to re-evaluate your content to determine what’s really needed and what’s there because it’s cool and you had the screen space to indulge yourself. And so on…

If you’re a Flare shop and considering mobile output, you’ll find that the mobile target will push you into new areas of information design in general and Flare’s feature set in particular. And it’s fun…

Open Questions From Single Sourcing Class in Canada on May 13

Here are the answers to the open questions from the Single Sourcing class in Scarborough last Thursday, May 13

In what format does Flare output PDF – Adobe.

Do mathematical expressions convert correctly – Depends on the version of Acrobat you have. Check your version's specs.

Do custom templates have to be in the My Documents/My Templates folder – Yes in Flare through v.5. V.6 now lets you put templates wherever you want by using the Template Manager dialog box, available by clicking the Manage Templates icon on most Add New… dialog boxes.

Can you physically exclude topic files (.htm) from the output folder – Conditionalize the topic at the topic level, not at the content level in the topic, and then exclude the condition from the build to physically remove the topic’s .htm file from the output folder. This did NOT work the first time I tried it, but it did when I tried it twice more so I assume I missed a setting the first time.

Can you have topics’ content output to print without listing the topic in the TOC in Flare – No. Flare uses the TOC to select and sequence the topics to output to print, so removing a topic from the TOC in Flare removes that topic’s content from the output. You can work around this by leaving the topic in the Flare TOC for output to Word, then removing the topic’s content from the TOC in Word.

Thanks to Alvaro in tech support for several of these answers...

May 25th Boston STC SIG Meeting on Mobility and Tech Comm

This is a reminder about the Technical Editing SIG presentation that I’m doing for the Boston chapter of the STC on May 25 in Natick, MA. (See the chapter site for the address, times, and directions - www.stcboston.org/sigs/te_sig_may2510.shtml.)

I’ll start by discussing the rationale for mobile content, and for tech comm to be creating that content as part of our regular role. Then the history of mobile, briefly – one slide, followed by three reasons why mobile information may succeed this time.

I’ll then cover three target options, two architecture options, and two dev options, with the dev options focusing on using HATs like Flare or RoboHelp to create mobile content vs. using dedicated mobile web authoring tools. Finally, I’ll look at what standard online content design elements work or don't work in the HAT-created content and how we’ll have to change some ways in which we work in order to fix those things and add mobile to our repertoire.

I’ll also demonstrate a number of readers and emulators including, at the moment but not officially, MadCap’s WebHelp Mobile viewer with content from Flare 6, Adobe’s Digital Editions ePub emulator with content from RoboHelp 8, an Android emulator, a quasi iPhone emulator, Firefox in small-screen rendering mode, and whatever other tools I can set up between now and the 25th.

And if you're interested but can’t make it, email me and I’ll send you the slides.

This stuff is fascinating...

The Return of Location-Based eCommerce

One benefit of longetivity in any field is the ability to see cycles. The latest cycle I’ve seen is the return of location-based eCommerce – an interesting idea (just as it was ten years ago).

Consider an article entitled Social Media’s New Mantra: Location, Location, Location in the May 10-16, 2010 edition of Bloomberg Business Week. The article discusses the promise of social media-based, location-based ecommerce. It focuses on several companies that are moving into this space or that already have a presence, ranging from startups to existing companies. The article suggests the example of an iPhone app that checks your friends’ calendars to see if they’re free for the evening, suggests a restaurant that everyone’s wanted to try, notes table availability, and notes where your friends are to make it easy to hook up. Cool…

Now consider this description...

… there’s a specific type of location-based application that’s likely to affect technical communicators – lCommerce (“l” for Location), or mCommerce (“m” for Mobile)… these applications will determine your location and try to sell you things based on that location. For example…

• The florist’s site beeps you when you’re within a mile of the store to remind you that tomorrow is Mother’s Day.

• The car wash beeps you as you drive by on the day after a blizzard to remind you that road salt is bad for your car’s chassis – why not come in right now?

• You’re looking for a Cajun restaurant in an unfamiliar city, find one on an online restaurant list, select it, and have a web site detect your location and continuously provide directions to the restaurant

More ambitious applications could bring people together by detecting their relative locations. For example, a Starbucks’ site might call as you drive past and tell you that your friend Bob is inside and that you’ll get a dollar off a latte if you drop in now. Or that florist’s site might beep to tell you that tomorrow is Mother’s Day but warn you that your mother is in the store right now.

This latter description is from a column that I wrote for Intercom, the magazine of the Society for Technical Communication, in February 2001. I ended that column with this prediction as to how location-based apps might affect technical communicators.

… should see two types of work coming out of the location-based applications. First, there’s likely to be an increase in site development work as local businesses decide to create web sites. Second, given the high potential for irritation…, we may find work creating filters to block calls from the same sites that we created. If all this sounds unlikely, remember that it isn’t too long ago that the idea of technical writers creating web sites was ridiculous. Location-based applications will be an interesting addition to our repertoires.

I’d have to say that I got this prediction wrong. (There may be technical communicators out there who do this type of work, but I’ve never met one.) However, as society becomes increasingly mobile, the idea is still sound and the technology is a lot better than it was in 2001. I have no idea what might come of this technology, but it is worth watching.

RoboHelp Goes Mobile

Help authoring tools, or HATs, have been around for a long time. RoboHelp, the second oldest HAT, appeared in 1991/92 – impressive longetivity in a technical field.

HATs stay alive (business issues aside) by constant adaptation in the face of technical changes. For example, HATs in general could have disappeared in 1997 when Microsoft introduced HTML Help, since we could now create online help with web authoring tools like Dreamweaver. Many of the original HATs did in fact fail to make the shift to HTML and disappeared. But the larger, better funded ones like RoboHelp and Doc-To-Help did make the shift and are with us today.

That large-scale adaptation has continued since 1997, with the incorporation of support for PDF, XML, DITA, and now, mobile output, the focus of this post.

The mobile space has been chaotic since the late 1990s. Technologies like Windows CE Help and Wireless Markup Language looked good but failed to penetrate the mass market for several reasons, a major one being the fact that mobile output looked like this in 1998 (a screen from a Wireless Markup Language presentation that I gave back then):



This was a simple mobile app designed to teach the coding, but full-scale apps weren’t all that much more exciting. The screens were grey and bland compared to what we expect today, which looks more like this…



So mobile content and mobile apps are more inviting than they were a decade ago. And the explosive growth of the iPhone, Android, RIM, and other mobile devices has given mobile a degree of market credibility that it hasn’t had before. So it makes sense to start looking at mobile. And yet…

Many companies are reluctant to try mobile for three reasons:

• There may not appear to be any environments in which their apps can be used in a mobile mode. But some uses just may not be immediately obvious. For example, accounting apps might be used in the field for inventory control and need mobile-style online help. Or reference guides containing settings for pollution sensors in a food processing plant might be more usable on a mobile device when the sensors are mounted up near the ceilings.

• Companies may be looking at the market for mobile apps or help or “content” and find the choice between the various platforms to be too confusing or chaotic to be able to pick one.

• Companies may have tried mobile before and been disappointed by the feature set or burned by the reception in the market.

In each of these cases, companies will be rationally reluctant to invest in new tools. But if your company uses certain HATs, and I’ll focus on RoboHelp here, there is a way to test the mobile waters almost effortlessly.

On April 23, Adobe released a RoboHelp 8 script that converts RoboHelp projects to the ePub format. ePub is a standard from the IDPF (International Digital Publishing Forum) for “reflowable” text, which essentially means that content can change its width to take into account the width of the screen on which it’s being displayed. You can find the instructions for downloading and installing the script, along with suggested best practices for coding content, on the blog of Ankur Jain, RoboHelp Product Manager, at Adobe’s Technical Communication blog at http://blogs.adobe.com/techcomm/. The instructions for the script itself are in the April 23 post. The preliminary announcement was in the April 12 post.

The reason this script release is important is that it’s strategic. If you’re a RoboHelp shop but have wanted to try mobile output, you no longer have to buy and learn new authoring tools. Instead, mobile simply becomes one more output in a tool you already own. And if mobile turns out not to be what you need, there’s no money wasted on a dead-end tool - just abandon the mobile output and go back to your regular RoboHelp work.

I’ll be describing the feature set and some test results in an upcoming post.