Information 4.0 Technologies and Their Issues

Information 4.0 is getting a lot of attention, but what is it and how will it work? Andy McDonald, one of its evangelists, describes it as “…the informational component of Industry 4.0.” (I discussed Industry 4.0 in an article in the Winter 2017 issue of Communicator.)

Think of “Information 4.0” as an umbrella term for advanced technical communication technologies. Its overall goal is to create user assistance that is:

• Continuously updated – as up-to-date as possible.
• Focused on the requester’s needs – an event triggers the content which is then automatically profiled for the requester, as opposed to being static and generic.
• Ubiquitous – available when and where needed.
• Broken into small chunks, or “fragments” that are independent of each other and assembled as needed, like beads on a string.

How will Information 4.0 work? At a high level:

1. Some mechanism determines the context of an information request.
2. Some mechanism sends that context to a repository of categorized content fragments.
3. Some mechanism extracts the appropriate fragments from the repository, forms them into an output, and sends that output to the requester.

If you’re thinking that this is simply an extension of how we create context-sensitive help today, you’re right. But Information 4.0’s technologies and required skills make it a HUGE extension of that work.

In this article, we’ll look at some of the major Information 4.0 technologies by function, and some issues behind those functions. As you’ll see, there are as many questions as answers today as the concepts, technologies, and methodologies emerge. (Similar to the web in the mid-90s, when the browser wars were heating up and people often didn’t know what browser they had or even what a browser was.)

The article does not discuss specific technical communication-oriented tools because those tools are still undefined. Today’s help authoring tools will add Information 4.0 features and new tools will appear as that market emerges. That’s the subject of a later article.

Contextualization

Technical Overview

In order to tailor the content to a requester’s needs, the system must know the context of the request. Contextualization sounds mysterious but it will be familiar if you create context-sensitive online help. It lets the help system determine the requester’s location within an application and what help topic is related to that location. (If the requester is in the Print dialog box and clicks a Help button, a Print Dialog Box Help topic should open. Simple.)

Traditional context-sensitive help is simple. A standard method has existed for years and is supported by the GUI of our help authoring tools; it’s a well-known process with no coding work. (Although companies can have proprietary methods that the tools don’t support.)

In Information 4.0, however, “context” goes far beyond the “in what dialog box is the requester located” model to include contexts like:

• Geographical – physical location, outdoors using GPS or indoors using GPS or beacons.
• Chronological – date and/or time.
• Environmental – temperature, light levels, and more.
• Spatial – device orientation, such as whether you’re holding your phone in portrait or landscape mode, and more.
• Personal – pulse, temperature, and more.
• Perhaps other contexts, such as physical to detect conditions like vibration or strain in machines.

Issues

Contextualization issues include:

• Transience. Traditional context-sensitivity is stable until the requester changes it – e.g. you’re in dialog box A until you go to dialog box B. But the other types can change quickly and often, like a light sensor that has to distinguish between light and shadow while the requester is under a tree on a windy day. This puts more demands on the sensors.
• Context detection method. Traditional context detection is built-into our authoring tools; others are not and the detection method must be coded separately. We’ll need programmer support.
• Context transmission method. Transmitting the contexts to the processor needs fast and reliable internet access, plus some local fallback when internet access is slow or lacking.
• Context processing. The context must be analyzed to determine what content fragments to send to the requester. This might take place outside or, eventually, within the authoring tool, possibly on a server.
• The effect on hardware, software, and network requirements.

Content creation

Technical Overview

This is simply the creation of the content to be delivered in response to a user’s request.

Conceptually, it’s identical to content creation today but Information 4.0’s requirement for fragments complicates things. How?

• Traditional authoring tools like Word or FrameMaker exist to create documents – books. We can create content fragments with them but the process takes more concentration. Users of Word of FrameMaker may have to switch to more topic-oriented authoring tools.
• Writing will have to change. For example, traditional continuity (“as described above”) won’t work because “above” may be in a different fragment that may not appear in a given output.

Issues

Some content creation issues exist today, and new and more complex ones will appear.

• Fragments will have to meet the needs defined by the contexts. That seems self-evident, but it means that context definition will have to be done prior to content creation. In other words, “winging it,” already a bad idea today, will be a really bad idea under Information 4.0.
• Fragments may have to stand alone or be combinable on the fly in response to user requests.
• Fragment naming, metadata, and similar control conventions will be crucial. The “winging it” that we can get away with for 100 fragments will be unmanageable for 1,000 or more.
• Fragment creation will require authoring tools that create syntactically clean code and no tool-specific code that might affect the processing.
• Fragment content must be separate from formatting rules. This requires a CSS and elimination of local formatting. The content must also be separate from business rules to let it be used in any output ranging from a browser to a mobile app to a bot to whatever is next. The internal structure of the content has to reflect this separation.
• Search will be crucial for finding information, so SEO (search engine optimization) will be crucial.
• Fragments may have to be created to meet different, personalized requests. For example, for a process description, can there just be one fragment containing a list of the steps? Must there be an additional fragment containing the steps and the concepts? Or an additional fragment that describes the concepts that can be combined with the steps fragment depending on the requester’s background? And how do we know the requester’s background?
• The contents might use “microcontent” depending on your definition of microcontent – ranging from a title or heading to an abstract or meta-description that appears on a search results list.

Finally, and most meaningfully for the future of technical communication…

• The number of fragments required, plus the naming and coding requirements, may mean that traditional technical communication won’t be able to keep up with the work. Instead, AI-driven tools will create the fragments; our roles will become that of AI rule writer and content curator. Traditional writing will become a thing of the past in companies using Information 4.0.

Content selection

Technical Overview

