Showing posts with label tech doc. Show all posts
Showing posts with label tech doc. Show all posts

Tuesday, May 29, 2012

Color me this...



The following are a few extracts from my latest feature cover article for INTERCOM magazine on Communicating with Color

 
My red shoes went viral on the Internet thanks to a photograph taken at the Intelligent Content Conference in Palm Springs back in February. Over the last couple of years I’ve developed a bit of an obsession with Converse sneakers, and as of today have nine pairs in different colors, usually worn to match whatever shirt or jacket I’m wearing. The red ones always seem to draw comments or, it seems, the occasional photograph.

However my interest in color goes beyond my choice of sartorial footwear, as I’ve long been interested in the use of color as a design element in communications and storytelling.

Color has always been around us, used by both man and nature as a means to communicate.  The bright plumage of a bird, or the striped fur of a Tiger are not an accident, they are an integral part of the way that the animals interact with each other and their surroundings. The same goes for the human species. We have long used color to communicate with each other and as a part of various cultural traditions. So why not use color as part of our technical communications toolbox as well?

....

Of course adding color to your technical communications deliverables isn’t as simple as just picking a few crayons from the box and coloring in between the lines. The use of color takes a lot of thought, and a new set of skills that need to be considered. In fact the color theory knowledge and experience of an individual can make a big impact.   

....

Think about the colors you see around you everyday and how they are used. Red for Stop or Danger. Green for Go etc. Your company probably already has some color standards overseen by the marketing group on how the company colors can be used. Think about how they can be incorporated in to your technical documentation. Even take a look at the colors used in the product you are writing about. How can they be used?

The full article is available in the print edition of the STC INTERCOM magazine, or on-line here.

Monday, May 9, 2011

Looking forward to the STC Summit

Next week I will be in Sacramento, CA for the 2011 STC Summit. An event I've been looking forward to for many months.

Although I'm not speaking this year, I've been more involved than ever, as both Deputy Program Manager, and Track Manager for both the Web Technology and Education and Training tracks.

This will also be the first STC Summit since the publication of my book "WIKI: Grow Your Own For Fun & Profit," which will be available at the conference bookstore and at the XML Press booth.

If anyone would like to meet up for a chat, or get a book signed, then the best places to find me (or leave messages) will be at:
  • The STC Program booth,
  • The XML Press booth,
  • The PTC booth.

I'll also make sure to step into some sessions and visit the expo floor on a regular basis throughout the conference.

I'll also be posting note on both my Twitter accounts during the conference, so feel free to follow, or contact me, via @4jsgroup or @alanjporter

I'm looking forward to meeting up with old friends and colleagues, as well as meeting lots of new people for some interesting discussions on Technical Communications and Content Strategy.

I think we have put together a great program this year, and if you are attending, I hope you find it both informative and stimulating.

See you in Sacramento.

Tuesday, December 21, 2010

Paying the Ferryman - The cost of putting your content in someone's hands.

As part of the research for my next book for XML Press book (Which like this blog is also entitled THE CONTENT POOL.) I was having a conversation with a couple of people at a large manufacturing company about the cost of their documentation; at the start of the conversation I was expecting to hear all about the software they used to author, manage and publish their information, or even about the cost of training and retaining skilled technical communicators. But the conversation very quickly turned to one aspect of technical publishing that most of us (and I include myself in that) often completely overlook. - The cost of actually getting the information into our customers hands.

For this company their largest publishing related cost is simply Postage.



