Might We Become Walking Computers?
What do an article in Wired magazine about attaching a sensor to your running shoe and uploading it via iPod for data analysis, a camping trip, an article about wearing video screens, a scientist husband, a discussion about wildlife parks, office work, and work by a W3C working group have in common? If you can bear with me for a moment, I’ll tell you.
We’re going to turn into walking computers. That’s what I think. This will enable us to leave cubicles and exist in our natural habitats – sans clunky laptops and the like. Crazy idea? Perhaps. Now for an explanation: here is how all this fits together (in my mind, at least).
First, a short while back I found the article on Technology Review about video screens on clothes (There’s a post about it on this blog: Use of Flexible Screens in Documentation.) Development is underway for video screens that can be “worn on wrists, and plastered on clothes.” Ok. So that’s the computer-on-clothes aspect of this.
Second, the Wired article is about how Nike and Apple have developed a sensor that you can hook on your sneaker and which uploads information about your run to the iPod you’re wearing, and you can access the data via iTunes and Nike. That’s more of the computer-on-clothes aspect, but which goes one step further: uploading data.
Third, on our recent camping trip at a lake, there was a duck family that swam around each day right by our campsite. They were in their natural habitat. My husband, in his work and in the group with which he works, focus on natural habitats. We had a family discussion at dinner the other night about wildlife parks and zoos, and I said I preferred to see creatures in their natural habitat. That made me think about office work and cubicles. Nobody likes cubicles. We would all prefer to be in our natural habitat – and an office doesn’t fit that description. Our lake campground was close to a resort town, so we saw many people in town in their natural habitat – one where they could have fun. Everyone was in casual clothes. Not a suit in sight.
Fourth, just yesterday I came across information about a W3C VoiceXML working group. I didn’t know that there was such a thing. Is there a future where one will be able to talk and have some data somehow uploaded somewhere? I haven’t read it in detail, but just the thought of it has my imagination running wild.
So here it is, all wrapped up: maybe we’ll be able to leave offices and work in our natural habitats (whatever or wherever that may be) and wear computers on our clothes, sneakers, and who knows what else, upload data via devices such as the sensor/iPod scenario, use VoiceXML for processing, and download videos and info onto our sleeves. Perhaps this could all be powered by using Velcro to strap a solar-panel strip on said sleeves. Who knows? Who needs a laptop when you just need a shirt, some sneakers and an iPod, and a mobile phone gizmo in your ear?
Let’s Reinvent Technical Writing
More and more, I think it’s time to discard main approaches to tech writing and come up with new methodologies. The world and technology is changing so much that I think it’s time to start fresh. Just as sometimes when you’re working on a sentence and you tweak it and change it, but it’s still not quite right, and you finally just drop it and come up with something different. Perhaps it’s time to drop existing methodologies and develop something new instead of trying to tweak what’s there to fit what’s happening now. Perhaps the old methods no longer work.
The old print book model won’t do any longer. While I realize that there has been movement away from that for a while, I think that more is needed.
Let’s toss everything out and see what we can develop. Let’s use the modes of delivery that are out there now and pretend that books and their chapter formats don’t exist, online or otherwise – and that screens will remain small. Let’s cut content even shorter (using the 140-character limit in Twitter as an example). Let’s think more about how people are going to create and access content and plan accordingly.
More and more, I think that databases are key. So I’m going to start a section about that. It’s time to move forward.
A New Doc Strategy
In years past, a doc strategy was fairly straightforward: prepare print documents that were either in binders or printed into a book. Then came online help, so both were used. Then PDF was added as an option. For many, that’s as far as capabilities have progressed.
The new reality is that technology is rapidly changing and different methods of access are popping up all the time. Print and PDF, to some degree, are going to fade away. Some sort of online version will endure, but it won’t be what we’re accustomed to.
To wit, here’s yet another example of new technology: bendable, paper-thin screens and mobile device screens that “roll out” to a larger size.
http://www.technologyreview.com/computing/22232/?a=f
http://news.cnet.com/8301-10784_3-9891347-7.html
How cool is that? And how will it affect or impact overall documentation strategy? If you’re developing for mobile access, but the screen can enlarge, but is likely still smaller than a desktop screen, how do you design your docs for all?
These are the sorts of questions that will continue to arise. The simple days of print, online help, and PDF are gone. The idea of a “document” may even fade away.
If I were developing a doc strategy today, I would have the following elements, at the very least:
- Use xml and databases to produce content that can be accessed over intranets and the Internet, including portals such as SharePoint
- Design for mobile devices
- Use online forms to set up docs so that they can be directly input to a database
- Use content management strategies to review, design, and write content accordingly
- Set up video libraries (such as YouTube)
- Use Twitter for tech support and to push information and updates to users
XML – XSL Programming Features
In case you’re pondering whether or not to shift your docs to XML, here is another reason to do so.
One great feature of XML is the ability to incorporate some programming functionality into your docs. For instance, you can set up your XSL file to include some if..then and loop processing. You can set up attributes in such a way as to facilitate this processing.
One example is an attribute for, say, a “vegetable” element. The XSL file could contain a choose and when instruction to review the attribute, and if the attribute is “potato,” then display a specific picture of a potato.
For loop processing, you can use the for-each instruction. This is particularly useful for tables. Instead of building a table in HTML with content hard-coded in each row, you can build an empty table in your XSL file along with for-each instructions to populate it with content from your XML file. For example, let’s go back to the vegetable content. Imagine that you have two vegetables: potato and lettuce. For each of those, you have two types. For potato, it could be russet and red; for lettuce, it could be romaine and iceberg.
When you use for-each, you can essentially say (in this case): take the first vegetable and its two types (the nested elements), and put it all in one table row. Then go back and select the next vegetable and types, and put it in the next row. This continues until all the elements (potato, lettuce, etc.) have been transferred to the HTML table. If content changes are needed afterward, you can just update the XML. The HTML is part of the XSL file, so wouldn’t be changed.
In any case, more options are available to set up your docs with more flexibility and processing features when you use XML.
Why Tech Writers Should Know Database Design
IMO, all tech writers should know the basics of relational database design. Colleges should incorporate it into tech writing programs. I’m convinced of it. Why? I had worked for many years as a tech writer before taking a database design class, and have continued to work in that capacity for a number of years (and still counting) afterwards. It makes such a difference that I put it right up there as one of the basics that all tech writers should know.
After taking the class, I was able to make UI usability suggestions (a column in a table didn’t need to be on the screen; I realized that because I knew how tables work in databases). I was also able to decipher some error messages during dev because I was familiar with database lingo. Granted, I’m no DBA, but my limited database knowledge made a difference. Portions of the specs were also more clear. Most of all, though, I could see how understanding of database design and operation made a critical difference in setting up docs.
Planning docs from a database design viewpoint definitely adds another layer of complexity and time. However, it’s worthwhile. Your docs will be easier to maintain and share.
Databases, of course, have tables. The tables have rows of records. The database also has normalization requirements to ensure that data is broken down to its lowest common denominator. You don’t want redundancy; you don’t want to enter or update information twice.
For example, if you have a tag in your XML called “Name” and it includes first and last name, it could be trouble. If you have a database table for names and a separate record for first and last name (not one that includes both), the XML data won’t import well into the database. It’s better to have two XML tags. For instance, something like individual “FirstName” and “LastName” tags within a “Name” tag would work well. Then, the database table could be called “Name” and have two records: FirstName and LastName. The data would transfer back and forth between XML file and database without much difficulty.
To go one step further, let’s say that you have a database table with FirstName and LastName records. It’s also a good idea to have the XML file use the exact same name. If you use “First” and “Last” in your XML file and the database has FirstName and LastName, then you could have trouble. Match them up! Make your life easier.
These are some very basic examples of considering database design when setting up xml and xsl files. By knowing how databases work, you can name and arrange your XML tags in such a way as to facilitate import and export to a database. After all, the content in an XML file is data. Once you get that XML into a database, you can access it in varied ways. This includes web pages, reports and portals. That, however, is another story for another day.