The timing of this post, and the announcement by the Cherryleaf blog that they’ve created a Facebook group for technical authors, is completely coincidental. However there does seem to be a genuine move towards online communities, or perhaps it’s just the latest fad?

It’s an interesting time to be building an online community, and I’m lucky that I can pull from the past ten years or so that I’ve had an online presence.

When blogging first started there were few tools available, but in a short space of time they started cropping up all over the place and these days there are many different ways you can post to your blog (as well as many different ways/places to host it). The same seems to be true of the current rise of “social networking” sites.

Places like MySpace and Bebo focussed on the network surrounding one entity, whilst FaceBook and LinkedIn focus on central groups, and finally services like Ning allow you to build an entire specialised community which can then focus in on central areas of commonality.

I have a LinkedIn profile, a Facebook profile and I’m a member of a Ning community, and for me they represent different things. Ohh and please don’t be offend if I don’t “friend” you on any of those websites, I do try and keep that sort of thing under control.

For me LinkedIn is, in essence, a smart contact manager that allows me to find other people related to previous places of employment or study, whereas Facebook is something I dip in and out of and which I primarily use to keep in touch with friends and other personal/social goings-on. Ning, specifically the Content Wrangler community, is very much focussed on my profession and is a good way to interact with my peers across the globe.

I’m wondering if my perception of these sites are common? The reason I ask is that whilst creating a group on Facebook or LinkedIn is very easy, perhaps the usage of such sites needs to be considered. There has been a lot of chat about companies starting to “lever” these websites, alienating users/customers. So it definitely isn’t just me that has a fixed idea about for what these websites should be used.

I’m in the midst of trying to build an online community for the technical users of our product, and I’m very conscious of the unwritten rules and presumptions that go hand in hand with how people act online, and which boundaries need to be respected. It’s a balancing act, that’s for sure, but a fascinating one.

A phrase I spotted online the other day rings true: “someone hit them with the Web 2.0 stick”. I’m a big fan of Wikis, blogging and online communities, and I think they offer some excellent ways to be part of the conversation, but perhaps we all need to step back a little and make sure that the tools we are using are the right ones for the job.

Re-reading the article I submitted to the ISTC Communicator magazine, I realise that my average day isn’t:

• particularly average at all
• a true representation of everything I’m involved with

I lead a team of writers so my typical day may not apply to everyone, and I also have a tendency to stick my nose in and get involved in other areas if I feel I can be of help. Simply put, if I hear someone talking about “information” my radar pings and I see if I can be of any benefit.

Other non-typical items include collation of Product Release Notes, my team proof-read Marketing brochures and website collateral, we try and monitor consistency in the UI of our customer facing product, and I’m currently in the process of creating (and managing) and developer community website. As an “unbiased” member of the development group I also recently facilitated our retrospectives.

One of the reasons I love this profession is that you can (and should?) be involved in many different areas. We have a unique view of the product and I guess my day is sculpted by that, although it is helped that we are a small(ish) company and have a small group of people thinking about the “product” as a whole.

I’m lucky that our company doesn’t have a traditional structure, with everyone encouraged to talk to everyone else regardless of role or level. It’s a little like a zoo sometimes, with a lot of noise and activity, but apparently that’s a good thing. It does mean I am involved in discussions that can be hard to be a part of otherwise, chatting to the Product Manager, Product Marketing and Sales, all of whom are saying the same thing, which in itself proves that things are working and that technical writers are a valid part of that discussion.

I’m curious to hear if others have the same opportunity; What other areas, outside of technical writing, are you involved in? And why?

Text Preferences Survey
What is the ideal text size to use on the web? What about line height and column (line) length? Most of the information in this area is based on print (at best) or anecdotal (at worst). A design agency in Brighton, Message, has decided to try and find out by carrying out a survey:

“Our goal is to publish a report that provides hard facts about what constitutes ‘readable’ text on the web … We see this report being of value not just to our clients and their customers but to web users at large.”

It only takes a few minutes to complete so go and take the survey.

Why software applications need product blogs and why they don’t get them
As well as having a very long title, Tom also hits on some points well worth considering if you are at all web savvy (and I’m presuming that, as you are reading this blog, you are). Most of his ideas are spot on but would require a lot of business process change, but I think they are worth picking up on:

