Archive for the ‘Writing’ Category

Improving User Experience in Manuals

Wednesday, February 6th, 2013

Improving User Experience in Manuals by Anastasios Karafillis.

From the post:

The manual: possibly the most awkward part of a user’s experience with a product. People avoid manuals whenever possible and designers try to build interfaces that need not rely on them. And yet, users and designers would certainly agree that you simply must provide a proper manual.

The manual can be a powerful tool for unleashing the full potential of an application, something of benefit to users and vendors. Why is it, then, that manuals so often seem to confuse users rather than help them?

Let’s look at the most common difficulties faced by technical writers, and how to best deal with them to improve the user experience of manuals.

“…a proper manual.” Doesn’t seem to be a lot to ask for.

I have seen some better than others but they were all fixed compromises of one sort of another.

Ironic because SGML and then XML advocates have been promising users dynamic content for years. Content that could adopt to circumstances and users.

Instead we gave them dead SGML/XML trees.

What if you had a manual that improved along with you?

A manual composed of different levels of information, which can be chosen by the user or adapted based on your performance with internal tests.

A beginning sysadmin isn’t going to be confronted with a chapter on diagnosing core dumps or long deprecated backup commands.

A topic map based manual could do that as well as integrate information from other resources.

Imagine a sysadmin manual with text imported from blogs, websites, lists, etc.

A manual that becomes a gateway to an entire area of knowledge.

That would be a great improvement in user experience with manuals!

Mathematical Writing

Wednesday, December 5th, 2012

Mathematical Writing by Don Knuth, Tracy Larrabee, and Paul M. Roberts.

From the course catalog:

CS 209. Mathematical Writing—Issues of technical writing and the effective presentation of mathematics and computer science. Preparation of theses, papers, books, and “literate” computer programs. A term paper on a topic of your choice; this paper may be used for credit in another course.

Stanford University, Fall, 1987.

An admixture of notes, citations, examples, and war stories by several legends in the world of CS.

While making a number of serious points about writing, the materials are also highly entertaining.

I first saw this in Christophe Lalanne’s A bag of tweets / November 2012.

10 Tips on Writing from David Ogilvy

Monday, December 3rd, 2012

10 Tips on Writing from David Ogilvy by Maria Popova.

From the post:

How is your new year’s resolution to read more and write better holding up? After tracing the fascinating story of the most influential writing style guide of all time and absorbing advice on writing from some of modern history’s most legendary writers, here comes some priceless and pricelessly uncompromising wisdom from a very different kind of cultural legend: iconic businessman and original “Mad Man” David Ogilvy. On September 7th, 1982, Ogilvy sent the following internal memo to all agency employees, titled “How to Write”:

The one where I fail is: Never write more than two pages on any subject.

And could use the storing emails overnight and re-editing the next day.

Which ones would benefit you the most?

Spundge

Saturday, December 1st, 2012

First look: Spundge is software to help journalists to manage real-time data streams by Andrew Phelps.

From the post:

“Spundge is a platform that’s built to take a journalist from information discovery and tracking all the way to publishing, regardless of whatever internal systems they have to contend with,” he told me.

A user creates notebooks to organize material (a scheme familiar to Evernote users). Inside a notebook, a user can add streams from multiple sources and activate filters to refine by keyword, time (past few minutes, last week), location, and language.

Spundge extracts links from those sources and displays headlines and summaries in a blog-style river. A user can choose to save individual items to the notebook or hide them from view, and Spundge’s algorithms begin to learn what kind of content to show more or less of. A user can also save clippings from around the web with a bookmarklet (another Evernote-like feature). If a notebook is public, the stream can be embedded in webpages, à la Storify. (Here’s an example of a notebook tracking the ONA 2012 conference.)

Looks interesting but I wonder about the monochrome view it presents the user?

That is some particular user makes their settings and until and unless they change those settings, the limits of the content they are shown is measured by that user.

As opposed to say a human curated source like the New York Times. (Give me human editors and the New York Times)

