Development Techniques for User Assistance in Smartphone Applications

Posted 16 February 2011 by

Main presentation

Joe Welinske

Joe Welinske

“Development Techniques for User Assistance in Smartphone Applications” was the title of the presentation given by Joe Welinske (WritersUA) at the February 15, 2011, meeting of the Puget Sound Chapter of the Society for Technical Communication. He shared some of his observations having worked with a couple companies developing user assistance for Apple® iPhone® applications. The bulk of his comments were about developing for Apple products.

When starting, Welinske made the following points:

  • Apps are becoming more robust
  • Complexity and minimal screen real estate don’t mix
  • Mult-touch and multi-key controls are not easily discoverable. (How do you know to “double-tap”?)
  • Conceptual, contextual information is still important
  • Enterprise-related apps benefit form a consistent UI

When it comes to creating user assistance, Welinske felt that using tools for creating user assistance for desktop applications did not meet the needs of iPhone apps. Even using the conditional text capabilities in tools like Adobe® RoboHelp® and Madcap Flare™ to single-source content could not fit the lifestyle and sensibilities of an iPhone app. User assistance for a phone app needs crafting to fit the situation, not building from a tool. For example, Flare will create a table of contents, but that is not what you need on an iPhone.

Some of the things he felt that fit the sensibilities are:

  • Use icons in the text again. While this used to be the way to do system help, it has not been the way to do it for 20 years.
  • Do not number instructions. You are probably only using three or four steps under a heading, anyway.
  • Words for buttons carry much more weight. Spend the time with users to do this research.
  • Add a few extra words on a page to help people understand when you have the room have great benefits.

Welinske made his point on choosing the right words with these examples:

  • In an app, a button said “Dismiss” when moving a timer to the background to let you do other tasks while still keeping time. This was a major technical support issue. The word “Dismiss” did not convey to users the fact the timer was still working in the background. Welinske did user research with several synonyms to see what conveyed the right meaning. Changing the word “Dismiss” to “Hide” solved the problem.
  • In an application bringing spreadsheet and document capabilities to an iPhone, users did not know what “font” meant. Do not assume people have used desktop applications before using an iPhone app. They changed the user interface text from “font” to “text.” While this may not be 100% technically correct, this did convey the essential meaning to the users.

When developing for an iPhone, you need to use a Macintosh®. You need to be in the same ecosystem. Older Macs upgraded to the following work for developing in the same ecosystem:

  • Hardware/Software
    • Mac with Snow Leopard
    • iPhone
    • iPhone SDK
  • Knowledge
    • Interface Builder
    • Objective-C
    • WebKit

For user testing, Welinske simulated an iPhone with the SDK on an older Mac. While you cannot use gestures on a simulator today, there is a beta version where you can use gestures with the touch sensitive screen.

A corporate server served the user assistance for the apps with which Welinske worked over the telephone network. There was an assumption you would always have connectivity when using the apps. This method means Apple does not have to approve the text. If desired, you can embed user assistance with the app, but this would require approval by Apple.

Using the “viewport” meta tag resizes your content on the browser on an iPhone. There is no penalty for using this tag when using the same user assistance text on other phones, as other browsers ignore this meta tag.

When developing user assistance for an Apple product, the tools are well defined and well laid out. When developing for a Google™ Android™ device, not so much. For one, user assistance text on an Android device goes into XML files, not into a dialog box. You also need the correct AVD—Android Virtual Device—for the right mobile device.

The specs for the Microsoft® Windows® 7 phone a firm. The Visual Studio development tools are easy to use.

My reactions to the presentation

Joe Welinske suggested crafting the user assistance for the app, while using icons and keeping content simple. Do not number lines. Also, use color instead of bold in some cases. In general, what he said makes sense. However, he suggested to do not add a period at the end of a sentence with your three or four single-line instruction sentences to keep with the sensibilities of an iPhone. For example:

Start a project

Tap +, tap a project Name
Tap Client, tap +
Type a Client name, tap Save
Select the client, tap Save

I see some accessibility issues with some of these ideas.

  • This uses color in a way prohibited by accessibility standards.
  • How is a screen reader supposed to get the sentences right without a period at the end?

This type of punctuation may fit an Apple sensibility, but I do not use Apple products. I may understand the meaning with the examples he gave, but it depends on each individual instruction only taking one line. Even if a good goal, can you promise an instruction will always only take one line?

While a long-time member liked the idea of using screen icons as a part of instructions again, I remember the problems in doing add them as part of the text. One of the issues is what happens if an icon changes. Considering what Welinske said about the rapid development and release schedules (weeks, rather than months or years), I see a headache in keeping the icons correct and current along with the text.

I have been wrong before. Maybe I am wrong now.

What do you think?

Contact information

If you have further questions about this subject, contact Joe Welinske through the Writers UA website, by email message, or by Twitter.

Visit the Puget Sound chapter of the STC website.

Post Details

Leave a Reply

Page optimized by WP Minify WordPress Plugin