This article was originally published in ISTC Communicator, Winter 2017.
Imagine that you’re on an oil platform in the North Sea. Strain gauges in a drill tube detect metal fatigue and automatically start the process of replacing the tube.
Or imagine that you’re looking at an exhibit in a museum. Your smartphone knows which exhibit you’re at and automatically describes it. Move to the next exhibit; your phone automatically tells you about that one. Your phone also knows that it’s noon and suggests lunch. It also knows that it’s Friday, when the cafeteria offers a favorite dish of yours until 1 PM, and mentions that as an inducement.
Or imagine other scenarios where a computer can take action or offer information or assistance based on some context. That’s a large part of what Industry 4.0 and Information 4.0 offer. In this article, I’ll look at both but focus on Information 4.0 as being of primary interest to technical communicators.
What Is Industry 4.0?
Industry 4.0 is a model for factory automation and data exchange from Germany. (For an overview, see https://en.wikipedia.org/wiki/Industry_4.0 It’s based on the Internet of Things (IoT), AI, and the cloud, plus a new standard called iiRDS (International Standard for Intelligent Information Request and Delivery – https://iirds.tekom.de/) and RDF (Resource Description Framework from the Worldwide Web Consortium – https://www.w3.org/2001/sw/wiki/RDF), and other technologies.
The goal, to seriously oversimplify, is to create factories with machines that are self-governing through, in part, “context sensing”, like the drill tube that can detect metal fatigue and call for servicing on its own. For more examples, see “Context Sensing and Information 4.0” by Ray Gallon in the November 2016 issue of TCWorld at http://www.tcworld.info/e-magazine/content-strategies/article/content-sensing-and-information-40/
So What Is Information 4.0?
Information 4.0, according to its evangelists Andy McDonald and Ray Gallon, is the “…informational component of Industry 4.0”. (See https://www.linkedin.com/pulse/information-40-response-requirements-industry-andy-mcdonald.) (Andy and Ray have formed the Information 4.0 Consortium. Check it out at http://information4zero.org/.) Think of Information 4.0 as a conceptual umbrella for current and emerging technologies, either directly or peripherally related to technical communication.
Why does this matter to technical communicators?
For industry, Industry 4.0 is most important. And, as Adobe’s Stefan Gentz noted in a conversation with me at TCUK, what industry needs now is standards, protocols, and use cases.
Technical communicators are unlikely to create those standards, protocols, and use cases but we may be involved in documenting them. Doing so will call for familiarity with a vast range of new technologies.
Furthermore, we’re likely to use those technologies to document things outside the bounds of Industry 4.0. That will change technical communication the way word-processing did in the early 1980s and HTML in the late 1990s. That broad applicability of Information 4.0 is why it’s the focus of this article.
Characteristics of Information 4.0
Its evangelists postulate that Information 4.0 content will have six primary characteristics.
- Molecular – Replaces documents with “information molecules” that can assemble themselves into “compounds” based on a “state vector”.
- Dynamic – The context may change so the information molecules must change too.
- Offered rather than delivered – Information is available as needed but not pushed on the users. (Think of a dynamic help system that’s always available but discretely tucked into a corner of the screen.) Also, because it’s hard to predict what information users might need and whether users have the background knowledge needed to understand a particular molecule, we may need to create different molecules containing different versions of the information.
- Ubiquitous – Information has to be available everywhere, and has to be searchable.
- Spontaneous – Information has to display based on the context of the information requests.
- Profiled automatically – Information has to fit
user’s needs as closely as possible rather than being generic.Are these characteristics implementable today? Here are some of the issues.
Think of molecular content as topic-based authoring taken to extremes. “Fragments” of information are available at any given moment to fit the context of requests for information. This will boost the number of files.
But as the number of files increases, so do the hardware and software requirements – more RAM, faster hard disks, and faster networks. Can your tools and networks cope with huge numbers of files or will you have to upgrade your hardware or tools, or change tools? (And the definition of “huge” is subjective. I meet many people who have five-hundred files in a Flare project and consider that huge. The largest I’ve ever worked on had 176,500 files. The largest I know of is close to 900,000.)
As the number of files in a project grows, so does the need for project management rigor. The need for a project description becomes crucial. Even simple things like file naming conventions have to be defined and followed with no deviation. Without these and similar steps, the work may go out of control.
Assembly into compounds will make extensive use of metadata. Current tools offer some metadata, like conditional build tags, but the Information 4.0 metadata will have to be open source, such as RDF. That will add a new and unfamiliar requirement for authoring.
The “state vector” that drives the assembly process is a set of temporary context-states – an advanced form of today’s context-sensitivity. Somebody or something will have to define and maintain them.
Is it feasible today? Yes, in a limited way. Today’s tools support topic-based and fragment authoring, but not in the numbers needed by Information 4.0. Also, molecules and fragments created by today’s tools are meant to be combined into one output rather than live on their own. That may change how we create those molecules and may lead to machine-created content and AI.
The molecules will have to be continuously updated to match changing state vectors, effectively in real-time. Furthermore, the molecules will have to be in open databases rather than stored on authors’ local PCs. It also means that compilation becomes a bottleneck in some cases because users may not want to wait out the compilation time, just as users don’t want to wait out slow-leading web sites today.
We’ll also need fast, reliable network access to send the context state to the processor and the updated molecules back to the user quickly. There will also need to be some local storage for situations where network access is slow or nonexistent.
Is it feasible today? Yes, in a limited way. Current tools are starting to let us metatag content but that’s still in an early stage. Current tools will also have to create fragments that don’t contain tool-specific codes that may not work in an open standard environment. (MadCap Flare does this with its Clean XHTML output.) Our tools will also need to support local storage.
Offered Rather Than Delivered
Breaking information into the smallest possible molecules. However, defining the parameters of those molecules and creating them using traditional writing methods may not be fast enough. We may need machine-generated content.
Is it feasible today? Yes, in a limited way. The biggest bottleneck is the need to create molecules rapidly enough.
The molecules have to be available from anywhere and searchable. HTML5’s responsive design allows ubiquity across multiple devices and platforms. SEO (search engine optimization) increases searchability and findability. However, the need for ubiquity and findability rules out hard-copy outputs, perhaps even PDF. This will be a wrenching move for many companies today.
Is it feasible today? Yes, to a surprising degree. Responsive design lets us create one output that runs on multiple devices rather than having to create one output for each device. But the compilation time may be longer than users are willing to wait.
The “contexts” that trigger spontaneity are more advanced forms of today’s context-sensitive help. They might include device orientation (how users hold the device), location detection, external states like temperature, and more. The contexts have to be sent to the processor to let it alter the information to fit the context. This requires methods of context detection, metadata (again), plus fast networks to get the new content back to the user fast enough to make it useful.
Is it feasible today? Yes, in a limited way. We’ve been creating context-sensitive help since the dawn of online help. What we don’t have in the technical communication world is the spontaneous side, where information might change dynamically as the context changes. For that, we have to look to the web and mobile app worlds. Once online help went from RTF to HTML in 1997, technologies from those worlds have been available to technical communication projects but I’ve almost never seen them used.
User profiling will be done automatically based on the context, again requiring major and continuous use of analytics.
Is it feasible today? Yes, in a limited way. We’ve been able to create targeted online help for years using conditional build tags and placeholders like variables and snippets. The problem is that we can’t create the output dynamically. Instead, we generate a fixed output for user A. To create an output for user B, we change the conditions and placeholder values and regenerate, which adds a delay. Our online help projects have offered search capabilities for years but I rarely encounter companies that save and use the search data. I have never encountered a company that uses that search data to automatically update and regenerate the material. (If your company does, please contact me.)
How Will It Affect Tech Comm?
Here are some of the more obvious likely effects.
- We won’t write documents. Instead, we’ll do single sourcing with a twist – creating information molecules that can stand on their own as well as being combined into larger outputs. This may affect users of document-oriented tools like Word and FrameMaker the most. (We can use those tools to create molecules – e.g. topics – but many authors will find true topic-focused tools to be more convenient.)
- No more traditional continuity – e.g. no more writing “as described above” because “above” may now be in a separate molecule.
- No more local formatting since local formatting will probably break automated processing tools that look for styles.
- The need to structure content organizationally, using templates, but also semantically using metadata.
- Dealing with dynamic wording. We say “click the button” when writing for large screens but “tap the button” when writing for mobile. What do we do when using responsive output to that runs on both large screens and mobile devices? One answer today is to use an intermediate word like “select” but that doesn’t ring true to desktop or mobile output. There are ways to alter wording dynamically using CSS, which should spread as more authors start creating responsive output but they’ll have to work in the code until our tool vendors start to support it. Which will call for greater facility with…
- We’ll need more technical skill. We’ll have to be familiar with, or more familiar with, metadata, CSS, networks, and the other technical communication technologies mentioned above.
- We’ll need familiarity with technologies and standards from outside technical communication, like iiRDS and RDF.
- We’ll need to follow good coding practices and standards.
- We’ll need up-to-date tools.
- And we’ll need formal training in how to use those standards and tools. Peer-to-peer training is common but too often simply passes bad practices on from one generation to the next.
- Nobody cares about “documentation”, but “content” is cool, possibly even a revenue generator and/or a branding mechanism. This may help technical communicators become more of a force within the company by changing the company’s perception of tech comm.
- We have to stop trying to block new technologies in technical communication. Someone in an audience once responded to my discussion of social media by saying “over my dead body.” The technology will still go ahead, but around her, as her career has dead-ended.
Four Major Issues on the Business Side
You may be thinking that all this sounds interesting, with the promise of challenging work and new lines of work. But Information 4.0 will have to overcome four business hurdles.
- Does it support my company’s strategic and business direction? If it does not do so, in ways that are clearly and quantitatively demonstrable, it either won’t be funded at all or will be a quickly-forgotten one-off.
- Does it have high-level management support? Even if Information 4.0 supports the company’s strategy and business, other initiatives within the company probably do as well. Only the ones that get management support will survive, or at least have a chance to survive.
- Does company culture support this higher technical complexity? The answer is often no. Trying to force Information 4.0 into an unsupportive culture will cause turnover in the documentation groups; you’ll get people who are comfortable with the technology but lose people who have the experience and the institutional memory.
- Are goals and terms clearly defined within my company? As silly as this sounds, it’s very possible that people in your company, especially management, may not understand the terms we take for granted. They may also not have any clearly defined goals for an Information 4.0 initiative. Any Information 4.0 initiative is going to require an educational component on your part.
There are other business issues, plus technical ones. See my blog at http://hyperword.blogspot.com/ for periodic updates on Information 4.0 issues.
Much of Information 4.0 still conceptual, but it represents a continued increase in the technical side of technical communication, and offers multiple paths forward for tech comm in the years ahead. It’s worth watching.