Or is the problem a lack of human curated data feeds?

Read this: Revising Prose

Friday, November 30th, 2012

Read this: Revising Prose by Jason Zimdars.

From the post:

There are plenty of books that will teach you to be a better writer, but I’ve never found one so immediately useful as Revising Prose by Richard A. Lanham. Following along as Lanham revises example upon example of real world writing is like exercise for your writing muscles.

My favorite takeaway is this tip for improving the rhythm and cadence of your writing. Many of us have learned to read text out loud as a method to reveal awkward transitions or generally dull passages, but you can also spot poor rhythm visually. A red flag for dull cadence is a run of sentences that are all of similar length. Try adding a carriage return after every sentence or phrase, the rhythm is evident:

This looks like an interesting and easy technique to use on your own as well as the prose of others.

The better a writer you become, the easier it will be for potential clients, colleagues and others to understand what you have written.

Modulo that if you go into “public service” as they say in the United States, being understood may put you at a disadvantage.

As with most advice, it could go either way. ;-)

Calligra 2.6 Alpha Released [Entity/Association Recognition Writ Small?]

Wednesday, October 17th, 2012

Calligra 2.6 Alpha Released

The final version of Calligra 2.6 is due out in December of 2012. Too late to think about topic map features for that release.

But what about the release after that?

In 2.6 we will see:

Calligra Author is a new member of the growing Calligra application family. The application was announced just after the release of Calligra 2.5 with the following description:

The application will support a writer in the process of creating an eBook from concept to publication. We have two user categories in particular in mind:

  • Novelists who produce long texts with complicated plots involving many characters and scenes but with limited formatting.
  • Textbook authors who want to take advantage of the added possibilities in eBooks compared to paper-based textbooks.

Novelists and text book authors are prime candidates for topic maps, especially if integrated into a word processor.

Novelists track many relationships between people, places, things. What if entities were recognized and associations suggested, much like spell checking?

Not solving entity/association recognition writ large, but entity/association recognition writ small. Entity/association recognition for a single author.

Text book authors as well because they creating instructional maps of a field of study. Instructional maps that have to be updated with new information and references.

Separate indexes could be merged, to create meaningful indexes to entire series of works.

PS: In the interest of full disclosure, I am the editor of ODF, the default format for Calligra.

All Presentation Software is Broken

Thursday, May 17th, 2012

All Presentation Software is Broken by Ilya Grigorik.

From the post:

Whenever the point I’m trying to make lacks clarity, I often find myself trying to dress it up: fade in the points, slide in the chart, make prettier graphics. It is a great tell when you catch yourself doing it. Conversely, I have yet to see a presentation or a slide that could not have been made better by stripping the unnecessary visual dressing. Simple slides require hard work and a higher level of clarity and confidence from the presenter.

All presentation software is broken. Instead of helping you become a better speaker, we are competing on the depth of transition libraries, text effects, and 3D animations. Prezi takes the trophy. As far as I can tell, it is optimized for precisely one thing: generating nausea.

Next Presentation Platform: Browser

If you want your message to travel, then the browser is your (future) presentation platform of choice. No proprietary formats, no conversion nightmares, instant access from billions of devices, easy sharing, and more. Granted, the frameworks and the authoring tools are still lacking, but that is only a matter of time.

Unfortunately, we are off to a false start. Instead of trying to make the presenter more effective, we are too busy trying to replicate the arsenal of useless visual transitions with the HTML5, CSS3 and WebGL stacks. Spinning WebGL cubes and CSS transitions make for a fun technology demo but add zero value – someone, please, stop the insanity. We have web connectivity, ability to build interactive slides, and get realtime feedback and analytics from the audience. There is nothing to prove by imitating the broken features of PowerPoint and Keynote, let’s leverage the strengths of the web platform instead. (emphasis added)

Imagine that. Testing your slides. Sounds like testing software before it is released to paying customers.

Test your slides on a real audience before a conference or meeting with your board or important client. What a novel concept.

By “real audience” I mean someone other than yourself or one of your office mates.

When you are tempted to say, “they just don’t understand….,” substitute, “I didn’t explain …. well.” (Depends on whether you want to feel smart or be an effective communicator. Your call.)

Presentation software isn’t fixable.

Presenters on the other hand, maybe.

But you have to fix yourself, no one can do it for you.

Let us abolish page limits in scientific publications

Thursday, April 19th, 2012

Let us abolish page limits in scientific publications

Daniel Lemire writes:

As scientists, we are often subjected to strict page limits. These limits made sense when articles were printed on expensive paper. They are now obsolete.

On the contrary, page limits (or their digital equivalents) are more important in a digital setting than when articles appeared in print. (Research data, source code and the like should not be subject to limits but that is a different issue.)

Why?

Perhaps you have heard of the DRY principle:


Don’t

Repeat

Yourself

The hazards of repeating yourself inconsistency, change of one reference and not another, etc., are multiplied in prose writing.

Why?

At least in computer programming, if you otherwise follow good programming practices, some of your tests or even the compiler will catch repetition as a bug. Which can then be fixed. Repetition in prose lacks the advantage of a compiler to catch such errors.

Do you want to be known for “buggy” prose?

Moreover, good writing isn’t accidental. It is a matter of domain knowledge, hard work and practice. Write in a sloppy fashion and before too long, bad habits will creep into your “professional” writing.

Do you want to lose the ability to express yourself clearly?

Finally, your writing reflects your respect (or lack thereof) for readers. Your work is being read for possible use in publications or research. Why would you inflict poor writing on such readers?

To me personally, poor writing reflects a poor understanding of content. Is that how you want to be known?

tl;dr

Saturday, April 7th, 2012

tl;dr

John D. Cook writes:

The slang “tl;dr” stands for “too long; didn’t read.” The context is often either a bad joke or a shallow understanding.

What bothers me most about tl;dr is the mindset it implies, scanning everything but reading nothing. I find myself slipping into that mode sometimes. Skimming is a vital skill, but it can become so habitual that it crowds out reflective reading.

I despaired when I read in the comments that someone used this as their entire review of an ebook version of “Moby Dick.” I have read it more than once and didn’t really notice the length, other than to be disappointed with I reached the end.

On the other hand, I have read short conference proposals that required me to force myself to the end of a three page abstract. Being uncertain at the end if the authors actually had a point or were trying to conceal some point.

Reflexive reading isn’t encouraged by some user documentation, which is written carelessly, inconsistently and apparently for the purpose of claiming it exists.

To avoid seeing the use of “tl;dr” on your work, convey some of your excitement about it by caring enough to write well. Readers will recognize your writing as a cut above the average and may consider that as a good sign about your software.

Best Written Paper

Saturday, March 24th, 2012

Best Written Paper by Michael Mitzenmacher.

From the post:

Daniel Lemire pointed to an article on bad writing in science (here if you care to see, not CS-specific), which got me to thinking: do we (in whatever subcommunity you think of yourself being in) value good writing? Should we?

One question is what qualifies as good writing in science. I’m not sure there’s any consensus here — although that’s true for writing more generally as well. While colorful word choice and usage can garner some attention* (and, generally, wouldn’t hurt), unlike what some people may think, good writing in science is not a vocabulary exercise. I find that two key features cover most of what I mean by good writing:

  1. Be clear.
  2. Tell a story.

Those two points cover “good writing” for all types of writing.

A Coder Interview With John D. Cook

Thursday, March 1st, 2012

A Coder Interview With John D. Cook

I have cited John D. Cook’s blog more than once.

I must confess that I cited this interview for the following quote:

What advice would you offer to an up-and-coming programmer?

Learn to express yourself clearly in writing. Buy a copy of Strunk and White and read it once a year.

If you’re a genius programmer but you cannot or will not write English prose, your influence will be limited.