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:

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.

================

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.

Irony, Thy Name Is Webinar!

Last Thursday evening, while wearing my WebWorks hat, I was happy to deliver a presentation to the fine folks from the North East Ohio chapter of the STC. The title of my presentation was “Why Publishing Is No Longer The Last Step.”

If you scroll through the slides in the embedded copy of the presentation below, you can see that the main theme I was talking about was feedback and how we should both encourage and embrace user participation in the publication process. In fact one of the points I was making was that feedback, user participation and collaborative authoring, while they may all be current buzz words, aren’t anything new. They have been a part of the publishing process for as long as we have been telling stories. It’s just that the technology has changed. In fact it could be argued that modern technology is an enabler that allows us to capture and process feedback even quicker.

Why Publishing Is No Longer The Last Step

View more presentations from WebWorks .

BUT…

When I got home my wife asked how the webinar had gone, and I had to admit that I wasn’t 100% sure. The reason for my lack of certainty? Missing feedback.

Yes a few people had asked questions, and I had received a nice round of applause at the end of my presentation, but delivering the presentation over a combination of WebEx and phone meant I had no visual feedback. I didn’t now if silence meant that people were enthralled, bored, or had all snuck off to the pub!

Anyone who has seen me present will know I like to walk around. I talk with my hands a lot, gesticulate, point. I also like to try and engage the audience, ask questions, crack stupid jokes and make the occasional pun. But perhaps the biggest part of presenting for me, and the main reason I enjoy doing it, is being able to interact and engage with individuals in the audience.

Visual communication and body language provide essential feedback, and in this instance using enabling technology robbed the experience of one of its most vital layers of communication.

Virtual meeting tools and conference calls can be great cost savers and allow events to happen that otherwise might not occur – but even in today’s social network obsessed, web driven world, nothing beats being face to face with a real live person.

Technology should enable conversation, not get in its way.

Working Out With On-Line Help

For my birthday last month my family decided to buy me the Beatles Rock Band video game, an appropriate gift given my long standing interest with in the Fab Four. But I'm not really a game player and didn't have a game system, so we also decided to purchase a Nintendo Wii and the Wii Fit package to go along with the present.

While I really enjoy the Beatles Rock band, I have become somewhat addicted to the Wii Fit (with positive results on my overall health and posture), and feel like I'm missing something if I don't spend at least a few minutes each day doing at least a few of the exercises.

While working out one morning last week, I had a revelation of the Technical Documentation kind - I suddenly realized that I was in fact working out using what amounted to the Wii Fit's on-line help system.

There is nothing that we would label as traditional on-line help, no Help menu item, no F1 button to press and no self contained documentation - but it has Help all the same.

When you start a new exercise the virtual trainer immediately gives you a demo of the exercise. But just that once, after that it' an option available at the start if you want to refresh your memory.



And note how the Wii Fit uses a simple star system to give you feedback on how well you have done that task in the past - a simple, effective and intuitive feedback loop.

Once you start working on an exercise or task the trainer shows you the moves but also adds step by step instructions with using visual (movement and graphics), audio (voice) and text (on screen instructions).




I have also noticed that as you get better at a task and move up the levels, it makes assumptions on skill level and delivers less basic information. i.e it tracks your usage of the system.

What I am getting is the correct information to complete a task at the point I need it.

I do not have to go find Help on how to do something - the Help finds me as I do a specific task.

As I mentioned in an earlier post, watching my teenage daughter do her homework made me think about the way we need to redesign content structure, so my introduction to video games has made me rethink the way we should be delivering on-line assistance.

Why are we once again force fitting the book paradigm into software assistance and electronic delivery.?Integrated context sensitive help shouldn't just mean that I get a "topic" or "Chapter" when I hit the F1 key - it should mean that the software delivers the information I need at the point I need it based on what I'm doing and how many times I've done it before.

(Apologies for the quality of the photos - took them this morning with my iPhone after I thought about doing this blog post.)

Missing one small (but vital) step

As anyone who has heard me speak recently will be aware, I'm a big fan of providing minimalist documentation that helps answer the basic question - "HOW?"

