Tuesday, September 19, 2017

Information 4.0 is a new concept but some of the technologies
and methodologies that it encompasses are available and implementable today, albeit
in early forms. But before that happens, Information 4.0 will face multiple
challenges, just as online help and the web did in the 1990s.

In this post, I’ll discuss four implementation challenges on
the management side:

Defining clear and consistently accepted terminology.

Demonstrating support for the company's strategic and business direction.

Dealing with problematic senior management biases.

Establishing and following standards, metrics, and analytics.

Defining Clear and Consistently Accepted Terminology

New technology often sounds like confusing gibberish.

Twenty years ago, and even today, there was confusion over
“WebHelp” versus “Web Help”, for example. Because of that confusion, many
companies bought the wrong tools, hired the wrong people, or just went off in
the wrong direction.

Today, there’s confusion over the meaning of “mobile”. Is it
an app? Responsive online help on a laptop and a mobile device? Something else?
I recently consulted at a large manufacturing firm that brought me in to help assess
its readiness to go mobile. One result was the discovery that the different divisions
had totally different interpretations of the term.

Information 4.0 promises entirely new levels of
terminological confusion. Is “molecular content” the same thing as a topic? What’s
“dynamic” content? And so on.

Until everyone agrees on the meanings of the terms being used
for an Information 4.0 implementation, it will be difficult to show support for
the company’s strategic and business direction. This means it will be almost
impossible to do anything else. So any Information 4.0 effort needs an
education component.

Demonstrated Support for the Company’s Strategic and Business Direction

Information 4.0 is cool. But that won’t be enough to build management
support because management is typically being pressed to support other initiatives
too, many also cool. It’s crucial to show, concretely, how Information 4.0 will
support the company’s strategic and business direction. That’s going to require
careful analysis of the company’s operations beyond technical communication.

Dealing with Problematic Senior Management Biases

Even if senior management supports an Information 4.0 effort,
we may encounter biases that affect that support. (In the early days of
business computing, managers didn’t want to use computers because that involved
typing and the bias was that typing was secretarial work. Renaming “typing” to
“keyboarding” got past that bias and made typing – on a computer – cutting
edge.)

For example, it will be crucial to present Information 4.0
as dealing with “content” and “user support”, not “documentation”. No one cares
about documentation. But despite your efforts, management may still view
Information 4.0 as documentation-focused, not realizing that “documentation”
today is more a combination of content creation and programming. If so, it will
be hard to get management support. By way of illustration…

I was contacted by a company whose online help was created
using a long-dead version of RoboHelp. Users complained that the search didn’t work
well and there were problems in the code. The company wanted to convert the
help to Flare to get better search results and clean up the code to
future-proof the content, both supposedly good things.

The company turned down the proposal on the grounds that it
was too expensive. The problem was that they saw their help as documentation
rather than as a strategic resource and gave it a far lower priority. The
upshot? Their staff would do the conversion. Unfortunately, the staff was bright
but didn’t know RoboHelp, Flare, or code so the effort was likely to be slow
and inefficient at best.

In that tale is an example of how management bias may harm
even efforts that management wants. And Information 4.0 is far more complex and
unfamiliar than online help, so bias is likely to be still more of a problem.

Standards, Metrics, and Analytics

In the mid-1990s, online help and the web were so new that
few companies had standards or metrics by which to measure them. And analytics
barely existed.

Today, however, getting management support for an
Information 4.0 effort will require showing support for your company’s business
and strategic direction. (That may not always be the case. In 2002, I spoke
with two people from an aircraft builder whose CTO was so impressed with mobile
that he directed that it be implemented on the manufacturing floor without cost-justification. So you may
not always have to demonstrate
support, but it’s the safe way to bet.)

