Now that iPhone has landed to my country I have been eager to actually use it for more than five minutes. It’s bling, sure, with it brilliantly fast touch screen, camera, iPod, and instant access to YouTube. All that’s missing is instant access to Facebook – but hey, that can be downloaded as a free add-on application.

I’m sure Apple would like us all to be young, trendy and cool. I actually feel like putting on a pinstripe suit before touching the thing. Don’t know why. I have slight problem deciphering the bright colours, pretty display icons -that remind me of the Google Desktop icon style- and cute sound effects. I like bright colours -as long as they’re not on the clothes that I wear- and think that the display icons are sweet. I smile involuntarily whenever I hear one of the sounds that the device makes. That’s an emotional response if I ever saw one. ‘Nuff said. Let someone else do the psychological analysis on how purposeful this is on Apple’s part.

Yes, yes, yes. So I’m in touch with my inner child and am a hard-core gadget freak at heart. But I’m also a business woman and need a device that supports that role wherever I go. Style-wise, iPhone is a sure thing. It gives the impression that I’m young, trendy, etc, whatever those people in magazines are.

I’ve identified three things that I need as I trek the world and do business. (OK, that’s slightly exaggarated. But better-sounding than commuting in a bus between the city center and the office twice a day). These three things are calendar, e-mail, and office applications.

The iPhone main menu has both Calendar and Mail, so that’s promising. But where’s my Word or Word lookalike? Let’s get back to that one later. First, the Calendar. There’s a month view, day view and a list view where all my meetings are listed. A small dot below the date shows that there’s a meeting on that day. It’s a good, basic calendar. Does what it needs to do. But I’ll still prefer the Calendar in Nokia E71 and Nokia E66 – have you seen them? If not, go to the nearest store that sells Nokia devices and try one out. The Eseries calendar is even clearer and gives me more information at a glance, and there are pop-ups that give you more information about a meeting are excellent, both style-wise and function-wise.

Next, e-mail. It took me 5-10 minutes to set up e-mail, depending on what is the “success” that ends the setup procedure. iPhone didn’t recognise my e-mail service provider, so I had to enter the information there by hand. I had the examples in the fields that had to be filled, which is nice since I can mix the sending and receiving mail server addresses. After I had entered the correct data, iPhone started to verify it. It failed, and promptly told me so. Unfortunately the error message didn’t make sense to me, and then I was offered another verification method and save options. Finally setup informed me that my e-mail may not work properly and sending and/or receiving may be impossible. Well, it works anyway. Now, if only I could find the settings so that I could edit them since my password changed…Where’s my Options list?

OK, finally, the office applications. There are no office applications that I can see, but as I just happened to have a powerpoint in my e-mail, I tried to download that. It downloaded nicely, and I was able to open and view it. How annoying that I would need to make a small edit to it before sending it forward. Luckily I have my new and shiny Nokia E71 – few quick clicks and the edit’s done. I can do all the viewing with iPhone since it zooms the powerpoint’s tiny print like a dream, but will honor E71 as the portable office that it is.

So what’s the end result of this quick&dirty analysis on iPhone as a business device? It works, but there are a few things that I miss from my E71. Combine the good parts of both and you’ll see me in the stores, queuing for a copy of my own.

So, to show that I haven’t completely forgotten TC2.0, I thought that I’d put together a little blog entry combining my core competence with my extracurricular interest, spiced with an international aspect.

In Wikipedia, information design is defined as “the art and science of preparing information so that it can be used by human beings with efficiency and effectiveness.” Naturally, any human being anywhere in the world must be given the possibility to use the information with the same efficiency and effectiveness. This means that the information design must be international.

Making the information design international means that your information plan or [insert-name-of-design-document] shows the requirements from everywhere in the world: legal texts for France, That text input for Thailand, disclaimers for Brazil, warranties for North America – whatever the requirements are in your business area.

Adding this required information can, of course, be handled with checklists from the various regions or countries that have something to add to your “plain” information design, but this approach leaves something to be desired. After receiving the requirements, you may not be able to understand them or may not know where to place them in your information plan. There will be lots of e-mails flying back and forth, which can be frustrating and prone to the “it’s in her inbox and she’s on holiday for five weeks” communication gaps.

But how about using something more 2.0? Create your information plan in a wiki.

Wikis, naturally, are built to support collaborative editing. Anyone can see the who, when and why of an edited piece of text. You, the original information designer, can create the original information plan wiki page and then let the real specialists in the regions/countries to add the information that they need to the correct place in your information plan.

Over time, the original information plan wiki page could grow into a web of wiki pages where the requirements are in their correct place and form wiki pages themselves with additional information on the requirement, its implementation in different projects, and so on.

