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?
Think Mobile When You Write
Always keep the small screen in mind when you’re preparing your docs. There are some W3C “mobileOK” guidelines to consider to ensure that your content meets requirements. Here are some highlights:
Tables
- No nested tables
- Tables must have more than one row and more than one cell per row
Page Titles
- There must be a Title element in the Head section, and it must not be blank.
Frames
- No frames. These don’t work well for search engines anyway, so it’s best to avoid them.
Images
- No image maps
- Images must have height and weight measurements, and they must be in pixels
- Images must use alt tags, and there must be text in the tag (not blank)
- Transparent graphics for spacing: no large ones
These are just a few items. There’s enough, though, to consider. When you plan your content, think mobile.
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.