I can think of six major ways product blogs can benefit users and project teams. Product blogs can …
- Provide a venue for product announcements
- Allow users to submit product bugs
- Allow users to submit feature requests
- Provide a roadmap preview for the product
- Enable a point of connection between users and project teams
- Provide a way to teach advanced tips to users

He also mentions something that I too have pondered, namely including RSS feeds in online help and somehow merging the two in a more dynamic way than before. Probably not much point in purusing that now but who knows what may happen in the future.

How to work better
A short list of simple, but powerful, advice which is applicable to everyone. Go on, there is at least one thing on that list that you could do better (or if you are like me, 3 or 4).

Subversion for writers
Entirely focussed on Mac OSX users, this has reminded me that we use Subversion at work and that I should really write up our process. Regardless of platform, the basic benefits of using a version control system can be realised with little cost.

What does it do? It manages multiple versions of a project in development. You check your project out of the repository, make changes and you commit those changes back to the repository. At any time you can view older versions of the whole project or of individual files, and revert to them, if the work done since was in error. You can make branches, which allows you to develop your work in two (or more) ways in parallel, and you can tag your project to say, at this point I met a certain milestone (eg: first draft, second draft, version sent to publisher X, version sent to publisher Y, published version, etc.)

Why would you choose to make something difficult to use? Are you deliberately putting barriers in the road? Or are you just forgetting the main reason why people pick up a document or manual?

Long ago, when I had just started out as a technical writer, I attended a course on designing for Print. It covered many things, from typography to layout and I still use some of the basic design rules I learned way back then.

Whitespace, choice of font, and hierarchical indentation can help make a document more readable. Clearly delineating the structure of a document without explicitly stating it as such, leaving visual clues to help the reader navigate the page (presuming you’ve covered the multiple navigation routes they’ll take to get to that page of information).

Such considerations will continue to become more important as more and more information is moved online, and is then available in a variety of media formats and devices. Structuring your content, and using visual clues to convey that structure clearly, will become ever more important.

At this point there starts to become an obvious overlap with usability, pushing technical writers to start thinking more in terms of the user experience than simple task analysis allows. Understanding the reasoning behind a user action will become equally important, and can be passed to development to influence the UI as well as directly impacting on how we present technical information in the future.

Beyond that I’m not sure where else this may take us but I do know that part of the reason I love this job is the cross-over we have with so many other professions/industries, and I can’t wait to see what is next over the horizon.

How many times in your professional career have you been asked to spell something, or asked if a word is hyphenated? How many times are you asked whether to use “that” or “which” in a sentence?

We are the grammar police, the word monkeys, and many of us revel in that role (if not the title). Typically we possess greater information about writing than anyone else in the company, and rightly so as it is the main focus of our job.

However I am trying to stop answering these questions directly, instead I’m trying to direct people towards an answer. The reasons are two-fold.

Firstly it’s always better if people learn things first hand, helping to break the dependency for the future. In other words it stops people relying on you to remember things for them. It stops you being asked the same question, over and over and over. That can be annoying.

Secondly, and this is a subtle point, it re-enforces the notion that ALL we do is write words, that all we consider is grammar and spelling, that all we bring to a development team are documents. I don’t know about you but that’s not the case for me, never has been and never will.

It’s easy to quickly hand out information when someone leans over your desk, but maybe we need to be a little more careful. As (typically) a minority group in a software development team we have to work hard to prove and maintain our value, so maybe we need to distance ourselves a little from such matters.

Last week I spent most of my time facilitate our retrospectives, that is I spent a lot of time chairing meetings, encouraging and monitoring debate, and far too much time manipulating Post-It notes. Let me explain.

Within the development group, we base our working practices on Agile development and part of that suggests that at the end of each release cycle you should hold a retrospective session to pinpoint things that went well, things that didn’t go so well and to assign actions which will help improve things next time. It’s all about continuous improvement and we do get a lot of benefit from them.

Don’t be put off by the name, it’s essentially a debrief session that is focused on a particular area, and the process is quite simple although ours has changed a few times and the sessions we held last week were, again, something new to try and improve the retrospective process (we actually hold retrospectives of the retrospective to make sure that the retrospective is improving as well… ).

Our development group is broken into teams, and each team is asked to consider their own working processes within the overall adoption of the Extreme Programming methodology (the branch of Agile development we follow).

And then it’s Post-It note time!