I’m not saying that this approach would be free of problems. But it’s worth a try, as much as a spreadsheet or a document filled with requirements.

I do not have personal experience from working with agile SW. But fate has thrown some workshops and  seminar presentations about it my way. And when you hear about something where the word combo “no UI specs” pops up sometimes, as a technical communicator, you are bound to get interested.

What kinds of things could agile mean to a technical communicator?

• You need to understand your company’s SW creation process better than you may have before. Written SW  documentation may not be available in the accurate abundance it used to be. You need to understand what and why they are doing in the SW team to get the most information out of it for your own work. In the best scenario in agile, you may need to participate as a team member in the SW team’s work.
• You need to think outside the box and be innovative. The best documentation process for agile SW creation in your company may be very different from your current one. It just might be correct in your situation to do unconventional things like translate unfinished content that is still under development *gasp*. Don’t be afraid to go wild as you are planning the process and aligning it with your agile SW creation. You might be surprised at what works, or what is needed.
• You need to develop your communication skills. I kinda like Bogo Vatovec’s description of the solitary, introvert technical writer which he talked about in the Portland WritersUA conference – I am sort of that type myself. The further you are removed from the agile SW team, the more communication skills you may actually need, as you need to “extort” information from the team members outside their regular, typically face-to-face oral comms.
• You need to develop your inner sense of “good enough”. Even if you are a perfectionist who wants every comma and colon to be in their correct places, you may sometimes need to release very drafty documentation.

But this here is just my speculation. What has agile meant to you in practice?

While these examples are not from the domain of technical communication, they may help us think of technical communication problems as we write instructions. How can you translate this to your own products and your own documentation?

Example 1: Traffic lights 

Sometimes with the traffic lights, there’s a small box in the pole that has a button on it. It may not say anything at all, or then something in the lines of “To cross over, press the button”. If you know what traffic lights are, this is just fine.

But if you don’t – you need a whole lot more instructions to complete your task successfully:

• Conceptual information about traffic lights and what they do
• UI descriptions/term definitions for green and red lights
• Probably some warnings from your legal department, since bodily harm could ensue
• A numbered task sequence with several steps about pushing the button and crossing the street. To promote learning and understanding, you should also tell what pushing the button does, so how the user’s interaction with the UI influences the world.

The lesson: Think whether the users really know the feature you are writing about. They need considerably more information to complete their tasks if they don’t. You must teach them about the new feature.

Example 2: Hairspray

Can you pack hairspray in your luggage that’s going to the air plane’s cargo?

The dangerous goods list on my airline’s page talks about pressurised containers and flammable liquids not being allowed. Technically, hairspray is usually both. But the examples given include stuff like paint and varnish. Because hairspray is not mentioned, does it mean that it is allowed? Or does it just mean that the airline did not remember hairspray at all when writing this?

The lesson:  If you know there are specific use scenarios that the user is interested in, spell out what they are and how they go. For example, not mentioning something at all does not intuitively mean “it must be OK then”.

Example 3: Oxygen masks

You know those safety demos or videos they must show you before an air plane can take off? On the Portland trip, we did one strech with an airline I had not used before. And they had included a really nice point about the oxygen masks.

Normally, you just get the instructions about how to put the mask on. This airline also told you that when the mask is in use, the oxygen flows even when the bag does not inflate. Now this is something I would never think of pondering in advance. But if there was an emergency and I needed to use the mask, I probably would expcet certain behaviour from the mask UI, and get worried whether I am completing my task of getting oxygen successfully. I think this airline did a good job in anticipating that user worry (or perhaps panic would be a better word).

The lesson: Anticipate the problems or questions the users will have when completing the tasks, and respond to them. In tech comms, it is very likely the user picked up your instructions because they are already facing that problem or question, and want an answer.

I’ve been to the WritersUA conference twice and both times have enjoyed it thoroughly. This time I’m bringing friends with me, as my co-blogger TanjaK and two other colleagues are coming with me.

Let’s see if we can blog from Portland – expect to see at least one tiny blog entry. If we’re too jet-lagged to correctly write difficult words such as “web  2.0″ or “component content management”, we won’t be here before week 13.

 Hope to see you in Portland!

Well, it means a lot of things, but one implication is that you need to think outside the box. You need to become all-knowing, all-powerful.

When content is not single sourced or not saved in a content management system, designers and writers typically work for a very specific purpose. They are creating a document for:

• A certain product with a distinct feature set
• A certain audience
• A certain deliverable or channel, for example, a printed user guide or online help
• Perhaps also a certain country or market area – often the one where they themselves are located, even if the document is localised globally

When you are writing for reuse, you must suddenly know a lot more. You must know not only one product very well; you must know all the products that may reuse your content, to some extent. The minimum that you must learn is what features (hardware, software, whatever) typically vary between the products. This way, you can create global, generic content that suits all of them, and know where content must be tagged to allow for variation (like discussed in a previous post).