When we talk about modern technical communications and publishing systems, processes, and technology, we tend to think about digital creation and delivery. Along with that comes an assumption that most, if not all, our customers are in some way connected to the internet. There is a lot of talk (and again I'm just as guilty as anyone) of web delivery, mobile delivery and the bright digital future we are all marching towards. Yet that is a very Anglo-American centric view of the world.

Recently someone at Facebook developed a visualization of all the various Facebook connections, and the image that appeared (below) turned out to be a startlingly accurate rendering of a map of the World. Except that large areas of that map were dark. It reinforced the message that even if we are producing information digitally, we can't assume that if we are operating on a global scale everyone who needs access to our information has a wired connection.




So back to my earlier conversation. The company I was talking to uses XML and topic based authoring processes, along with content management tools, to efficiently single-source their documentation into many different deliverables.

But their products are literally used all over the world, including in some of the world's most inhospitable and remote locations. Not everyone is wired, so instead they ship sets of DVDs to customers and business partners.

Depending on the product being used the DVD sets can consist of anything from 3 to 12 separate DVD discs. And they ship 15,000 such sets every month. While the cost of shipping a set of DVDs within the US may be relatively cheap, the cost of shipping on set of DVDs to to a user working in the African jungle maybe as high at several thousand dollars. As well as the actual postage there is the cost of import duties, time to fill out customs forms and get approvals, as well as the actual delivery cost. I was told of one DVD set that involves the monthly rent of a boat and boatman to delivery it along a jungle river!



The total annual postage and delivery cost of DVDs for this company is in the Millions of dollars range, and recent increases in postage rates have meant a dis-proportianate rise in that overhead.

So next time you are considering the cost of your documentation - don't just think about the investment needed to actually create the content - think about what it takes to actually get that information into the hands of all your customers, no matter where they are located.

Saturday, July 10, 2010

Are you an "Awesome Dude"?


I just spotted this message posted by one of my nieces to her FaceBook account the other day:

[name] finally has picture messaging on her Nokia N900 thanks to an awesome dude and his step by step youtube video!!

A seemingly simple message, but one that made me stop and think. I've written, and spoken a lot over the last year of so about the way that the digital generation access and assimilate information (a subject I'll be revisiting at this year's LavaCon), and also held forth on my view that as Technical Communicators we should be embracing and working with new media.

Here is a perfect example of that convergence. Rather than use the manufacturers, instructions, or look for an answer on their web-site, or on-line help, my niece turned to the internet and the wider online community.

Her answer came not from Nokia, but from some "awesome dude" on YouTube.

What are you doing to make sure that you as a technical communicator can be the next "awesome dude"?





Tuesday, June 29, 2010

Technical Communication As Story Telling

Over on his "I'd Rather Be Writing" blog, Tom Johnson, has taken my idea of Tech Comm as storytelling, and expanded on it an excellent post, that I highly recommend.

In particular I like these two ideas on the practicalities of applying story telling techniques to technical documentation:

THE ELEMENT OF CHANGE

In a good story, the resolution always brings about some type of change, or comes about because of change. If you listen to stories on The Moth podcast (a storytelling podcast), you’ll constantly hear this element of change near the end of each story. For a story to feel meaningful, the protagonist always changes as a result of the conflict. Without this element of change, the story feels flat.

In technical documentation, achieving that element of change is difficult. In almost all technical documentation, the reader is the protagonist, since our point of view is second person (“you”). You (the reader) have a problem. ..... Through the help topic’s steps and information, you find a solution that solves your problem. Hooray, you’re much happier and complete now. That’s the basic transformation.

And..


FOCUSING ON THE PROBLEM

A problem of some kind usually drives and gives rise to the story. But isn’t every help topic by default the answer to some problem? And aren’t users coming to the help content with a problem already in mind? Do we need to explicitly supply the problem, since it’s already apparent in the user’s mind?

Yes, your protagonist already has a problem. That problem is what is fueling his or her path through the help. But it can still be helpful to state the problem explicitly so that users can connect their problem to the solution you describe.

In many ways the examples and ideas that Tom cites, also feedback to my earlier post on Applying the 10 Commandments of Storytelling to Technical Documentation.

It's great to see these ideas being picked up and expanded upon.

Tuesday, June 22, 2010

Print or Digital ? - Using Augmented Reality to bridge the gap.

One of the the strangest aspects of all the recent discussions in the mainstream publishing world about the emergence of eBooks seems to be the notion that digital and print are mutually exclusive delivery options.

Nothing can be further than the truth; as we well know in the technical and corporate publishing world, electronic delivery of information is just one delivery option.

But how about combining the two? Print publications augmented by digital content?

Check out this video of a young reader's reaction to a copy of the BBC's science magazine, FOCUS, with augmented reality content.




Think about how effective that would be when used to deliver technical or training materials?

Perhaps Augmented Reality maybe just the thing to bridge that perceived gap between print and digital? Food for thought.


Friday, June 18, 2010

Where's The Manual?

Over the last couple of days my life in corporate and technical communications seems to have crossed over into my life as both a pop-culture writer, and motor racing fan.

While watching the advance press-screening of TOY STORY 3, I was delighted to discover that a central plot point revolved around the toys using the manual to discover how to effectively reboot Buzz Lightyear via his 'reset' button - of course, as they say, "hilarity ensues."

Then this morning I was pointed in the direction of this amusing video of McLaren Formula One team drivers, Jenson Button and Lewis Hamilton, both World Champions, trying to build one of their race cars without the aid of their team. The plaintive cry of "Where's the manual?" made me smile.




But as much fun as it is to hear "manuals" used and talked about like this, it made me think about a more serious take.

I still keep hearing people in the technical communications industry say they aren't valued, that what they do has no place in a hi-tech digital world. Well it doesn't come much more hi-tech than Formula One, or digital than Pixar, but still the idea of, and need for, a "manual" is paramount.

In both cases, the toys, and the drivers, wanted to know how to do something.

And that's where the future of technical communications lies. It doesn't matter what form the "manual" may be, now or in the future; we have the skills to provide the best answers to the question "How?"

Now, that's real value...

Just ask Buzz or the McLaren F1 team.




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.

Saturday, January 9, 2010

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, October 23, 2009

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.)

