Tuesday, January 19, 2010
The Augmented Future of Technical Documentation?
For those of us who have written, or write, technical documentation for hardware, and engineering products, this video of a BMW research project perhaps gives a glimpse of the future.
And BMW are not alone, a quick search online produced videos of several different prototypes of using Augmented Reality for maintenance, service and repair procedures.
This type of development, once again reinforces my message that technical writers need to step up and become technical communicators comfortable with developing content that can be delivered in any media.
Technical documentation is not just about the written word, it is about the communication of ideas and knowledge.
And BMW are not alone, a quick search online produced videos of several different prototypes of using Augmented Reality for maintenance, service and repair procedures.
This type of development, once again reinforces my message that technical writers need to step up and become technical communicators comfortable with developing content that can be delivered in any media.
Technical documentation is not just about the written word, it is about the communication of ideas and knowledge.
Monday, January 18, 2010
Hello Publishing, Meet the other side of Publishing
Over at the TeleRead blog, which reports on trends in the growing eBook market, editor Roger Sperberg recently posted a piece entitled "Why Do Publishers Need XML?" in which he thoughtfully examined the advantages that traditional book publishers could benefit from by adopting an XML mark-up.
I won't reiterate his arguments here, most of which I agreed with, and suggest that instead you go read the article.
However one statement really caught my attention, Sperberg's suggestion that book editors should learn XML as part of their job. His statement was that
At face value a very valid point, but as I read through the article and the various comments attached to it, I suddenly realized there seemed to a complete lack of awareness that those skills already exist within a profession that understands a bit about publishing.
Here's a little extract from my own comments.
I won't reiterate his arguments here, most of which I agreed with, and suggest that instead you go read the article.
However one statement really caught my attention, Sperberg's suggestion that book editors should learn XML as part of their job. His statement was that
"...that we (book publishers) can’t exploit (eBooks) until editors understand XML as well as English grammar, and regard metadata as valuable as a plug on Oprah."
At face value a very valid point, but as I read through the article and the various comments attached to it, I suddenly realized there seemed to a complete lack of awareness that those skills already exist within a profession that understands a bit about publishing.
Here's a little extract from my own comments.
"As for asking editors to learn XML, sure they need to be aware of it and its power – but there is a whole profession of people out there who already know about applying XML mark-up to content – the Technical Publications industry. Oh and a lot of them know about XSLT and XSL-FO too, and are skilled in the tools that use these standards.And believe you me, for people who have spent years tagging things like aircraft manuals and software user guides, tagging a trade mass market book is not too great of a challenge."
It is often said that traditional book publishing is dying, and a large part of that is because traditional publishers still see the physical book as the product, and not the content. But today content is king, and we need to make that content available across all platforms, and that means mark-up.
Does the salvation of the book publishing industry reside in the world of technical and business publishing? - It just might...
A short commercial...
Join me at 1:00pm ET on Wednesday (Jan 20th) when I present a live webinar on 'What Technical Communications Can Learn From The Comics."
Register HERE.Sunday, January 17, 2010
This Week in Wikis - Week 2
Another round up of interesting links and articles about wikis found while I continue to work on my upcoming book "WIKI: Grow Your Own for Fun and Profit."
Week 2
Week 2
- Writing in the Open: Using Wikis to Create Documentation
- Wiki Cheat Sheets
- Wikis? A meme? It’s more likely than you think.
- A Wiki Isn't A Character From Star Wars
- Motor Sports organization uses wiki to write a new rule book.
- An Indian view of Wikipedia and wikis in general .
- W3C - Semantic Web Standards wiki
- The Independent Publishing Wiki
- Collaboration requires a culture of comfort
- ToyPedia - wiki for Toy Collectors
- Mashup of Wikipedia and Google Maps - don't just read about an event - see where it happened.
- Fact or Fiction: Should You Use Wikipedia for Research ...
Sunday, January 10, 2010
English as She is Spoken - it can be difficult at times.
Earlier today, The Content Wrangler, Scott Abel, posted the following on his FaceBook page:
[English Lesson du jour] Leonard Lunsford says the letter combination "ough" can be pronounced 9 different ways. The following sentence contains them all: "A rough-coated, dough-faced, thoughtful ploughman strode through the streets of Scarborough; after falling into a slough, he coughed and hiccoughed."
This sort of thing is a perfect example of why we shouldn't assume everyone in your intended audience understands the subtleties and nuances of the English language - particularly important if you are creating technical or business content for an audience who are not native English speakers.
As I mentioned to Scott - I will definitely be using this as an example in the Simplified Technical English training courses I run from now on.
Saturday, January 9, 2010
This Week in Wikis - Week 1
Welcome to a new feature on THE CONTENT POOL, "This Week in Wikis." - As I continue to work on my upcoming book "WIKI: Grow Your Own For Fun and Profit" I am reading and bookmarking numerous articles and online mentions of wikis, wiki tools and examples of wiki usage.
So I thought it might be useful each week to share a selection of wiki related articles I came across over the previous seven days.
Here's this week's selection:
- Wired's "How-To" Wiki
- CarbonCopyPRO Introduces New "Wiki" Marketing Platform,
- MobileRead Wiki on eBook technology
- Wiki on research for librarians
- Improved wiki usage in 2010
- How Non-Profits Are Using Wikis
- Wikipedia:Manual of Style
All the "This Week In Wikis" links will be archived, and available, at http://delicious.com/wikiweek
So I thought it might be useful each week to share a selection of wiki related articles I came across over the previous seven days.
Here's this week's selection:
- Wired's "How-To" Wiki
- CarbonCopyPRO Introduces New "Wiki" Marketing Platform,
- MobileRead Wiki on eBook technology
- Wiki on research for librarians
- Improved wiki usage in 2010
- How Non-Profits Are Using Wikis
- Wikipedia:Manual of Style
All the "This Week In Wikis" links will be archived, and available, at http://delicious.com/wikiweek
Comics in Corporate Communications
Is there a place for comics in corporate communications? I certainly think so, and have long been a vocal proponent of using comics graphic and story telling techniques in the business world.
Recently Scott Abel, industry leading consultant and blogger, offered me the opportunity to write about the subject on his CONTENT WRANGLER blog.
My two page article Comics Can Make You A Better Communicator is now up, and you can check it out simply by clicking HERE.
Friday, December 11, 2009
The GHOST MAP and THE SOCIAL WEB
Over the last few weeks I've been reading a fascinating book entitled THE GHOST MAP by Steven Johnson, that details the story behind the 1854 cholera outbreak in London and the efforts of a few men, including the physician Dr. John Snow, to isolate the cause.
Dr. Snow is perhaps most celebrated for developing the titular "Ghost Map" that (and this is simplifying the process) helped form a visual correlation between the number of deaths and the proximity of the contaminated water pump that turned out to be the root cause.
It's a fascinating book for anyone interested in social sciences, history, biology, and communication. A large part of the story discusses how Snow culled information from a variety of apparently disparate sources, some written, some verbal, and his own observations and bought them together to develop one of the most celebrated examples of technical communication and visual design of the modern age.
But the book itself has one great failing - it doesn't include a copy of the map! You know the map that is referenced in the title of the book? The map that has a whole chapter to it and to which the author constantly refers. A map that is in the public domain and widely available on the net. Yes THIS map.
Here is a great example of setting up a reader / user expectation and failing to meet it. The quality of the content in this book was excellent, yet the one thing I will remember most (and obviously decided to blog about) was that single point of failure.
So how does this relate to corporate communications - simply put - make sure that you deliver the content you promise - even if it's an implied promise. And titles are the first place you set up expectations of what's to follow. Make sure you deliver.
So to make sure I deliver on my promise, what does the Ghost Map have to do with the Social Web? In the later two chapters Johnson goes on to discuss the impact of Snow's work on science in general and the use of cartography in mapping social trends.
In that discussion on maps he makes the following observation:
An astute observation and not one that just applies to cartography projects, - it also applies to the changing face of corporate communications and social media. The day of the 'experts' being the sole trusted source of information. As Don Tappscott & Anthony Williams put it in their book Wikinomics:
In London in 1854 the experts inside the organization, i.e. the Government, were convinced it was the mythical 'miasma' that was killing people. It took informed 'amateurs' to identify the root cause and develop the documentation to prove their case.
Any organization today should be listening to, and encouraging, the participation of the smart people outside.
Imagine if Dr. John Snow had access to a wiki, or Twitter?
Dr. Snow is perhaps most celebrated for developing the titular "Ghost Map" that (and this is simplifying the process) helped form a visual correlation between the number of deaths and the proximity of the contaminated water pump that turned out to be the root cause.
It's a fascinating book for anyone interested in social sciences, history, biology, and communication. A large part of the story discusses how Snow culled information from a variety of apparently disparate sources, some written, some verbal, and his own observations and bought them together to develop one of the most celebrated examples of technical communication and visual design of the modern age.
But the book itself has one great failing - it doesn't include a copy of the map! You know the map that is referenced in the title of the book? The map that has a whole chapter to it and to which the author constantly refers. A map that is in the public domain and widely available on the net. Yes THIS map.
Here is a great example of setting up a reader / user expectation and failing to meet it. The quality of the content in this book was excellent, yet the one thing I will remember most (and obviously decided to blog about) was that single point of failure.
So how does this relate to corporate communications - simply put - make sure that you deliver the content you promise - even if it's an implied promise. And titles are the first place you set up expectations of what's to follow. Make sure you deliver.
So to make sure I deliver on my promise, what does the Ghost Map have to do with the Social Web? In the later two chapters Johnson goes on to discuss the impact of Snow's work on science in general and the use of cartography in mapping social trends.
In that discussion on maps he makes the following observation:
"The amateurs are producing the most interesting work, precisely because they have the most textured, granular experience of their community."
An astute observation and not one that just applies to cartography projects, - it also applies to the changing face of corporate communications and social media. The day of the 'experts' being the sole trusted source of information. As Don Tappscott & Anthony Williams put it in their book Wikinomics:
"There are always more smart people outside your enterprise boundaries than there are inside."
In London in 1854 the experts inside the organization, i.e. the Government, were convinced it was the mythical 'miasma' that was killing people. It took informed 'amateurs' to identify the root cause and develop the documentation to prove their case.
Any organization today should be listening to, and encouraging, the participation of the smart people outside.
Imagine if Dr. John Snow had access to a wiki, or Twitter?
Monday, November 23, 2009
Confessions of a Mark Up Junkie!
Hello my name is Alan, and I love tagging things.
It has been 15 minutes since I last tagged some text.
There I’ve said it.
A few days ago I came to the realization that I’m a tagging and mark-up junkie. I do it almost everyday, and I do it without thinking about it. I also never thought about the effect my tagging habit had on others, until a few days age when my wife complained about it.
I’ve been tagging for over twenty years now, SGML, XML, HTML, CGM and a multiple variety of typesetting tags and industry specific ones - I’ve used them all. For me tagging is as natural as using the Ctl+ keys to shortcut a menu.
I even used to have a t-shirt that proudly proclaimed:
But it's time I stopped assuming that others want to join me in this behavior.
What bought me to this realization?
In preparation for our upcoming house move, we decided to sell some of our books on eBay and my wife offered to help set up the listings. I walked her through the steps to sell an item online and all went well until it came to the part where you need to add an item description of the article.
Without thinking I just started applying 'p' tags a 'b' tags and even a few 'a href=' tags . She stopped and looked at me as is to say "What is all this nonsense?"
The feeling that I was perhaps doing something that may not be understood (or needed) by a large percentage of the population was further compounded by various comments and feedback on my article about "Wikis in the workplace" that was published on Ars Technica last week,
Several of the comments made the point that the biggest obstacle to wiki adoption was the perceived notion that you had to learn mark-up to write in a wiki. Whether this is true or not (and it isn't), the idea is out there.
One comment in particular caught me eye.:
While the comment may have been a little facetious, I take the point. I've written before about how we need to observe the way the next generation accesses information. Those comments made me realize that we should do the same for the way that information is created.
In the article I wrote:
Everyone is now used to the simplicity and intuitive look and feel of a simple word processor, be it MS-Word or Google Docs, and many other content creation tools, including most wikis, have also adopted the same approach. This is something we need to remember when we become enthused about a new technology or process.
I guess what I'm saying is that having a tagging habit is fine, (and in some circumstances it is a very valuable skill), but it should be exercised when it's needed. When dealing with your audience, customers and general users don't jump in to showing them how clever you are; think about what will make their lives and project easier.
Don't let the technology and techno-babble get in the way.
==============
As an aside - this is the first post on The Content Pool blog not hand coded with HTML tags but written using the in build rich text editor.
================
It has been 15 minutes since I last tagged some text.
There I’ve said it.
A few days ago I came to the realization that I’m a tagging and mark-up junkie. I do it almost everyday, and I do it without thinking about it. I also never thought about the effect my tagging habit had on others, until a few days age when my wife complained about it.
I’ve been tagging for over twenty years now, SGML, XML, HTML, CGM and a multiple variety of typesetting tags and industry specific ones - I’ve used them all. For me tagging is as natural as using the Ctl+ keys to shortcut a menu.
I even used to have a t-shirt that proudly proclaimed:
WILL TAG FOR BEER
But it's time I stopped assuming that others want to join me in this behavior.
What bought me to this realization?
In preparation for our upcoming house move, we decided to sell some of our books on eBay and my wife offered to help set up the listings. I walked her through the steps to sell an item online and all went well until it came to the part where you need to add an item description of the article.
Without thinking I just started applying 'p' tags a 'b' tags and even a few 'a href=' tags . She stopped and looked at me as is to say "What is all this nonsense?"
The feeling that I was perhaps doing something that may not be understood (or needed) by a large percentage of the population was further compounded by various comments and feedback on my article about "Wikis in the workplace" that was published on Ars Technica last week,
Several of the comments made the point that the biggest obstacle to wiki adoption was the perceived notion that you had to learn mark-up to write in a wiki. Whether this is true or not (and it isn't), the idea is out there.
One comment in particular caught me eye.:
I don't know anyone under 40 who will use a wiki at work. The mark-up language is a deal breaker.
While the comment may have been a little facetious, I take the point. I've written before about how we need to observe the way the next generation accesses information. Those comments made me realize that we should do the same for the way that information is created.
In the article I wrote:
Technology geeks need to realize that many of the ideas, features and functions that get us excited and turn us into early adopters of new technology can intimidate the average user to the point where they will be scared off and not use a solution no matter how beneficial it may be.
Everyone is now used to the simplicity and intuitive look and feel of a simple word processor, be it MS-Word or Google Docs, and many other content creation tools, including most wikis, have also adopted the same approach. This is something we need to remember when we become enthused about a new technology or process.
I guess what I'm saying is that having a tagging habit is fine, (and in some circumstances it is a very valuable skill), but it should be exercised when it's needed. When dealing with your audience, customers and general users don't jump in to showing them how clever you are; think about what will make their lives and project easier.
Don't let the technology and techno-babble get in the way.
==============
As an aside - this is the first post on The Content Pool blog not hand coded with HTML tags but written using the in build rich text editor.
================
Tuesday, November 17, 2009
Wikis in the workplace: a practical introduction
When times get tough and belts get tight, one of the first things many companies do is begin casting about for ways increase efficiency and raise per-worker productivity. Many businesses turn to free and open-source tools to meet these needs, and at some point in such discussions someone invariably suggests a wiki for some internal project. But the wiki idea often gets rejected soon after it's floated, typically because wikis are perceived to be insecure, inaccurate, or difficult to use; either that, or someone in the discussion has gone the wiki route before, only to see their wiki languish from lack of interest and participation.
These perceptions and experiences that lead companies to reject wikis are rooted in a common problem: the vast majority of the public has formed 100 percent of their expectations about what a wiki can and should be based on the single example of Wikipedia. Few have ever seen wikis used creatively and successfully in a real-life business context, so even when IT professionals attempt to implement wikis in their own companies they lack real experience and good examples to imitate.
As someone who's currently writing a book on wikis, I've talked at length with a number of different organizations about the wiki's role in their business. In this article, I'll share with you some of what I've learned about wikis in the real-world by taking a case-study approach to describing how and why a handful very different organizations are successfully using wikis. After seeing the kinds of things that are being done with wikis, you might be motivated to give the technology a second look.
Read the rest in my article on the Ars Technica website.
These perceptions and experiences that lead companies to reject wikis are rooted in a common problem: the vast majority of the public has formed 100 percent of their expectations about what a wiki can and should be based on the single example of Wikipedia. Few have ever seen wikis used creatively and successfully in a real-life business context, so even when IT professionals attempt to implement wikis in their own companies they lack real experience and good examples to imitate.
As someone who's currently writing a book on wikis, I've talked at length with a number of different organizations about the wiki's role in their business. In this article, I'll share with you some of what I've learned about wikis in the real-world by taking a case-study approach to describing how and why a handful very different organizations are successfully using wikis. After seeing the kinds of things that are being done with wikis, you might be motivated to give the technology a second look.
Read the rest in my article on the Ars Technica website.
Subscribe to:
Posts (Atom)
