Danah Boyd has been reflecting on her long lost handwriting skills.

“My ability to communicate without editing has decayed. My patience for creating text at a rate slower than I think has decayed.”

Are we getting lazy? Are we too reliant on technology or are we simply adapting how we work and think to match the new capabilities we have at our disposal.

Personal computers have been around for long enough now that they are a standard, obvious, piece of kit for a technical communicator. I’m 34, and those of you from my era probably won’t EVER have asked whether a PC is part of the provided tools or not, it’s just something that is presumed (asking for a particular spec is different).

So, whilst I still use pen and paper to jot down notes, I don’t ever write anything of any length that way. Contrast that with some letters I stumbled upon the other day, written to my Gran when we had moved to the South of England (there are few in number but her replies are treasured). Written in one go, by hand, I was obviously still capable of editing my thoughts before committing them to ink. These days my tendency is to write first, edit later, publish quickly.

Everything you read here has passed through that (somewhat wonky at times) filter, and it’s a luxury I’ve become so accustomed to that I no longer really consider the process. Editing is such a key part of my written communication, regardless of where it is manifest, that it is now just something I do. It wasn’t always so.

Writing notes at college required on-the-fly information structuring and text editing, due to the simple premise that the less time spent scoring through lines of text the better. I have notes from early training courses which show I still adhere to that principal for at least the first couple of years of being a professional, entire sentences written out by hand with nary a score or embellishment to be found.

Fast forward a few years and my notes quickly descend into random words and scribbled quotes. If I don’t type up my notes the night of a conference, training course or meeting then they take on the cryptographic qualities.

And I guess this is one reason why the prominence of laptops in meetings and at conference venues has slowly risen over the past few years.

The odd thing is that most people acknowledge that note taking works best when pen on paper.

So I’m making a concerted effort to rediscover my inner editor, to take a few extra milliseconds when jotting down notes and thoughts to make sure they mean something. It will take some time but, in the long run, I think it will be worth it.

Technology is wonderful, it has many benefits but sometimes it’s good to step back and rediscover the abilities you used to have.

Just visited the McAfee website and on one of the forms encountered a, shall we say, anomaly presented itself.

I am a patriotic kind of guy, and I’m not in any way anti-American (I’m well aware that the percentage of idiots over there matches the numbers we have here), and when you actually consider what I’m about to tell you isn’t really about patriotism, jingoism or somesuch.

Rather it’s a wonderful piece of bad programming that I’ve seen before, centred around the fact that (at least for the purposes of this discussion) the country I am identified with is known as both the United Kingdom (UK) and Great Britain (GB).

I’m Scottish, and my country is part of Great Britain (which is the main island mass which also includes Wales and England). Add in Northern Ireland and you have the United Kingdom. It confuses me but that isn’t really the issue here.

When selecting my nationality in an online form, invariably I have one option: United Kingdom. On some forms I am delighted to be able to select Scotland, and on others I have to hunt for Great Britain.

However, the McAfee form in question proved a little troubling.

On highlighting the Nationality list, and tapping the U key, I was taken down to Uganda. A few more taps of the DOWN arrow key is usually all that is required to get me to “United Kingdom”. Not this time though, so I clicked the list top expand it, just to make sure I hadn’t keyed too fast but no, there was no United Kingdom.

No problem, I think, I’ll just tap the G key to get me back up the list towards Great Britain. This time I expanded the list first and scrolled down to… hang on… no Great Britain either? Great! Must be an option for Scotland!

Nope.

Somewhat puzzled now I double-checked that there was no entry for Scotland. There wasn’t. United Kingdom? Not listed amongst the rest of the nations of the world that begin with U. Must be Great Britain then?

And there it was, nestled away amongst the Gs. “United Kingdom”.

Now technically I can figure out what has happened, the label which is displayed to the user is “United Kingdom” but the value, on which the list being sorted, is set as “Great Britain”.

I have to wonder if this was tested at all and if so they have missed a fairly obvious set of test cases. If you are a global company then you need to consider these things.

OK, admittedly it is a tiny mistake amongst a large and complex website but it does serve to remind me to take the unhappy path through our own software now and then. I have a tendency to check through screens and processes presuming a lot of knowledge and taking the happy path.

Footnote: I worked for Dr. Solomons for a year before they were purchased by McAfee. One of the projects (ditched by McAfee) concerned a global company update system, during which many long design meetings centred around just this kind of “international” issue. But hey, I’m not bitter that they made me and 250-odd other people redundant almost immediately after they bought us, honest…

Another week (and a bit) has passed. Time is tight for me at the moment, and I’m not posting here as often as I’d like so, for now, here’s a quick roundup of everything that’s zipped past my inbox in the past week:

Resources on presentation design

