TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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