Demonstrating that support often requires quantitative data,
ideally numbers that translate to increased revenue or reduced expenses. Information
4.0 is so new that few standards exist, and thus few metrics or analytics. Yet
Information 4.0 has a lot in common with today’s online help and web efforts,
and may be able to use some of their standards and metrics. The biggest problem
I’ve found with metrics for any purpose, let alone Information 4.0, is
resistance from people who don’t want to be measured.

Summary

Information 4.0, like any new technology, is fun to
speculate about and fulfilling to help emerge. There are many interesting
challenges on the development side and the impact on tech comm. I’ll look at these
in later posts.

But none of them matter if you don’t sell management on the
idea in the first place.

Wednesday, September 6, 2017

So, your company has decided to take its documentation
mobile. Great! But has the company considered:

•What does “mobile” mean? People often assume
that “mobile” means an app on a smartphone but does everyone share that
definition? If not, different groups can wind up going in different directions.

•How do you plan to go mobile? Creating
responsive versions of the documentation, converting the online documentation
to an app, creating a “true” app, or something else?

•Should your content authoring practices change?
You may be authoring in ways now that violate good practice, such as local
formatting in Word, but that have been working until you decide to go mobile.

•Will your business practices support an
organized and maintainable mobile effort? If not, the move to mobile is likely
to be a one-off that wastes resources and loses management’s support.

In this post,
I’ll briefly discuss these questions. The post is based on the “We’re Going
Mobile! Great!...” presentation that I gave at the STC annual conference in
Washington, DC in May, 2017 and the TCUK conference in Nottingham, England in
September 2017.

What Does “Mobile” Actually Mean?

It sounds silly,
but poll everyone involved to make sure they’re defining “mobile” the same way. Often, they may not be and the
result can be chaos if you’re trying to set up a company-wide mobile strategy.

How Do We Plan to Go Mobile?

There are three
primary approaches – responsive output, converting online documentation to an
app, and creating a “true” app.

1 – Responsive Output

Responsive output means creating
one online document or web site that can detect the properties of the device on
which it’s displayed and automatically reformat itself accordingly. This
can be very useful because if your material has to be displayed on desktop PCs,
tablets, and smartphones, you only have to create one output rather than one
output for each device.

And, depending on your authoring
tool’s features or your code skills, you can not only change the screen layout,
such as collapsing the menu, but change the layout of the content, such as
changing from a horizontal to a vertical format, and even change wording, such
as changing “click” when the material is displayed on a PC to “tap” when it’s
displayed on a mobile device. All automatically.

2 – Converting Online Doc to An App

Because so much online
documentation is primarily text and graphics, we tend not to think of it as
being suitable for an app. Yet many apps are largely text and graphics. Check
out the Messier List and Encyclopedia Britannica apps for example.

How can you convert your online documentation
to an app? Two quick options:

Not everything will convert
smoothly. Popups convert to hyperlinks. Some head styles converted to italic
when I converted a RoboHelp 2015 project, though this may have been fixed in v.
2017. But the main content, structure, and features converted surprisingly
well.

3 – “True” Apps

Need the look and features of a
“true” app? The last few years have seen the appearance of code-light or
code-free app development tools. These are sometimes referred to as DIY
(do-it-yourself) app tools, or categorized by Forrester Research as Rapid
Mobile App Development (RMAD) tools. (Look for a future post on the subject of
RMAD tools.)

RMAD tools have two uses for the
purposes of this discussion.

•Let non-programmers create apps.

•Let programmers create apps by making the interface
creation, workflow, and data access tasks simpler than working in code in order
to free up time to concentrate on the code-heavy tasks.

By way of disclosure, I’m
certified in one RMAD tool called ViziApps (www.viziapps.com).
For a list of other RMAD tools, see “10 simple tools for building mobile apps
fast” at http://tinyurl.com/hzz4j5c

Why create true apps rather than
using responsive output or converting your help to an app? Two primary reasons.

•User expectations – If you say “app” to most
smartphone users, they’ll have expectations about the look and features that
responsive output or converted help may lack.

