Re: Mobile - tooltips and other embedded help

Subject: Re: Mobile - tooltips and other embedded help
From: Tony Chung <tonyc -at- tonychung -dot- ca>
To: Charlotte Branth Claussen <charlotteclaussen -at- gmail -dot- com>
Date: Fri, 4 Dec 2015 10:36:21 -0800

On Thu, Dec 3, 2015 at 3:00 AM, Charlotte Branth Claussen <
charlotteclaussen -at- gmail -dot- com> wrote:

>
> What are the challenges?
> How do you avoid the "mobile first" approach affecting the desktop versions
> negatively?
>

You can't. Mobile requires an entirely different mindset. You could say,
for example, 50% of desktop users read the docs for personal enjoyment (or
study for proficiency), whereas 100% of mobile users are in-the-moment. The
mobile users require less fluff and more anticipation of the tasks they are
trying to accomplish. On the other hand, desktop users need the
in-the-moment access, as well as additional detail that they can peruse at
their own request.

The only way you would know for sure is to study how your users behaveâwhat
works for one industry may not work for another, as the use cases are
entirely different.

How do you solve the issues with touch interfaces and small screens? (when
> you can't do right-click, hover, etc. - and you don't have a lot screen
> estate for buttons or extra text)
>
>
These are usability problems that require a technical understanding of the
platform. Now that Apple released "force touch" for newer devices,
developers are finding a place to insert its capabilities in every
application. But just like the IE vs Netscape wars in the 90s, proprietary
features don't build users. Following a widely accepted body of standards
does.


> I have done some searching and seem to mostly find examples of what is
> *not*
> working.
>
> Do you know good examples of embedded help for mobile devices?
>
>
The UX team will say that for mobile devices, the best help is no help at
all. The MOOPPOP (ha! nice term) should be discovered during development
and fixed before release. The best embedded help for any device is that the
app is labeled correctly, and provides a context-sensitive message for each
activity that requires it.

This is why it's imperative that UX, Devs, and TechCom forge partnerships
early in the development cycle. UX dreams the big dream. Devs assess
technical feasibility. And in between, TechCom ensures the UX requirements
are understood, and the Dev is explained.

-Tony
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives


References:
Mobile - tooltips and other embedded help: From: Charlotte Branth Claussen

Previous by Author: Re: Unerase 7z file?
Next by Author: Re: OLE Survey
Previous by Thread: Re: Mobile - tooltips and other embedded help
Next by Thread: Re: Mobile - tooltips and other embedded help


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads