Smart approach to document profiling (DocBook)

Today I visited a seminar on single-sourcing at Philosoft. We had 2 presentations:

• An overview of MadCap Flare (presented as an alternative to AuthorIT, Help-n-Manual, and in many aspects to FrameMaker).
• A round-up of how single-source documents are created at Philosoft.

The round-up was most valuable.

First, Philosoft writers create genuine single-source documents, where each document is built from content pieces stored in a common database. Unfortunately, they did not quite explain which types of content pieces they have and how they arrived to these types. However, they promised to share this info on their website soon.

Second, I really liked Philosoft's approach to profiling output documents in their DocBook environment. They suggest 3 criteria for profiling:

• Subject for document's subject, e.g. a certain software product, hardware item, or person's role, etc.
• Aspect for document's type, e.g. user's manual, administrator's guide, product reference, etc.
• Profile for subject's or aspect's flavor, e.g. software's version for a certain OS, hardware's model for a certain customer, etc.

These 3 criteria make up a unique combination for each document. The guys say this trinity is quite enough for all profiling needs. Besides, knowing the 3 criteria for each output document makes drafting more focused.

Technically, they use 3 native DocBook attributes to tag conditional elements in a single-source database:

• conformance for the subject
• userlevel for the aspect
• condition for the profile

As for myself, by now I've been maintaining a database with one source XML document for each product's documentation set ("subject" criterion). Where needed, my XML sources are tagged with condition attributes to define the output document's type ("aspect" criterion). For all flavors (e.g. product version) I've been using XML entities ("profile" criterion).

Now I'm thinking of trying the 3-criteria approach and probably fine-splitting my per-product XML sources into pieces to make up a joined database.

Single-sourcing in action

These days I dived into writing a set of 2 documents, Quick Start and Full Guide, based on the same DocBook source. This must be a fine opportunity to try out the guidelines suggested in my new book on single-sourcing (see it on my bookshelf).

Well... Being so clear and simple when I read it, this book proved quite a challenge in practice. A big surprise was to realize that my present writing style is not modular enough. It takes me much effort to make all chunks more independent, so they would read natural when assembled in either target document.

Anyway, I'm pretty sure that the result will be worth the effort. Will keep updating this blog with new impressions as I move on.

The rights of the reader

I liked this short discussion of a humorous poster entitled "The rights of the reader" by Daniel Pennac (he wrote a book with the same name). Indeed, this poster is quite in tune with what user-centered technical writers keep in mind as they write. :-)

Do "late sleepers" really work worse than "early risers"?

I'm a genuine late sleeper. Since my senior school years (it's ~ 12 years now, wow!) I've been studying / working "shifted hours". Most of this time I've been normally coming to school / university / work by noon. And even in my childhood, can't remember if I ever liked the idea of waking up / going to bed early. My creative powers come to their peak in the evening, while squeezing a fresh idea in the morning is murder.

Meanwhile, I often meet people who -- conciously or not -- judge that one must be an early riser to work truly well. Even in the creative sphere of IT this stereotype is popular. Is there any sane psychological ground for it? Or maybe it's just legacy of those times when people had to wake up early to do all the job during daylight?

Odd but true: I love deadlines!

Really, deadlines are my best remedy for writer's block. Time pressing is stressful, but it helps a lot to realize priorities, take decisions, and stop muddling with trifles.

Hilarious video from Font Conference

Ha-ha-ha!.. Can't stop laughing. :-D

Just imagine typing fonts... gather together and hold a conference! All those TNR, Arial Narrow, Futura, Comic Sans, Wingdings et al starring in a short clip. Acting and makeup are superb! Tech writers and all font-concious people will appreciate. :-)

10 mistakes in icon design

Here goes a handy checklist that helps fight typical mistakes in icon design. The author keeps things simple and gives nice illustrations to support his point. Just what an amateur designer like me would need next time when the need for drawing a simple custom icon arises. :-)

Summary:

1. Insufficient differentiation between icons.
2. Too many elements in one icon.
3. Unnecessary elements.
4. Lack of unity of style within a set of icons.
5. Unnecessary perspective and shadows in small icons.
6. Overly original metaphors.
7. National or social characteristics not being taken into account.
8. Images of real interface elements in icons.
9. Text inside icons.
10. Outside the pixel framework.

P.S. Thanks to Desh for sharing the link.

Trends in web design

Today I was surprised to learn that writing about trends in web design is so popular. Just google for something like "web design trend" and you'll get tonns of opinions and design samples!

The topic is not straightforwardly "techwriting", of course. Nonetheless, taking a look at carefully selected galleries boosts both mood and imagination. :-)