•The need for new capabilities such as location
or orientation sensitivity, a built-in camera, RSS feeds, transaction
processing, and more.

What Effects Might Mobile
Have on Your Development Practices?

If you plan to make your content mobile in an efficient and
maintainable way, you may need to make some changes in how you create and
maintain that content. Some examples:

•No more hacks – Hacks may be impressive but
they’re often a bending of good coding practice that can be hard to maintain
and may not work as you upgrade your authoring tools or code version. As
someone once said, “A hack is a one-off; good coding is forever.” Eliminate existing
hacks and make it a policy that new hacks are not permitted.

•No more local formatting – Local formatting is inefficient
and overrides the styles in your CSS. This is not a not a mobile issue per se,
though it bulks up files and may slow downloading. But it’s just bad coding
practice and may break something in the future.

•Replace local formatting with styles, which may
mean cleaning up your CSS.

•Rethink your writing style. Make it shorter, more
granular, and more focused.

•Eliminate excess content.

•Tables can be hard to fit into small screens, so
rethink what purpose your tables serve and how to use them. If your tables are containers
for multiple content pieces, only one of which is used at a time, can you
replace your tables with lists of links or searches?

•Consider changing navigation – Indexes are being
replaced by search. Does this affect you?

•Use up-to-date, commercial tools – Look for tools
that offer new features like responsive output and get rid of outdated tools. Be
wary of tools with proprietary features that may not translate going forward. If
you use such tools, be wary of leap-frogging multiple versions to get up to
date or switch to a different tool.

Do Your Business Processes Support Mobile?

You can be okay regarding definition, technical approach to
conversion, and cleanup of development processes and still have the move to
mobile fail because it isn’t supported by your business processes. Some
examples:

•Management buy-in – Have you given senior
management sound business/strategic reasons for going mobile in order to
justify the effort and build long-term support? If not, the effort will die.

•Training – Have the authors been formally trained in the correct and
effective use of their tools? Peer-to-peer training may work if the trainers are experts, but too often this simply
promulgates bad practices.

•Standards – Have authoring standards been clearly
defined, promulgated, and enforced across all authoring groups? Without such standards,
it’s almost impossible to share content between groups and projects.

•Development metrics – Are there clear, focused metrics?
If not, it’s very difficult to identify weaknesses
in the development processes. Something as simple as time-per-content-unit is a
convenient way to keep track of the effort and resources required.

•Usage analytics - Do you collect and analyze usage data to find
out what users, if any, are using what material? Without such data, you’re basically
throwing your mobile content into the darkness and hoping for the best.

•Governance – Is there any formally defined
process for managing the workflow and ensuring that material meets internal and
any external requirements?

•And more…

Summary

It’s easy to go mobile – buy an authoring tool, figure out
how to use it, and convert your content to a mobile format. Unfortunately, this
approach can be very inefficient and lead to results that are neither
maintainable or reproducible.

Similar problems arose in the early days of online help in
the mid-90. But back then, much of the effort was experimental, user
expectations were minimal, and schedules were loose. Today, “mobile” is a much
more culturally accepted form of presenting content, which means that user
expectations have been conditioned by a decade of smartphones, and users want
their mobile content now.

Proper planning before going mobile will help your company
better meet those expectations.

Tuesday, September 5, 2017

Beyond the
Bleeding Edge was a conference session that I ran at the STC’s summit from 1999
until 2014, and a column I wrote for the STC’s Intercom magazine from 2000 to
2015. The goal was to introduce technologies that were new to tech comm – on
the leading (or bleeding) edge and beyond – such as XHTML, WSDL, JavaHelp, haptic interfaces,
the W3C RDF metadata standard, and more.

The Bleeding
Edge is now Hyper/Word Services’ technology blog. Look for a new post every 3-4
weeks on various technologies, tools, and methodologies, with a focus on mobile
content and the Information 4.0 concept, plus whatever else seems appropriate.