Each team member is given a pad of Post-Its, and we spend 10-15 minutes jotting down things that went well, one item per Post-It. Once the time is up they Post-Its are stuck up on a wall or whiteboard, and grouped into common themes. Then we do the same for the things that didn’t go so well (ok ok, “what went wrong”) and again they are stuck on a wall and grouped.

The common groupings in each category give you things to continue doing (what went well) and things that need improved (what went not so well). Then comes the fun bit!

Each team is given control of their own working processes, and are encouraged to discuss and decide on actions to improve the process where it’s been identified as being weak.

We then gather each team together for a reporting session at the end of the week, during which I teased out the common threads in each category, the items that everyone identified. That final session was interesting, and suggests that, despite having been split into small teams (8 people per team, including 1 tester and 1 technical writer) everyone identified some similar issues, and everyone agreed that certain things were working well.

One of the common “what went well” topics was agreement that having a tester and a technical writer embedded in the development team was of benefit, something I thought but hadn’t ever received feedback on until now. That was a nice moment.

Call it a debrief, call it a retrospective, but an honest appraisal is hugely beneficial. It can be hard, and at times the discussions were heated, but everyone was honest and upfront and we should see the benefits over the coming weeks of this release.

Now, does anyone know what I can do with a few thousand Post-Its??

UK readers, Skill Matters are running a session on Agile Retrospectives next week.

Another week has zoomed past, and I’m only now catching up! I’ve been helping out with our development group retrospectives… but more on that later. For now, here are a few things that caught my eye this past week.

Gatekeeper vs. team member
Whilst not directly talking about technical writing, there are some good points in this post, with several mirrors between some of our [sic] processes and that of the self-publishing author:

…some authors, trusting no one but themselves, will put out what they have to say, untouched by any other person. Sometimes this works. Usually it doesn’t. Others will reject the criticism of experts but accept the flattery of a subsidy publisher. Others will embrace the traditional publishing process and accept the input of those who have more publishing experience than they. Others fall along the full spectrum in between.

Is single source always the best option?
Single source, rightly, gets a lot of press and for a lot of companies would be of benefit. However it can be hard to convince others of those, here’s an example:

I know a single source of content will save me a lot of work. But for other people in the company it won’t. It will mean more work for them, not to mention a very steep learning curve, an investment in software and a strong training committment. It will save me lots of time and effort—in the long run—but it’s going to double the work effort of ten other people. Where is the benefit?

The last business case I pulled together this was the sticking point as well. Understanding the pain points, and how much they cost the company is key and the benefits need to be realised over a longer time period than you’d think.

Are you part of the industry conversation?
Anne Gentle (via Twitter) pointed out that Sun now have a formal blogging policy in place for their employees. It’s a great step and shows that they understand the role that blogging can play:

… By speaking directly to the world, without benefit of management approval, we are accepting higher risks in the interest of higher rewards. … The real goal isn’t to get everyone at Sun blogging, it’s to become part of the industry conversation.

Confluence Wiki adds page ordering
I’ve talked about Wikis before, and largely I think the core value comes through long-scale collaboration and, as such, haven’t really considered moving our documentation set to a wiki. There are very good cases for wiki-fying your documentation set of course, but for me there are one too many limitations. This news from Confluence is starting to change that as summed up by Sarah:

When you’re writing a documentation set, the sequence of the pages and chapters is very meaningful. It’s nice… well, many would argue that it’s essential to be able to define a logical page order rather than being stuck with an alphabetical order. Up to now in Confluence, we’ve worked around the problem by manually adding chapter numbers and page numbers, like “1. Introduction”, “2. Installation Guide”, “2.1 System Requirements”, and so on. Now take a look at point 2 in the Confluence 2.8 Release Notes. We can just drag and drop the pages and chapters where we want them. They stay there :) and the new order is reflected in the PDF outputs and hierarchical page-tree views

Thinking like a user
I spend a fair amount of time reminding developers that they have a different mental model from (some of) our user base and that the design may be improved by taking the point of view of the target user. However I should confess that I fall into the very same trap myself:

the problem with being able to think like a user is that familiarity breeds … well, familiarity .. we’re using (at least I hope we are) the applications that we document daily … building a store of information about the application [and] we can easily lose sight of what the new user, who comes to the application tabula rasa, may experience.

Yup. Guilty!

Word 2003 Tip: Edit in Print Preview mode
I didn’t know this one either. You truly do learn something new everyday.