Thursday, March 26, 2009

Why Technical Writers Shouldn't Be "Writers" - Slides

Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.

Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)

The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.

What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?

Several people have asked for copies of the slides I used, so here they are.

However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."

If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.

Friday, March 6, 2009

Should Customers Pay for the Manual?

Yesterday a friend of mine posted the following on his Twitter feed

OMG! (Company Name) actually charges for their owner's manuals! That's absurd.

Absurd? Really? Is that the common expectation - that all the manuals associated with a product should be "free"?

Over the years I have, at different times, worked with two companies that have almost directly identical competing product lines. In general they each have around 50% of their given market (although actual market leadership tends to fluctuate between them on a year to year basis). Yet they have two diametrically opposed philosophies when it comes to supplying documentation.

Company A has the philosophy that when you buy their product you get everything included to run, maintain and operate it (but not to repair it) so they include the cost of producing the documentation in their product pricing. They make their money on spare parts.

Company B has the philosophy that when you buy their product, you just buy the product and then pay extra for the bits and services you need, as you need them, so they have a lower product price and charge for their documentation (and their spares too).

The total cost of ownership for both products over the normal operating span turns out to be just about the same.

Let's take a look at the two scenarios in more detail.

COMPANY A - Documentation Included

This is perhaps considered the more traditional model. A content development team writes the various manuals , help sets etc. and publishes a complete suite of documentation. The whole suite is then delivered with the product. That suite can range from one small manual to literally (in the case of an aircraft) hundreds of large volumes. The cost of producing those manuals is covered in the product cost, and the customer perceives them as being "free."

That's how it should be. I've been amazed at the number of times that I've done consulting work for companies that don't even consider the cost of the documentation. They don't calculate it, they don't consider it a development cost and they don't cover it in the price of their products. Often companies like that consider documentation to be "a necessary evil" (a phrase I have heard more than once) and an uncontrolled overhead. As a result the content development is not considered an integral part of the design and production process and is poorly funded (if at all). The result is usually poor quality documentation. As a general rule of thumb, if you buy a low commodity priced product and it includes "everything," then there is a fair chance that the manuals will be next to useless. (I know this is a broad stroke statement, and there are always exceptions to it).

COMPANY B - Documentation Sold Separately

