STC Summit day 2 – Publishing to mobile devices
I’m attending STC 2012, the annual conference of the Society for Technical Communication. This post contains my notes from a session called “Publishing to mobile devices: Best practices and strategies”, by Mike Hamilton from MadCap Software.
Mike let us know that he’ll be talking about the topic from the standpoint of the MadCap tools. But the concepts and principles apply to other tools too.
The session covers:
- Types of devices
- Delivery formats
- Delivery strategies that we can use to combine the above two points
Types of devices
Smartphones. We’re on the third or fourth generation of smartphones. They’re becoming ubiquitous. Mike also includes handhelds in this group, such as devices held by people who read water meters. These are handheld devices that can communicate. Challenges for our content:
- These devices are small (3 to 5 inches). This limits the width available for our content. Multi-column tables or wide images are a problem.
- The devices tend to have a relatively low resolution. (The newest iPhones offer a resolution of 640×960, which is the best available.)
- They use touch/swipe interfaces. This affects the way people navigate through our content. Also, elements must be the optimum size for human touch.
Tablets. These are also portable devices, but offer a different set of challenges for communication.
- They’re a medium size.
- Medium to high resolution. The proportions may be odd, such as 1024×600. The newest iPad is 2048×1536, which is magnificent. No problem delivering content there.
- Once again, the interface is via touch. From an interactivity point of view, we can’t just dump what we’re using on the PC onto the phone or tablet.
This part of the presentation is focused on what MadCap Flare produces:
- WebHelp Mobile
- Traditional, frameset-based WebHelp
- HTML5 (WebHelp 2)
The output has a familiar, paperback feel to it. Content is divided into pages, there are bullets, there can even be a page header and footer. Note that the page header and footer are not highly customisable. This makes it difficult to brand a document.
EPUB is designed for long, linear documents such as novels. In other words, it was not designed for technical documentation. We can use it, but must be aware of the limitations.
EPUB requires a viewer. Not every device ships with a viewer, with the result that people will need to download one. EPUB presents content like a book, but it reflows content like a web page. This makes for a good reading experience, but it does mean that the page numbers are different on different devices. Also, there are problems with overflow: if an image is too wide it is simply truncated, and wide tables are truncated and distorted.
EPUB is an offline format. When you get the document, the entire document is downloaded onto the device. The entire document is a single file, which is more convenient than other formats that deliver a number of files. EPUB is a common standard, which means that any tool can produce EPUB format.
This is a format developed by MadCap. It is optimised for mobile devices. One single output supports all devices. You don’t need to download any specific viewer. The format uses the built-in browser on the device. MadCap tests the format with these devices:
- Windows Phone
Flare includes a mini-emulator for testing your content on a mobile device. Mike dropped the hint that they’re using the Windows Phone renderer for IE to generate the content inside the emulator window, with some graphics around the edges to make it look like a mobile device.
WebHelp Mobile does support branding. Because it is an online format, the content is kept up to date. This format is designed to handle overflow content as gracefully as possible. It adds a scroll bar. It also avoids extending the width of the rest of the page. The text will remain the correct width for the available screen size.
Optimised for medium or large format devices. It uses the onboard browser. Branding is possible.
This format has been around for a while. It’s cross-browser and cross-platform. It presents the familiar tri-pane help format.
This format uses frameset technology, which may cause problems with security and SEO. There may be problems on Android devices with some WebHelp formats, when you need to do cross-frame communication.
WebHelp is not touch friendly, although you can customise it to be so.
This looks very similar to WebHelp. It uses the same tri-pane format, but there are not framesets. Instead, it uses HTML5 and CSS to give the same look.
This format is SEO friendly, can be branded, and supports all browsers and platforms.
Because this is a new format from MadCap, it’s still a little difficult to customise.
For phones and handhelds, Mike recommends WebHelp Mobile, with a fallback to EPUB if the users are not online. Mike gave us tips on the best way to produce this format in Flare. For example, customise your CSS for the mobile output, and use conditional publishing to select only the essential content for the mobile output.
For tablets, Mike recommends modified WebHelp or HTML5. Customise the CSS for the tablet format, and modify the skin file to increase the size of the navigation items to make them finger friendly.
This is how Mike summarised his talk:
- Determine the devices you need to support.
- Select the output format for each device type.
- Tailor the content using master pages, skin files and conditionals.
- Modify the WebHelp or HTML5 skin files for touch compatibility.
Thanks Mike, this was a great insight into mobile content development and also into the tools that Flare provides.