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.
>Gotta keep up with the times... linear, book-form documentation is
becoming obsolete. So I agree with mbaker; we need to rethink all the
old-school conventions that we're used to.
Becoming obsolete? When I trained as a technical writer 15 years ago we
were taught to chunk information into small pieces that could be used to
single-source docs and Help from the same source. "Every page is page one"
has been how I approached writing documentation since 2001. Is anyone
even writing book-form, linear documentation anymore? (I know the answer,
that was a rhetorical question....)
I've been at four or five different jobs in the past 10 years that were
working on developing some flavor of mobile apps. Each time that led to
investigating options for how to format and present online Help for a small
screen. But I have yet to actually have a mobile help project go live.
Either there were some sort of problems and the app was killed, or I've
left the company before the mobile version of the product launched.
You can condition out graphics to not appear in your mobile help. Flare
lets you display thumbnails of your graphics. But I've never yet solved
the problem of what to do about tables in mobile content.
On Thu, Jun 23, 2016 at 2:52 PM, Wright, Lynne <Lynne -dot- Wright -at- kronos -dot- com>
wrote:
> I've just started learning to author in Flare, largely *because* it
> enables my Help output to automatically adjust for display on mobile
> devices.
>
> People are increasingly using tablets or phones to run apps -- one of the
> products I document is used by airline staff, so I expect users will be
> accessing it mostly from mobile devices.
>
> Not only do I see it as my responsibility to provide HTML5 output for that
> purpose; but I don't want to have to rely on some programmer to code my
> output for different platforms, especially when they already have their own
> job to do.
>
> Gotta keep up with the times... linear, book-form documentation is
> becoming obsolete. So I agree with mbaker; we need to rethink all the
> old-school conventions that we're used to.
>
> -----Original Message-----
> From: techwr-l-bounces+lynne -dot- wright=kronos -dot- com -at- lists -dot- techwr-l -dot- com [mailto:
> techwr-l-bounces+lynne -dot- wright=kronos -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of
> Robert Lauriston
> Sent: June-23-16 2:29 PM
> To: TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>
> Subject: Re: HTML5, Phones, and Tables
>
> Does anyone who actually writes technical docs for a living spend much
> time working on stuff that will be displayed as HTML5 on a phone? In my
> experience, that's something that UX/UI people code, and the involvement of
> a docs person is typically with the raw content rather than the
> presentation.
>
> This seems to me like something that people who spend more time at trade
> shows than writing actual docs like to talk about because it's a market
> opportunity for consulting and whatnot.
>
> On Thu, Jun 23, 2016 at 4:53 AM, <mbaker -at- analecta -dot- com> wrote:
> > We should think of tables as a way to structured information lookup for
> static media. In other words, they are a technique for presenting data on
> paper because of paper's lack of any kind of interactive features.
> >
> > Consider, for instance, the time tables for a transportation company. No
> modern airline or bus company would dream of presenting its schedules as a
> static table anymore. Instead, the present a booking widget that lets you
> enter your starting point, destination, and travel times and automatically
> constructs an itinerary for you.
> >
> > So the question should not be, how do we present tables in online media.
> We should never be thinking in those terms. We should be thinking how to
> allow readers to manipulate this data, or to ask the question of the system
> whose answer depends on this data. If we also have to present the data in a
> static media, then and only then should we be thinking about how to make it
> into a table.
> >
> > The key here is to stop thinking in terms of tables and presentation and
> to start thinking in terms of data and queries on that data. Fall back to
> tables only as a last resort.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Visit TechWhirl for the latest on content technology, content strategy and
> content development | http://techwhirl.com
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>
--
Julie Stickler
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