In this scenario the cost of producing and distributing the product documentation is usually well understood and managed. Most products in this case will ship with a small "free" documentation set that covers the basics of getting started, and simple opertaion (like the books in you car's glove box for instance) with the expectation that if customers want to know more they are prepared to spend money. Again think of the car analogy - most people who want to maintain and repair their own cars will go and buy a book on how to do it. There are whole companies who write and sell sepcialist manuals for car dealers and repair shops. The vast majority of customers will never access a full documentation suite, so why provide it to everyone? The manufacturer can focus on producing the documentation that 80% of its customers need, and the other 20% can be covered by a recognizable revenue stream from selling the specialist manuals.

One area of opportunity where I believe that the "pay as you need it" model breaks down is that currently most manuals you pay for (including the one that my friend was complaining about) are PDFs of traditional print manuals. You still end up buying the complete book even if you only want one or two sections of it. - If you have a pay to download the manual model, why not publish it based on topics (DITA?) and use a system of micro-payments. Instead of asking customers to pay $10 (the amount that outraged my friend), $15, or $20 - why not charge $0.99 a topic?

So which one is the right approach? I think they both are. Whether or not you charge for documentation is a product of many factors such as the business plan, the content development team's role in your organization, customer expectations, etc - but one underlying thing that applies is that the cost of documentation development should be correctly calculated and factored into the product development costs. You need to recoup that costs somewhere - it just becomes a matter of deciding where in the product life cycle and how.

BUT... if I had to favor one, I'd say go the separate charge route. - it gives more flexibility for delivery, it gives the customer choice, it lowers product prices, and it turns the content development team from being an overhead into a profit center.

On a personal note, when I switched one documentation department from being an overhead to being a revenue generator it completely changed the way the role of documentation, and the people who produced it, was perceived.

And the customers liked it too.

Thursday, February 12, 2009

Don't educate...learn!

Earlier today I came across the following post on a Tech Doc related discussion list.

We still use X and while we (the tech writers) think they are useful, I think our users mostly rely on Y. We've attempted to educate our users on the value of X, but based on the questions I get I don't think a lot of our users think of using X on a regular basis.
(AJP - Quote edited to remove names of specific processes)

Wow - so if I get this straight, the users of the information like to use it one way (Y), but the content creators think they should be using it another way (X) so they make every effort to "educate the users" as to how it should be done.

If the majority of the people who uses your content are following the same behavior pattern, isn't it better to look at why they are doing that, and the value that THEY find, rather than the value that YOU think is there.

Learn from your customers. Find out why they prefer Y to X, and then do what you can to make Y even better. If that means dropping process X, then do so.

Those of you who have heard me talk will have heard this before, but the documentation industry is not about us as content creators, it's about our customers and how they access, assimilate, and use that content.

Friday, December 12, 2008

Banging The Drum Again...

In his excellent blog post about the current state of the book publishing industry Mark Tavani, a Senior Editor at Random House, makes the following observation.

... books are a mere format. Yes, they can be beautiful and wonderful to hold in your hands, and yes, there are some books I plan to keep in my home until the day I die simply for their sentimental value. So I understand what is magical about books. But the most magical thing about them is the information they convey: the story they contain. The word “book” and the word “story” are not synonymous, just as eight tracks and music are not the same thing. Stories pre-date books by milleniums; and though books might someday go away, story will last as long as our civilization does.


Substitute the word "book" for "documentation," and the word "story" for "content" and I think the observation applies equally to the world of corporate publishing as it does to traditional book publishing.

=========

I need to add a couple of points of clarification here.
- Anyone who knows me and has heard me speak will know I love books (the traditional kind). I have a house full of them, and spend my evenings and weekends writing them. BUT while I'm a passionate bibliophile, I am also aware (as I mentioned in my last post) that the "book model" is perhaps no longer the best model to be using to ensure that content reaches the end user of a product or service.
- While I suggested swapping the word "story" for "content" in the quote above, that was more to illustrate a point. For me everything we write or produce that is designed to pass on knowledge or information is, and should be treated as, a story. The ability to tell stories is the most powerful communications tool we have at our disposal. As Tavani points out, we've being doing it for millennium, and will continue to do it irrespective of any technology or medium.

Tuesday, November 25, 2008

Remember the (STC) Alamo

Just over a week ago I attended what was simply the most open and stimulating regional STC event I have ever been to.

The Central Texas STC Fall Seminar, was organized jointly between the Austin and San Antonio chapters of the industry group and held at the excellent Hotel Valencia on San Antonio’s famed Riverwalk. (Home to many fine restaurants - including the one where we had lunch.)



But it wasn’t the setting that made it memorable – it was the participation.

In my experience a lot of these regional get-togethers end up in features and functions comparisons of tools, minutiae of the job, or arcane technical discussions about standards that only a minority of people use. Not so in this case.

The discussions ranged from using emerging new technologies, Web2.0 tools,, wikis, social networks, to how to develop and recognize metrics, to how to make sure that the documentation process is heard and accounted for in a Agile Development driven world.



But underscoring all the talk of technology was the realization that technologies will come and go, and the most important skill to develop was the ability to learn about new things, and communicate that in an empathic way.

There were several people who were attending their first STC event and they, along with everyone else, left with the impression that this is an exciting time to be in the corporate publishing world.

Thursday, November 20, 2008

Is there a case for "Just Enough" Documentation?

A couple of what at first glance appear to be disparate unconnected posts picked up by my Twitter feed over the last few days got me thinking about just what we should include when we produce product documentation.

On her Twitter feed consultant Sarah O’Keefe posted the following quick observation: "Inbox Zero once again. Today's lesson: When you ignore stuff, much of it becomes irrelevant.” This is a productivity, time management technique that I have used for years. One of the first things I was taught at management college was that never keep anything on the “to-do” list longer than 30 days. If you haven’t got around to it in 30 days and no-one’s complained it probably wasn’t that important. Delete it, and if it is important someone will remind you. Like Sarah I also apply a similar philosophy (but not time scale) to the contents of my Inbox.

Then today, Alyssa Fox from NetIQ posted a quick note on her Twitter feed that “SE just found a bug in our doc that's been in there 5+ years. Obviously no one ever reads that section,” to which I responded “If no-one's read that doc in 5 years - is it really necessary to have it there at all? Why write and maintain something no-one uses?”

Over lunch I began to realize that the two thoughts had a definite connection. Traditionally we tend to document every feature and function of a product. We expend many hours describing how something works. Yet how much of what we produce is ever read or used?

Most users are only interested in learning how to set something up and start using it in the shortest possible time. Secondly they want to get answers to very basic “how do I” type questions. With this in mind I’ve recently been conducting an ad-hoc, and very unscientific, straw poll about which documents (print, on-line help etc.) that people are most likely to use. The result is very clear that the thicker and more voluminous the documentation appears, the less likely people are to use it.

So going back to the “ignore it and it becomes irrelevant” thought. If sections of documentation are never read, accessed or used, are they irrelevant? While the engineers and designers may not think so, it seems clear that the users do.

Is there a case for “Just Enough” documentation.

At WebWorks.com we recently went through a process of rewriting our complete documentation set. At least that was the original goal. Yet when we compared the old documentation set against the project time frame we realized that we would have to make a decision about what was necessary and what was just “nice to have.” The project was lead by one of our MVP users who could give us the user perspective on what was needed and what could be left out.

But how will we know if we’ve made the right choices?

We posted the new documentation set online as a wiki. We have enabled comments so users can directly tell us if there’s something we missed. If we need to, we can create a new piece of documentation and publish it quickly. But perhaps best of all we can now track which document pages are visited and more importantly which aren’t.

It may take a few iterations but we will be able to fine tune the documentation to provide just the information that our users need and use; allowing us to focus effort away from maintaining “irrelevant” dead pages to making sure that he have “just enough” documentation to make our users successful.

[This entry is cross-posted to my WebWorks.com blog]

Thursday, October 9, 2008

STC Proposals #3 - What Tech Doc Can Learn From The Comics

Proposal for a paper to be presented at the 2009 STC Summit in Atlanta, GA

#3 - What Tech Doc Can Learn From The Comics

The recent Google Chrome comic caused a lot of buzz. But it's far from being the first "technical" comic. Find out how comics can help you produce better tech docs.

There is a long tradition of connections between the worlds of comic books and technical documentation, but it is one that is often overlooked. (For example the US army has used technical comics for over 50 years)

This presentation will present examples of technical documentation done using comic book techniques from over the years to the present day.

It will also show how by studying the story telling and artistic techniques used in comics we can improve the readability and quality of technical documentation.

STC Proposals #2 - How To Make Executives Love The Publications Department

Proposal for a paper at the 2009 STC Summit in Atlanta, GA.

#2 - How To Make Executives Love The Publications Department

"The publications department gets no respect" is an often heard refrain. But it need not be that way.

It is possible to make Publications one of the most respected groups in your company?

Building on my own experience of doing just that, this presentation will show five key steps to take in order to change the way people think about publications.

The lessons presented can be applied equally to a single writer, as well as to larger publications groups.

STC Proposals #1 - Move Over DITA, Chaos is Coming

Last week I submitted proposals for three papers for the 2009 STC Summit in Atlanta GA, and thought it might be fun to post the summaries here. Let me know if you'd be interested in hearing any of these and if so, what sort of questions you'd like answered or topics you would like me to cover.

#1 - Move Over DITA, Chaos is Coming

The Technical Publishing industry is on the edge of a paradigm shift and may not realize it.

As the digital generation enters the workforce they will bring new expectations with them that will challenge the way we write and deliver content.

This presentation will contrast the way we currently produce documentation and our expectations of user behavior with what we can expect our users to be asking for in the not too distant future.

In the world of social networks, online video, wikis, blogs and twitter is structured topic based authoring really the answer?

Friday, October 3, 2008

Reflection on Santa Fe

I must admit after last year's excellent CIDM Best Practices conference, this year's event in Santa Fe was a little disappointing.

I didn't really hear anything new from the presentations, while the networking and side conversations seemed somewhat subdued. I had a couple of good productive pre-arranged one-on-one meetings, but otherwise there was no real discernible "buzz" about this year's event.

Difficult to say why, as that's more of a subjective feeling than an objective observation.

One thing that did surprise me was the fact of how many people still overlook both the importance of graphics, and the impact of the whole publishing process once the content has been created.

Creating good technical documentation is not just about authoring and content management.