How do I make this work?
How do I connect this?
How do I complete this task?

But when I say minimalist, I don't mean badly designed or written - in fact I would argue that the sort of documentation I advocate needs to be better written and designed than the traditional 'owners manual' approach.

In a recent tweet, well known industry consultant, Scott Abel posted

Most people don't want a user manual; they want usable, managable instructions for the task they are doing.

I totally agree.

I often cite a slim 16 page booklet that I received as part of a network router package as one of the best designed pieces of documentation I have ever used as it combines, good use of language with color, simplified clear illustrations and even the physical design of the booklet to quickly and simply answer the question of 'How do I connect this thing up and get my wireless network running?'



Then last night I ended up installing a different wireless router from another manufacturer, which on the surface appeared to be taking a similar, minimal documentation route, but with not quite the same results.

This new router was shipped with no printed documentation, just a CD in a paper sleeve with the words "Start Here" emblazoned on the sleeve.

Once installed a couple of clicks opened up the installation guide - a short, well illustrated, 5 page document.

Looking good so far - but then I scanned down to read the instructions, and saw this.

1. TURN OFF YOUR COMPUTER.

mmmm - see the problem?

You only provide instructions as a PDF on a CD and the first thing you ask me to do is to turn off the device I use to read those instructions. - Not so clever.

The inclusion of another small, but vital, instruction step saying

1. PRINT OUT THIS DOCUMENT

could solve that usability issue.

So think about this - if you are going to produce a minimal documentation set - then at least think about how, and where it is going to be used.

Getting Started type guides will probably always be best as a printed document, which could be anything from a single sheet checklist to a small booklet. But remember you need to apply more thought about design, graphics, language, and usability.

Round Tripping - Myth or Promise?

As I mentioned in a previous post, later in October I will be taking part in the WikiFest panel as part of this year's Wiki Symposium in Orlando.

As a small taster for those who can't join us (but if you are free that week, I encourage you to make the trip to Florida), here's the brief presentation description I submitted:

Round Tripping – The Holy Grail of Documentation Wikis – Myth or Promise?

More and more companies are using the wiki platform to publish their product and design documentation online. One of the main attractions of taking this approach is the hope that the documentation users will both comment on, and contribute to, the documentation set. In other words that the companies will move from developing documentation based on theory to documentation based on the collective experience of the community. But how do you manage that user generated content? Many are looking towards a solution that will automate the integration of feedback into their source content. This presentation will look at if that goal is feasible, manageable, or even desirable.

Panel Picking Time for SXSWi

Time is running out to vote for the panels and topics you would like to see discussed at next years SXSW Interactive Conference in Austin, TX.

SXSW Interactive features five days of compelling presentations from the brightest minds in emerging technology, scores of exciting networking events hosted by industry leaders and an unbeatable line up of special programs showcasing the best new websites, video games and startup ideas the community has to offer.

I have a couple of panels up for consideration and if you haven't yet voted, I would appreciate a "thumbs up."

Wikis are Wonderful - or Are They? - Corporate wikis are not wikipedia, but are they of any use? The adoption of wiki technology in companies and organizations of all sizes is growing fast; but is it hype, or are there real benefits? The panel will discuss the use of wikis, when they work, and when they don’t.

Spandex and Software: Can Comics Get You To Read The Manuals? - Google Chrome wasn’t the first product to be accompanied by documentation in the form of a comic book. Sequential art based messaging is everywhere, and has a long history. In today’s more visually literate society is the humble comic book placed to be the next big thing in user docs?

And while you are visiting the panel picker, here's a few more panels that I'd recommend checking out and voting for.

Sarah O' Keefe on "Will User-Generated Content Wipe Out Technical Writers?"

Rahel Anne Bailie on Greening Your Content: Reduce, Reuse, Recycle."

Brenda Huettner on "All About Audience: Improving User Experience."

Charlene Kingston on "Designing Projects That Change User Behavior," and "Reach Your Diverse Community With A Persona Strategy."

Warbling About Wikis

"You know you should really do that using a wiki," seems to becoming a regular part of my daily conversations. In recent weeks I know I've used it at:

