Technical Communication Poll: How Is Ubiquitous Computing Changing Tech Comm?

Something else- similar to the marketing line that “the package is the product”, UI will become the new documentation. Gone will be the days of separate manuals and help files. UI will need to become self explanatory. I also foresee a generation that is way more technically knowledgeable and does not have to be spoon-fed instructions. The impact on doc is hoping up be tremendous- are we ready?

First let me say that ubiquitous computing in toasters and toilet seats is fine but let’s not kid ourselves. Computing will not devolve into only household appliances. The tech writing for that would be painfully dull, if necessary at all. I hate toasters and microwave ovens. But considering domains where we need real and interesting information…

In the short term, we will see dynamic, distributed documentation. Just like topic-based writing produces a collection of self-sufficient topics that can be collected into topic sets for different hierarchies and/or webs, topic sets will be stand-alone and will combine into different hierarchies and/or webs. The current “application” will be a mashup of many apps, all of them interacting via APIs. Likewise, the current documentation will be a mashup of many doc sets, marshaled by the point of entry that you choose (or stumble on) as you exploit services in a given domain.

Obviously, this documentation cannot be static. It cannot be centralized either, because people will be shuffling mashups around like decks of cards. So the current push toward centralized doc servers is a way to get dynamic and social, but it can’t last. Each service will have its own doc set, and the combination of the day will merge these doc sets into a coherent whole. Whichever entry point you choose will include the capability to dynamically marshal the constituents. But the constituents are distributed, and live with the services they describe.

Some people might say this content will be generated apart from the given service… Social content that is created by a community of users, and just floats out there in the Web. There will probably be that component. But different service domains will have different social boundaries. Not everybody will have access to the services that manage your cable data delivery, or the IRS, or health insurance management. Just as we have always had social boundaries, cliques, and private clubs, so we will (erm, we do) in terms of information. Distributed dynamic doc systems will also marshal dynamic and distributed social content. But there will still be a need for *authored* and *edited* content, especially for the more specialized info-clubs… Every club needs its charter.

In the longer run, this dynamic distributed documentation will evolve into semantically aware systems that can answer questions. And these dynamically assembled mashups will include a concept of information boundaries. In other words, a given dynamically assembled information domain will know how and when to say “I don’t know” — something many people find difficult, let alone automated information retrieval systems. So you will ultimately be able to ask, “How do I X?”, or “When should I Y?”, or “Why should I Z?”. What is developed as mere documentation will assemble itself and be able to answer those questions.

I’m working on the first step for this, BTW… 4-D Pubs — Distributed Dynamic DITA Display. The hooks for Distribution are in place, and I have the Dynamic part well under way — it’s integrated in a product as we speak. I’ll be presenting it at the UA Europe conference this June 13-14.

I definitely agree that the line between doc and GUI is blurring. And that level of documentation should diminish, if not go away altogether. But that leaves room for other documentation… When, why, where, who should do X? And also, explanations of what the service is actually doing. Not everybody wants an iTunes world where you can only listen to music if you follow the exact work flow determined by Steve Jobs. Most people who invest in a system or in the knowledge to use a system also want to know how your service will interact with that system.

So definitely, tech writing will be much less about instructions and procedures. It will be much more about concepts and domain knowledge.

In the end it is all about latency. It is about the time and distance that separates me from the information I need.

When you live in a high latency environment, you plan, prepare, and act differently from if you live in a low latency environment. Thus if you are going hiking in the wilderness, you carry a backpack with everything you need to eat, sleep, dress, and treat minor injuries, because you are going into an environment with high latency for all those things. But if you are taking a stroll down town, you don’t carry any of those things because you are in a low latency environment where those things are all readily available. (A related blog post: http://everypageispageone.com/2012/12/17/desert-island-docs/)

In the age of paper, we lived in a high-latency information environment most of the time. We had specific institutions for achieving relatively low information latency — libraries and book stores — but we could not spend all of our time in them. And even in those places, the latency was still high because while there was lots of information available, it was hard to sift through it to find what you needed, and much of it was very out of date, with no easy way to tell if it was still valid, or whether or not it was actively disputed.

Ubiquitous computing means that we will all be living in a low latency information environment all the time. It means that the social institutions we have created for dealing with information latency, such as the User’s Manual, will become obsolete. It means that if your function is to mitigate the latency of information (such as planning, assembling, editing and formatting the user manual), as oppose to directly providing it, then your function will become obsolete unless you find a way to reduce latency still further in the networked world.

I think professional communicators still have a role in a low information latency environment, but it will be substantially different from what it was in the paper age, and its focus will have to be on reducing information latency levels to what users will accept in an always-on, always-connected world.

John Pavlus published an interesting take on this last week in the MIT Technology Review. “Your Body Does Not Want to Be an Interface” (http://www.technologyreview.com/view/514136/your-body-does-not-want-to-be-an-interface/) discusses how people want tools to be ready-to-hand rather than present-to-hand. Technical communicators who are (or will be) in a position to create user support via wearable, ubiquitous computing should keep in mind that people don’t really want to to think about the tools they’re using as a separate entity, they want them to be an extension of themselves to help them do a job. Do I really want to think about whether I’m selecting something when I blink? Can’t I just blink? I’m not sure it would be healthy to be in high latency mode all the time, any more than I want to be connected 24/7.

Not every product is a consumer product, and not every user is sitting at an internet connected device when they use the products we write about. A lot of technical writers – I’m one of them – work in engineering, automotive, aerospace, and defence sectors rather than in software or services or consumer electronics. While the devices I write about contain lots of sophisticated electronics and idiosyncratic interfaces, they aren’t and never can be connected to the web, and their users cannot, for operational reasons, get online while they are using them either. So in my case ubiquitous computing has no impact, at least for the time being. It is quite possible that in the future the connectivity of complex engineering products may change, and I am quite sure that because of the presence of ubiquitous computing in so many other fields the expectations of users are already changing.

David,

It is certainly true that the Web, and Web connectivity are not quite ubiquitous yet. But consider how much more ubiquitous they have become over the past five years. Five years ago if you wanted to keep your employees off the web, you can simply firewall it off. Today, you would have to either confiscate their smart phones at the door or jam their signal. How many of your users now have smart phone (and therefore, the Web) in their pockets while they work?

There will, of course, always be come niches that are deliberately kept off the Web. But we are already at the point where you have to deliberately keep people off the Web if you don’t want them on it. Failing to provide access does not cut it anymore. You now have to actively block it. Once you have to deliberately have to take measures to keep something out, it is effectively ubiquitous.

But equally important today is that, whether it is completely ubiquitous or not, the Web, and its methods, are now the cultural default. Even when we are not on the Web, we expect things to work like the Web. That effects how people seek and consume information even when they are not on the Web, and that profoundly affects how you create information even in non-connected environments.