Reader Question: Creating Online Help for Touch-Screen Applications?

A reader asks,

I caught your blog online and have been enjoying reading through the posts. I was wondering if you came across any information regarding creating usable online help for touch-screen applications. I found one article that talked about using RoboHelp to create drop-down hotspots and context-sensivitity to lessen the need for the standard clickable TOC navigation (since on a touch screen, you wouldn’t have the benefit of a keyboard and mouse). What we have right now can be improved. We have a hyperlinked TOC that is just too small for anyone to click on. We have Frame and will be getting RoboHelp. We want to be able to leverage the same source file to create the online help and a printed guide.

Just wondered if you’ve encountered or heard about anyone writing for touch-screen apps.




You might look at how the iPhone delivers help. RoboHelp won’t give you anything special that other online help authoring tools don’t already deliver. If you’re planning to use a lot of drop-down hotspots, RoboHelp’s only advantage is that it allows you to embed Captivate movies inside hotspots. However, RoboHelp’s hotspots lack twisties (little triangles that twist down when clicked), so they’re not as user friendly. Still, RoboHelp is a fine application for delivering online help.

If you’re hoping to single source a printed manual and online help, you need a different tool (unless you’re good with Word macros). Madcap Flare does a much better job than RoboHelp. AuthorIt also does well.

But single sourcing seems a tangent from your initial question about touch-screen help. For touch-screen help, I recommend keeping the topics short, because I imagine the user is frequently standing or mobile. I also recommend supplying both a printed manual and quick reference guide, since the touch-screen interface may be too small to accommodate long text or graphics in a comfortable way.

If you do include help in the application, yes, make sure it’s context sensitive, because the user probably can’t open a help window and resize it next to the application interface. An online help file does offer searchability on the fly, but if the user can’t type on a keyboard, there’s little point in that, so make sure your printed manual has a good index.

Finally, all the touch-screen devices I’ve ever used have been small, so the help content may not single source anyway. For example, if you’re writing instructions for a touch-screen panel that controls a projector, the application’s help may be brief, such as 3-4 sentences only. But the printed manual may elaborate with more detail, including screenshots, diagrams, and longer explanations. If that’s the case (that the online help and manual don’t single source), then your RoboHelp/Frame solution will work fine.

Adobe RobohelpMadcap Flare

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

  • monkeyPi

    Interesting timing, I’m solving the same problem right now.

    I’ve been developing a touchscreen UI. Most standards (like the FAA HFDS) have specific guidelines for responsive area dimensions, which makes it difficult to use a common authoring tool like Flare or RH, as the dimensions are never sufficient for human-factors usability considerations for touchpoint applications. CSS might give one more control over most things, but dependency on the browser elements will still limit usability somewhat.

    If we’re only talking formatting, then, it seems that the best option to meet your reader’s requirement and offer the best usability is to use the FrameMaker route, and port the content for the online help over to a very-well (custom) designed PDF file. The controls in the PDF file (TOC/navigation/etc.) could be custom made to meet touchpoint standards.

    Otherwise, you’re left where I am, designing an interface from scratch to support it.

  • Tom

    monkeyPi, thanks for the comment. It’s obvious you have more experience with touch-screen applications than I do. Can you provide a more detailed comment or send me a link to a post on your blog about creating help for touch-screen apps? Thanks so much.

  • Pingback: Touchscreen interfaces at monkeyPi()

  • Mike Hamilton

    As MonkeyPI mensions, responsive area dimensions are critical. If using a tool like MadCap Flare (or others) then you definately want to know the standards you need to adhere to and create a custom skin file. In the skin file make any “clickable” elements oversize to accomadate the standards requirements. Then also use custom CSS attributes to increase both the size of the fonts used in the TOC/index as well as adding additional padding around the TOC/index elements providing more dimensional area for each of the items. Also as Tom noted above, unless some kind of virtual keyboard overlay is used then stay away from search and instead make sure that budget/time are allocated for doing a really good refinement job on both TOC and index.

  • Tom

    Mike and MonkeyPI, thanks for your comments on this topic. I was thinking about it today, and I agree that most touch-screen applications won’t allow you to have much of a help file in there. Kind of like your cell phone — sure there is often a “help file” included in the cell phone brains somewhere, but it’s skimpy and basic.

    The one help file I wrote for a touch-screen application I did entirely outside the touch-screen (because I didn’t have access to the touch-screen code). I created a booklet and also a one page laminated sheet that was placed right beside the touch-screen panel. I took photos with my digital camera to include as relevant images.

    It’d be really cool to see an online help file integrated into such an application.

  • Lisha Li

    If the tough-screen is big enough, I think the embedded help is a good way to help users.

  • Mike Hamilton

    I really can’t imagine doing something for a small screen like a phone. My comments above were based on work I had done with a hardware manufacturer supplying equipment to the semiconductor fab industry and the equipment had a full size 15 inch 1024×768 resolution touch screen built right in. This touch screen was the control interface for the hardware. One of the challenges of a clean room environment is that no paper is allowed so WebHelp was used to display all of the equipment operating instructions and maintenance procedures via the touch screen.

  • tsgee

    Big or small what matters most is the apps for all the funtions to intgrate and help the users. wish everythin could be easy for all

    tsgees last blog post..Touch screen piano a freeware

  • Karol

    It’s a very interesting subject! I know it is not the case, but I wonder if anyone out there tried to think different way and, for example integrate recorded voice instructions with on-screen animations/images etc. You lose the single-sourcing idea (though animations can be reused on the company’s tech-support website), but you add attractiveness to your product and free your deliverable from the responsive area dimension restriction.

  • Ed

    Mike, I was wondering if you can expand on oversizing clickable elements in Flare? I’m working with touch screen help as well (with full size monitors), and I mainly, as you suggested, increased the fonts and padding. The search field I erased entirely.

    Additionally, I created a custom skin with much larger buttons.

  • Mike Hamilton

    Hi Ed,
    By oversizing clickable elements I was specifically thinking of the user interface elements on the top toolbar in addition to the normal left pane navigation elements. This also applies to in topic elements as well. As authors we may take for granted the ease with which we can create a hyperlink from existing text on the page, however in a touch environment it would likely be better to create an oversize graphical button that is easy to select with a finger and use that as the entry point to the hyperlink. The bottom line is that any user interaction has to be examined in the context of a touch environment before you use it in such a system.

    I hope that helps,

  • raghavendra

    HI friend,

    Can u please solve my problem.Touchscreen application implemented in the K Desktop how did he do this without any touchscreen he has done this by using only normal monitor

  • yonna

    hi i have a rocada xphone nd i dont know how to add apps on my phone

  • Natalie James

    Worthwhile internet page and interesting post. I love piano a lot. I’ve marked it to return later. If at first you don’t succeed-skydiving is not for you

  • Jaydee

    another piece of interesting idea!

    is ebook not enough?
    have some ebooks and I guess it still handy and serve its purpose.