… advocates an assertion-evidence design, which serves presentations that have the purpose of informing and persuading audiences about technical content

Needless to say, with my first ever conference presentation looming, I’m fairly focussed on both topic relevant stuff and anything that will help make my presentation better.

An XML CMS is simple as 1-2-3

Creating an XML-based Content Management System to single-source technical publications is as simple as 1 - 2 - 3. Rather than focusing on any single tool or solution (and thereby forcing users to change to match the tool), this article describes one possible three-step process for using XML to single source your content deliverables.

A rather simplistic view of things, but if you are a bit flummoxed by the raft of information available in this area, and you aren’t really sure where to start, have a quick look at this. Short, simple and easy as A-B-C.

Make your writing east to scan

… the acid test is looking at your information as your reader/user would see it, and asking yourself “can I find what’s important without reading the whole page”?

You can format your text in a variety of ways, but it pays to take a step back and view the format of your content from the point of view of your readers.

Getting to the web-first mentality
Interesting to read that other professions are struggling to embrace the internet. Ultimately I think it’s getting to the point where we just need to take the plunge.

Start putting the web content management system into the workflow at the front end. This could be as simple as using Google Docs as a word processor instead of the bloatware that we know as MS Word.

Collaborate or fail
Titled “Building a Collaborative Team Environment” the opening couple of paragraphs kept me reading:

Technical communicators work hard to meet deadlines and value the standards inherent in the profession. At the same time, they value their personal creativity and the responsibility for developing a complete publication on their own. They tend to enjoy doing everything from writing, editing and page layout, tographics, technical content, and more.

Working as part of a team to create a single set of deliverables, handing over responsibilities to fellow team members, and trusting the work produced by others does not come naturally.

It’s an excellent article, looking at a variety of ways in which we, as technical communicators, can adapt how we work. It will no doubt prompt some posts here as I digest it further.

And on that, somewhat culinary note, I’ll thank you once again for stopping by.

I started this blog to have a separate place to write about my “professional” thoughts and I guess I thought I could maybe add a little value to the cluttered world of technical communications, or at the very least raise my profile a little. Yes, I have an ego, but it’s kept in check for the most part.

However, like my other blog, the main reason this blog exists is to give me a place that I can consider and process my thoughts. I’ve always found writing things down helped me get a good sense of what they were, even if I didn’t necessarily start with a cohesive picture in mind. Sometimes the simplest issue, one that has eluded me for some time, leaps into focus when I start writing. I’m not sure if it’s always been that way or I’ve now trained myself into such a habit but I’m not complaining, it works for me and I’ll admit that I still get a little buzz when something “clicks”.

If I were in a cartoon a light-bulb would *plink* into existence above my head when that happens. Reality can be such a disappointment.

Today brought a good example of such a moment and rather than deleting my thoughts, I’d thought I’d post them here. Sharing is power after all (badly paraphrasing remains inexcusable).

One continuing theme on most of the mailing lists I follow and in various blog posts across the land, is that of knowing your audience. Knowing why you are writing, and who you are writing for are the fundamental tenets of our profession. They are so fundamental that, if I’m honest, the incessant reminders about them do start to grate somewhat. After all I’m a professional, how many times do I need to be told to consider my audience? How many times do we need to restate something we all know and understand.

I’m happy to admit that some will know more about their audience than others. Some will make do with a rough approximation of what their audience expects, whilst others will interview and analyse their customers and gather requirements and direction directly.

Regardless of your level of commitment to understanding them, anyone who is writing must (surely) consider their audience. Yet, at every turn, the answer to many questions all stem from that presumption, and are presented in simplistic terms. Know your audience they say. OK OK, I get it!

The thing is, after reading such a response for the umpteenth time it suddenly struck me that yes, we do need to be reminded of this basic fact, time and again.

We all have pressures on our work. Whether those pressures come from commitments made to others, from our own professional integrity, or directly from the customer, they all serve to focus us on the end goal and usually to start thinking in terms of quantity. We know we need to document the new interface to the ACME Widget and when pressure is exerted their is a temptation to take shortcuts, and the easiest shortcut is, by and large, to forget the audience.

The cardinal sin allows us to omit information on the presumption that they will “probably know it”, to structure the information according to UI rather than task, and ultimately to regress to a “if you can click it, document it” mentality. That may be a valid mode in certain circumstances but that will depend upon, yeah you guessed it, your audience.

Audience analysis, the use of personas, call it what you will, if you don’t have at least a rough idea of the type of person you are writing for then why bother? You won’t be structing the information correctly, you won’t be pitching the level of information appropriately, and you most certainly won’t be thinking around the various conceptual models your audience are likely to use and understand. The more you know, the better you can focus your documentation, drilling down into the tasks they need to complete and what they need to know before they begin. The better your knowledge of your audience the more likely it is you’ll produce documentation that they can use.