- a social event related to my wife's work when someone was describing a public outreach program they had recently put on;
- a friend's book-signing where I fell into conversation about the usefulness of social networks and community collaboration;
- a science fiction convention during a conversation with a fellow writer about a research project he is part way through.
- a conversation with the CEO of a niche publishing company about using a wiki to connect his existing community of loyal readers.

It's perhaps only natural as I start to write the first few chapters of my upcoming book on the subject, "WIKI: Grow Your Own For Fun and Profit," that the concepts, technology, and practical application of wikis should be fresh in my mind; but what I am starting to notice is just how far reaching the application of wikis could, and should, be.

Wikis are far more than online encyclopedias, or a new way to deliver documentation.
Wikis can also be:
- Project management tools
- Forums for community conversation
- Knowledge capture tools
and much, much more.

In fact when you think about the ways a wiki can be used they can even replace the two most used corporate software applications - email and word-processors.



In October I'll be taking some of this wiki conversation and discussion on the road when I present a session at the WikiFest portion of WikiSym, the 5th International Symposium on Wikis.

I also have a panel on Wikis up for possible inclusion in next year's SXSW Interactive festival. If you would like to be part of that discussion, please head over to the SXSWi "Panel Picker" and give the proposal a "thumbs up" vote.

Is Social Media a Fad? Or Essential to your Business?

Watch this and then decide if you should be spending your marketing budget and hours on SEO optimization of your website and search based ad-word campaigns, or on building a community using Social Networks?

Rockets and Notebooks

As I mentioned over on my personal blog recently, I have been doing a lot of research into the history of the space program, and a few weekends ago took a trip to the New Mexico Space Museum. While I was there I got chatting to one of the museum volunteers who had worked in the astronauts’ office during the Apollo days. During the conversation he offered the observation that:
“There were things they did back then that we can’t do today.”

This reminded me of a conversation I’d had many years ago while visiting one of the NASA facilities where an engineer had told me that even though the Saturn V rockets on display at the Cape Kennedy launch site in Florida and the Johnson Space Center in Houston, TX (below) were fully functional, they could never be put back into service as no-one knows how to operate them. As the engineers from the Apollo projects dispersed or died off, and the focus shifted to Shuttle operations, the institutional knowledge needed to launch a Saturn V disappeared.

Recounting this story a few days ago prompted another memory. Several years ago, the consulting company I was working for was engaged to help identify just such a loss of institutional knowledge. During our time at the company we discovered that a tradition had developed among the people who worked on the assembly line to keep a small note-book in their overalls pocket. These notebooks were used to write down workaround steps, or take notations on how to improve the efficiency of the assembly process. Many of the notebooks had photocopies of pages from the company official assembly manuals pasted in with notations added. We also found out that the people with the longest service could assemble the product in about half the time the official process said it would take. The increase in efficiency was due to a combination of experience, and the tricks and short cuts they had written in those notebooks. The real problem came when the longest serving employees retired or moved on they took their notebooks with them. The institutional knowledge was lost. Each new person employed on the assembly process would start from zero with the official procedures and have to relearn all the tricks that their predecessor had developed.

Because the existence of the notebooks was never officially acknowledged, they were never included in any part of the company’s knowledge capture procedures. Our recommendation was to engage the people in the company who had the best skills for interviewing subject matter experts – the technical documentation group. From that point on a monthly review session was held where a technical writer would sit down with the assembly team and take notes on what the engineers had written down in their personal note books over the previous four weeks.

In fact in today’s economy where turnover of staff is high and a lot of valuable information is lost during layoffs etc., this is a great opportunity for a Technical Documentation team to showcase how their talents can be used and the real value they can bring to a company.

If someone who held a technical role is leaving the company, for whatever reason, don’t just conduct an exit interview with the HR department, but have them sit down with a technical communicator who is good at interviewing subject matter experts. Do a proper debrief and capture not only their notes, but the inherent knowledge and process tricks that are in their heads too.

Perhaps if NASA had done this, we might still be able to fly those Saturn Vs.