Once again about TOCs

Huh, it feels like my blog needs emergent revival with some fresh posts. ;-)

To start with, here comes yet another (wider) collection of creative and beautiful TOCs. I loved it!

"Nu grammar"

Sarah Maddox posted a summary of the "new grammar" session led by Jonathan Halls at AODC (Australasian Online Documentation and Content Conference) she attended. Her summary hooked me.

Jonathan's interpretation of "grammar" turned out much broader than I've ever took it: "the principles or rules of an art, science or technique". Hmmm... After reading Sarah's post, I took some time to read Jonathan's AODC handout Do you have time to read this? and many points of his "nu grammar" philosophy became clearer.

I agree with Jonathan that (a) in the recent years, communication patterns have changed dramatically (yes, in Russia too!), and (b) technical communicators must therefore respond to people's new expectations towards communication. Yes, we must, though often it's quite a challenge. It's true that people now emphasize the importance of faster, easier, and this way more efficient communication. At my current workplace, I mostly write documents for internal use, and colleagues sometimes ask me to shorten some written piece because they feel frustrated to read that much text. In Russian, we even have a popular ditty for this kind of complaint: "mnogabukav niasilil" -- literally "manyletters couldn'tmanage". :-)

I also agree that many innovations in the techcomm area can help us "win the fight" for readers' / listeners' / watchers' time. I like the ideas of adjusting content for speed reading, delivering information in quickly accessible formats, using collaborative environments, encouraging interactivity and authorship delegation, favoring more conversational style over "official language", etc.

However, I still feel "digital immigrant" rather than "digital native" when it comes to applying "nu grammar" ideas to strictly grammar issues. For example, now and then I'm asked to review my colleagues' documents and emails. When I follow "classical" English grammar and stick to Chicago Manual's guidelines, people say I make their prose too heavy. They want lighter constructions (though sometimes wrong in terms of "classical" English), and make me break my head over rephrases that would be both "light enough" and "grammatically correct" (not to say about clarity).

I just can't reconcile myself with the idea of writing technical specifications in instant-messaging style -- even if I knew it would boost understanding. My current "freedom limit" here is Richard Lanham's idea to replace "official style" with everyday though grammatically valid "business prose".

The grace and beauty of TOC

Guys from the Design Observer blog have published a small book, The Next Page: Thirty Tables of Contents. It features Table of Contents (TOC) pages from 30 different publications that range from poetry and fiction to non-fiction prose of all kinds. Meeting so much different TOC styles, designs, and structures gathered in one place was fun. The collection inspired me to pay more attention to TOC design and, as the book's authors promised, I found the examples "engaging, the discrepancies between them even more so."

The book is now available as online slideshow at Design Observer's site. Also, these and 40 more TOC snaps are available on Flickr.

P.S. Thanks to Boris for sharing the link.

No new ideas? Here they come!

Check out a wonderfully inspiring post -- The Birth of a New Idea -- in Dan Blank's blog. Smile and creativity pepper-up guaranteed! :-)

A new kitty

The "kitty family" living at my workplace keeps growing. Now they are two:

Words and money

The two articles, 14 Words That LOSE Money and
200 Words That Make Money, are just fun to read. Also, they give two wordlists that may come in handy when occasionally composing or analyzing some marketing text.

Typical day

The mystery of who technical writers are and what they do at their workplaces in gradually unveiling. In the last few days I found several posts from writers all over the world describing a typical day at work. Well, although the descriptions are typical, they're by no means similar! See for yourself:

A writer's typical day in the USA.

A writer's typical day in China.

A writer's typical day in the UK.

A writer's typical day in Australia.

For me, it was fun to get an insight of other writer's workdays, to find evidence of how different a writer's day can be, and to see what other writers can fit into just one day.

I'll keep updating the list above as I find more posts on this topic (I'm pretty sure there'll be more). Of course, I'll also consider adding my two-pence to this stream. :-)

Agile tech writers

Yesterday I bumped into a couple of awesome posts by Sarah Maddox, a writer at Atlassian. She writes about her team of "agile technical writers" (a.k.a. XTW, or "eXtreme Technical Writers) -- that is, writers who collaborate with Agile (or eXtreme) Programmers.

Sarah generously shares the secrets of their "XTW cuisine". In particular, her description of a typical XTW day in the first post is very informative. Needa think of re-using some of their XTW tricks in my non-agile environment...

Hello, world!

After a year or so of lazy blogging at LiveJournal, I decided to try out blogspot features and services. Hope to find here more ways for self-expression -- and more visitors to read my notes and share their experience.