Once the content fragments exist, it’s necessary to select appropriate fragments for a particular context and control the order in which they’re presented to the requester. (“Order” may seem like an odd issue if each fragment is independent but individual fragments may discuss individual steps in a task and must be presented in the right order. This is more important in print than online. In online, fragment order is less important because the order may be controlled by hyperlinks – e.g. “Click to go to the next step”. However, that implies that the links may have to be included for some outputs but excluded for others. This increases the structural complexity of the fragments.)

Back to content selection…

Content selection means that the fragments must be tagged so that they can be retrieved based on the context. There’s a model for this today, conditionality.

Issues

The conditionality feature in help authoring tools like MadCap Flare lets us assign a tag to fragments of content. We can then select content for a particular output by including or excluding content that has particular conditional tags. To do this, however:

• Authors must know what outputs they need in order to create and assign the tags. This work is simple but time-consuming when they have to tag many fragments. The same will be true for Information 4.0.
• Conditionality code is tool-specific. It will be years before Information 4.0 tools are as integrated as today’s help authoring tools so working in Information 4.0 will require multiple tools. This means the tags must be open source. The W3C’s RDF (Resource Description Framework) seems like the most likely candidate because it’s already used in Industry 4.0, the conceptual home of Information 4.0.
• Authors will have to become familiar with RDF. We probably won’t have to know it at the code level; GUI tools exist now. But it will be important to understand RDF at a conceptual level in order to use it well.
• The number of fragments to tag and the speed needed to do so is likely to shift the work toward an AI-based model. This means that our roles will change to AI rule writer and enforcer/curator and technical communication will become a thing of the past in Information 4.0 shops.

After the tags have been assigned, the appropriate fragments must be called from the repository. Calling fragments in today’s help authoring tools is mechanically simple point and click (though figuring out the logic can still be complicated). But until Information 4.0 authoring tools become as integrated as today’s help authoring tools, we’ll need programming support to write the scripts to read the context state information, translate that to the RDF codes, and call the fragments to generate the output.

Output generation

Technical Overview

After the processor receives the context information and retrieves the appropriate fragments, it has to generate the output. This seems straightforward, like generating HTML5 output from a help authoring tool. However, as you might expect by now, the process may not be that clear.

Issues

One issue is whether the output is a loose set of XHTML files or a packaged set of files like that created when outputting HTML5 from a help authoring tool. Why does this matter?

• If ancillary navigation files, like a table of contents, or control files, like a CSS, are to be part of the output, they have to be generated and applied to the output through some build process. Most builds are quick, under a minute, but I have seen some that take hours. Requesters won’t want to wait for a build that takes hours, so they may not use the content at all or use an older version, if they can. The problem is whether requesters will wait for a build that takes a minute.
• To avoid the build time problem, the fragments may just be uploaded to the requester’s device. If so, how will the ancillary files be applied, if at all?

Issue two has to do with whether to enable responsive output features. Given that ubiquity is one of the qualities propounded for Information 4.0, one output should be readable on desktops, tablets, phones, etc. We can create a separate output for each device but that requires a build, with the build time issue, or we can create one responsive output that can detect what type of device it’s on and reformat itself accordingly.

• If we want to enable responsive output, which seems logical to drive ubiquity, there must be a build process. That raises the build time delay issue mentioned above.
• To avoid the build time issue, there must be a way to generate files that will run on any device.

Output delivery

Technical Overview

Output delivery entails the ubiquity mentioned above – the accurate and up-to-date output must always be available when and where needed. This seems like standard internet operations, but there’s also the issue of internet access.

Issues

Some of the issues are similar to those under output creation. But two others apply to delivery.

• In order for content to be ubiquitous, dynamic, and spontaneous, three properties desired for Information 4.0, requesters need internet access. What happens when requesters have poor or nonexistent access? This is an issue with mobile apps as well and lead to the creation of local storage options that could hold content until users got internet access back, at which point the app would connect to the database and automatically sync the data.
• What part of the content would be sent to the requester, all of it or just those parts affected by the context call?

Summary

There will be other issues too, such as content storage and analytics.

Where does Information 4.0 stand as of mid-2018?

• Many of the concepts – contextualization, fragmentary content creation, networked content, content tagging and selection, ubiquity in the form of multi-device capable responsive output, analytics, and others – already exist and have been implemented in varying degree in today’s authoring tools. They’ll have to be extended to move technical communication into the Information 4.0 world.
• Other concepts, such as AI, RDF, and machine-generated content, exist now outside traditional technical communication. They will have to be integrated into technical communication.
• Today’s help authoring tools don’t support Information 4.0 but they provide a model for those tools as they’ll start to emerge.
• The challenges of working in Information 4.0 are broad and deep, as this article tried to show, and will rival or exceed the issues that we faced when word processing, the web, and online help all hit technical communication.

Information 4.0 may ultimately be very different from what I describe here. It may live under another name. But the challenges will be the same and will take technical communication into new and intellectually challenging areas with new and fascinating jobs.

This article was originally published in ISTC Communicator, Summer 2018.

About the Author

Neil is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA.  He has many years of experience in technical writing, with 34 in training, consulting, and developing for online formats and outputs ranging from WinHelp to mobile apps and tools ranging from RoboHelp and Doc-To-Help to Flare and ViziApps. To top things off, he has been working in mobile since 1998 and XML since 2000.

Neil is MadCap-certified in Flare and Mimic, Adobe-certified for RoboHelp, and Viziapps-certified for the ViziApps Studio mobile app development platform. He is a popular conference speaker, most recently at TCUK 2017. Neil is an STC Fellow, founded and managed the Bleeding Edge stem at the STC summit, and was a long-time columnist for STC Intercom, IEEE, and various other publications.  You can reach him at nperlin@nperlin.cnc.net.