Put it this way, if you aren’t writing for a specific audience, who ARE you writing for?

Ooops.

I’ve gone and done exactly what I said annoyed me, lectured you all on knowing your audience when you already know that you need to know that. You know?

Next time I read yet another “Depends on your audience” response in a mailing list I’m going to try and remember that advice and apply it to my current work.

Addendum: Charles Cooper has been considering the same thing.

Having recently upgraded my MacBook to run the latest version of OSX, I’ve been using the built-in Help to figure out how to configure things to the way I like them. It’s an excellent example of well designed and integrated help. Of particular note is the effect shown in the screenshot below.

An excellent example of integrating user assistance with an in-built online help system. Don’t you think?

Typing in your question to the text box, top-right of the window, dims the contents and ’spotlights’ the items which possibly match what you are looking for. Smart, huh. There are many more examples of this kind of thing but this one caught my eye.

Many years ago, when I was just starting out in Technical Communications, my boss at the time gave me a piece of advice. Every now and then it pops back into my head and, as well as allowing me a small smile, reminds me to do just what he suggested.

His advice was one word.

He didn’t explain it and, to be honest at the time I was a little befuddled. It took me a while to grasp the depth of what he was saying as, at first glance, as it is only one word it does seem very slight and somewhat obvious. Looking back now it even seems a little trite but, remembering the type of man he was, it was most certainly carefully considered and meant honestly and with compassion.

To this day, through all the different positions I’ve held in different organisations, and even into my personal life, his advice holds true. One day I hope I’ll be the type of boss he was, encouraging and enthusiastic, a real leader. Until then I continue to try and follow his advice and so far it’s served me well.

There are many circumstances in which it can be applied, whether you are at the start of a project and knee deep in planning meetings and specifications, or hurtling towards the deadline, grasping at every snippet of information that passes your way. Regardless, his single piece of advice, one simple word, holds true.

Pause.

That’s all there is to it. Don’t send that email, pause. Keen to start writing, pause. Desperate to just get the thing finished? Pause. About to finish a landmark, award winning project? Pause.

A simple word, a powerful piece of advice.

12 Lessons for Those Afraid of CSS and Standards

“It took me two years to break out of the comfortable prison of layout tables, and another two years before I could use CSS to produce layouts that were originally intended for tables.”

“The buzz about Web 2.0, CSS, and myriad other subjects of the bleeding edge can become a dull roar to those left ill-equipped for industry changes because of work habits adopted in good faith years before. It is my hope that the experience I’ve shared will help some folks to find a way back to the top of the heap—which is where the web needs you.”

But don’t be afraid, Ben Henick offers some lessons that will help get you through. It’s based on real-life experience and mirrors my position. CSS and standards are good, yes they can be strict taskmasters but remember that 100% compliance isn’t always required, sometimes 98% is enough. As Ben points out in Lesson No. 9: “In the real world, stylesheet hacks will get your project across the finish line”

Design Engineering

“The common expression “Engineers build bridges” is actually a misnomer. Engineers build mathematical models of bridges and draw little pictures of bridges on paper or inside computers. Ironworkers are the people who really build bridges. This inexact, industrial age metonym has led to much confusion in the post-industrial age, where it’s all too easy to confuse software designers with software welders because they both use the same tools and raw materials for their very different work.”

Not sure I agree with all of this but I always tend to learn more from a differing opinion.

What do you seek — Documents or Knowledge?

“Document management can only point you towards documents, like a traditional search engine. In contrast, when you’ve got information on a wiki you can search for information, link to it, reference it, update it, secure it, blog about it and share it.”

I’ve been pondering the possible questions that might crop up when I give my presentation on using Wikis in the workplace, and this is a great answer. So much of using a Wiki is about breaking the document-centric working practises that slow us all down. Don’t they?

The Spiral of Wiki Adoption

“Although reliance on email and familiarity of other tools may illustrate a reluctance to ‘unlearn’ habitual less effective work practices, there needs to be a balance between directive wiki usage and support for different communication styles as people become accustomed to using wikis and the different capabilities they can provide.”

During other research I found that just getting people to start using a Wiki was the hardest part. Once they started, they soon started using it in ways not previously considered. In other words, Just Do It.

And finally, two quick links. One I’ve known about for a while but recently cropped again on TechWR, and the other is just for kicks. Although I do often wonder if people do Laugh Out Loud as often as all that.

A List Apart: Style Guide

LOL?

As ever, I’d love to hear your thoughts on any of these. Particularly the Design Engineering article which I must admit I partly agree with but I do dislike the “them and us” tone.