HTML5 Publishing Series Post #1: Why you should publish content in HTML5

Hello Everyone,

HTML 5 Help The first 2 weeks of 2013 as RoboHelp and TCS Product Manager have been very exciting for me. I’ve received numerous emails from many of you since my first blog post here. Thank you all for reaching out and sharing your queries and feedback. Your inputs go a long way in making great products.

As you may know, in RoboHelp 10, we released a number of new features and improved existing ones. One of those exciting features, which got the maximum attention from our users, is Multiscreen HTML5 publishing. You can see some of the early review comments here.

In this post, I want to kick-start a series of posts explaining the RoboHelp Multiscreen HTML5 functionality in detail. In this first post, I would like to emphasize on why technical documentation departments must embrace HTML5 as one of the core output formats.

But first, let me take you through the evolution of help systems!

Journey

Phase 1, the time before computers: Even though now it is difficult to imagine a world without computers, but in those times when they were not around, printed manuals used to be the only source of help related information for the users.

Phase 2, adoption of computers: Software companies were the early adopters of help systems which were based on CHM format. This was the time, when the tri-pane structure of the help got popularity. Even some of the other companies which manufactured hardware started creating CHM help and distributing to customers over floppy disks and CDs. The end-user behavior also begun to change as they threw away the linear navigation system of printed documentation and started using search and cross-references more and more.

Phase 3, arrival of internet: The arrival of internet was a boon for non-software companies since they could eliminate the distribution of help on storage systems and provide it online instead. Not only it was cheaper, it was better too since most of the content could be updated regularly. When Google became popular, searching for a relevant topic within online help became much easier for the users. Traditional help systems gave way to user forums and wikis. As the end-users became internet savvy exotic help systems based on Flash & AIR started to emerge as well.

Phase 4, Device Explosion

Device Explosion This is the stage we are in now. Since the iPhone launched in 2007, there has been an exponential growth in computing devices with varying screen sizes. There are 1 billion smartphone users in the world. The tablet sales are expected to beat PC sales in 2013. In India, mobile internet usage has already crossed that of desktop internet. We have different screen sized phones, phablets, mini-tablets, & tablets. In future, we expect SMART TVs with bigger screen sizes as well.

The other key thing to note about these devices is that they are much more likely to be with user than a desktop or a printed document and hence there is a compelling reason that help should be offered on these devices.

For example, suppose someone, who has bought a kitchen appliance such as blender, is having a problem in operating the same. Wouldn’t it be nice if she can scan a QR code on her mobile and look at help on the phone itself? Maybe she could then be taken to a YouTube demo explaining how to operate the blender. You wouldn’t want your customer to be grappling with a printed document or expect her to check help on a desktop. Would you?

Imagine the level of customer satisfaction that you can achieve by offering the content on the device which she carries all the time.

mobile-shipments-300x225

This brings us to the next question that offering help content on multi-devices are fine, but why HTML5?

Sure you can offer the same web help on all devices but the end-user experience would be extremely poor. The usual web output will not be able to adjust to the varying screen size of the devices. Someone who is viewing your online help on mobile would be able to see only the TOC pane. She will have to scroll both horizontally and vertically to navigate. And because of the cumbersome nature of this process, she will abandon viewing help on mobile and call your customer care instead. No company would and should want that.

This is an era of responsive design and HTML5 is apt at that

A website that has HTML5 uses fluid and flexible layouts that adapts to almost any screen size. One can define specific screen layouts for different devices and HTML5, using media queries, shall display the most optimal layout to the consumer as per her device. For example, Mashable & LinkedIn are couple of really good websites which demonstrate an effective use of responsive design. Please visit these sites on phone/tablet and see for yourself.

In future, you would see more and more websites being developed in HTML5, and help systems would be no different. In fact, our 2012 survey of technical writers suggested that 11% of the users are already publishing to HTML5 output, and a further 33% are planning to in near future. HTML5 could be the most important help output sooner than we think.

You can generate HTML5 output in RoboHelp 10

As I mentioned earlier, we have launched the HTML5 publishing in RoboHelp. Now you can generate visually stunning help systems for a variety of devices using your favorite help authoring tool.

In my next post in this series, I would be explaining the step by step process for multiscreen publishing in HTML5. For those who don’t have RoboHelp 10 yet, here is the link to download the trial version. For those who can’t wait, watch this short video on RoboHelp’s HTML5 publishing capabilities

Expecting a datasource

You may also wish to view the following recorded webinar, which provides more of a “deep dive” on this topic:

Multiscreen HTML5 for multi-device publishing with Adobe RoboHelp 10

Stay tuned for more on HTML5 publishing,