The content may be used for all kinds of audiences. As with any technical writing, it is essential to have a good audience analysis, so that you know who these users are. More importantly, you need to know what their needs are: what information do they require, are there differences in this between the audiences, and how will you accomplish all this in your information design and technical writing?

What may be the most difficult part is that you must rid yourself of your beloved deliverable, a dilemma discussed also by Gordon McLean. Your content must be suitable for various publishing channels (that your team has defined). You cannot let just one format drive your thinking.

For some of us, this literally means stepping out from the sales box into the world wide web of content.

In one year, web 2.0 has moved to mainstream. I heard my first web 2.0 & technical communication presentations in the IEEE PCS conference in Seattle in 2007. There have been others before that but these were the “firsts” for me.

I’ve been teaching a web design course at the University of Tampere for several years, so moving from web 1.0 (HTML + people as readers) to web 1.5 (XHTML + people as contributors) to web 2.0 (people as content creators) has all been part of a natural growth process for me. Because of my background, it feels very natural for me to upgrade technical communication to technical communication 2.0 as well.

This may not be the case for all technical communicators. Web 2.0 applied to technical communication may make technical communicators fear of losing control – something very natural for us humans (just think how people behave on the web and how hypertext works). If technical communicators have spent their career hunting bits and pieces of information from specifications, software, hardware and various reluctant SMEs and putting that together as a complete information product, relinquishing that control to someone else may be hard.

Should we fear the users taking over our jobs? Are we all becoming editors and moderators of user-generated content? Who are really the experts, technical communicators or the users ? (For an interesting discussion on this matter, see the User-Generated Content vs Experts thread at Slashdot.)

The current situation is described this way:

“teaching has traditionally followed a one-size-fits-all approach to learning, with a single set of instructions provided identically to everybody in a given class, regardless of differences in aptitude or interest.”

The same is true with the static documentation provided by companies – our teaching of how to use the product or service.

How to provide a more flexible, beneficial learning experience? The solution is seen in “‘personalized learning,’ in which instruction is tailored to a student’s individual needs”. Sound familiar? In technical communication, it is already possible to take the first steps towards dynamic content delivery, or providing dynamic, personalised configurations of (static) content.

Are you already doing this? How can we improve the personalisation further, and take into account aspects such as different learning styles?

“When content is reused identically, it is reused without change. Derivative content is reused with change, content stays related to the original component.”

Often content cannot be used for multiple purposes directly as such. In her article, Rockley focused on two issues, the channel and the audience, and how addressing these issues does not mean content could not be reused.

To reuse content effectively, as much as possible of your content should be global and generic. Global content can be published in different contexts as-is, without changes (either identically or through filtered reuse like conditional text). Differentiate only where you must. These must-haves depend a lot on the item you are documenting, the environment for which the content is created, and also on the legacy practices in your organisation.

There are certain methods you can use to achieve reuse, and I’ll discuss two of those briefly here: information design (info architecture of your content) and conditional text.

Information design
In the information design of modular content, you define both the granularity, so size, of your modules and their content. Design as many modules as possible as global content.

• To address variation in product features, for example, try to confine the varying information into separate modules. If there is a feature or component that is not available in all products, instruct it in separate files.
• To address variation in the needs of separate audiences, design the modularity so that different modules speak to different audiences. For example, describe the advanced tasks in separate modules, which can be added to the content only when the audience benefits from this information.
• Like Rockley already describes, to address the needs of publishing formats, you may select to use different modules of the content for different channels. In some industries, the amount of printed documentation is actually decreasing due to various drivers. In cases like these, web channels may actually include more content (more modules) than the print one.

Conditional text
Especially if you need to address several sources of variation in your content, some kind of filtering such as conditional text is just about a must. By tagging complete modules and especially smaller elements inside them, you can reuse the same files directly and still cater for the various needs of software, hardware, products, audiences, countries, market areas, publishing channels…

When the differences are tagged with conditional text, you can maintain the content in a single source and reuse the file identically. The content is just filtered differently; you configure separately for your publishing which tags apply.

Make reuse happen

Rockley describes the caveat of content reuse:

“One thing is important to understand, not all content can be reused identically. You never want to compromise the quality of the content in order to reuse it. Derivative or unique content is OK, just ensure that it doesn’t dominate your content set, rather it is an appropriate part of your content set.”

Especially if your organisation does not have a long history in content management, it is beneficial to always start with the premise of reuse. When considering how to design and author the content, let your first question be “how can this be written as global, reusable content”. This way you are always forced to analyse the situation, and derivative or unique content is created only for solid, valid reasons, not out of tradition.