Archive for June, 2009

h1

Don’t make the next step difficult

June 30, 2009

I got a replacement wireless access point a few weeks back. And like a good citizen, I tried to register my purchase on the Netgear website.

The screen shot below is part of their product registration page (there’s another section to the right that I didn’t capture, which is for Returning users with existing login details):

Netgear's product registration page

Netgear's product registration page

So, what’s wrong with this, you might ask? In summary, neither the process nor the ‘call to action’ are clear. Specifically:

  • The Registration button in the navigation bar returns you to this page.
  • The Activate your support contract(s) link returns you to this page. Huh?
  • The Continue button. What Continue button? Yep, it’s hard to see but it’s below the text in the same font size and color as the body text. The background color is so faint that on certain monitors in certain light conditions this button is almost impossible to see. In fact, I refreshed this page, clicked all the other options (some even twice) before I even saw it! When I clicked on it I was taken to page 1 of 4 for registering my product (more on that in a moment…).

A new user to this site is likely to give up because just starting the registration process is difficult to do. By the way, why does it takes FOUR pages plus this front page to register a Netgear product? It’s not a bank loan! No wonder people don’t register — they’d get turned off even if they found and clicked the Continue button.

So how can this process be improved? Luke Wroblewski, in his session at the 2009 WritersUA Conference, gave many guidelines, of which two in particular are relevant to this initial page:

  • Show progress towards completion. [Netgear did this on the four registration pages, but there was nothing on the initial page that helped.]
  • Commands: Not all form actions are equal. Reset, Cancel, Go Back rarely need to be used, so can be omitted or relegated to lesser importance using faded color, smaller size, etc. Primary actions directly responsible for form submission include Submit, Continue, Next, Save etc. Make these larger or a brighter color to emphasize their importance, and align such that they are part of the clear path to completion.

Just making the Continue button larger, with a different (brighter) background color, and different font size to the rest of the page would’ve helped — a lot.

To restate my mantra — courtesy of Steve Krug: “Don’t make me think!”

[Links last checked June 2009]

h1

Documenting a live user interface

June 29, 2009

Bill Swallow, the TechCommDood and an all-round nice guy, made this comment on Twitter a week or two ago:

Trying to document a UI that’s in live development is like trying to repair a moving car or building a sandcastle at the water’s edge.

Hear, hear!

h1

Content types: Metadata for content

June 28, 2009

If you’re thinking of moving toward structured authoring, DITA, or other similar methodologies, you’ll need to get your head around content types.

The Content Strategy Noob has posted a very readable and understandable article called “Content Typology: Getting a Handle on your Content Types“, which should help!

[Link last checked May 2009]

h1

Word: Change date format from Excel data

June 27, 2009

When you’re using an Excel spreadsheet for mail merge data in Word, any dates come in in the ‘native’ Excel date format even if you’ve changed the date format for the relevant cells in Excel. From what I can gather the ‘native’ Excel date format is the US date format of m/dd/yyyy (e.g. 9/30/2009 for September 30, 2009).

If you want the date in the mail merged document to be displayed differently, e.g. UK/Australian date format dd MMMM yyyy (30 September 2009), then you have to add a switch to the mail merge field.

Here’s how you do it in Word 2003 (Word 2007 is probably the same, though I haven’t tested it):

  1. Insert the mail merge field for the date into the Word document as normal. It will look something like this (where StartDate is the name of the mail merge field in this example):
    date_format_mail_merge01
  2. Right-click on the mail merge field, and select Toggle Field Codes.
    date_format_mail_merge02
  3. Put your cursor after “StartDate” and before the closing } and add a space.
  4. Type in the switch: \@ “dd MMMM yyyy”
    date_format_mail_merge03
  5. Right-click on the mail merge field again, and select Toggle Field Codes.
  6. Save the document. The next time you run a mail merge, the date will be in the format you entered at Step 4.

This example shows just one date format switch — experiment with other combinations to get the date format you want. For example, “MMMM dd, yyyy” for September 30, 2009; “dd-mm-yy” for 30-9-09, etc.

h1

Offshoring, outsourcing and globalization

June 26, 2009

A week or so ago someone on one of my STC technical writing email discussion lists posted this:

I hear that tech writing pundits and trend watchers are predicting the eventual demise of the tech comms field due to globalization. A few good years left then – kaput. We will all be out of business due to competition from offshore. Best to move into a line of work that can produce a profit for employers (unlike tech comm) AND requires an onshore presence, i.e., can’t be done remotely from thousands of miles away.

After I’d settled down a bit (!), I responded as follows:

As an international member of STC, I won’t write what I felt when I read this, so here’s the polite version:

  • What do you class as ‘offshore’? Everybody lives somewhere and any country/continent where they don’t live can be classed as offshore — from their perspective.
  • If ‘onshore’ means the US or perhaps North America (US + Canada), then you have forgotten that STC is an international organisation. Therefore many members do NOT live in the US/Canada. With attitudes like those you expressed, it’s no surprise that many former international members of STC left the organisation, and continue to leave it.
  • My ‘onshore’ is Australia. If I send work to the US (as I have done several times), then that’s ‘offshore’ for me. A US citizen gets the work and gets paid. What’s wrong with that? If you see nothing wrong with that, then why do you think it’s wrong when it’s the other way round? (and yes, I’ve done work for companies in the US and Israel) Should I, as an Australian, only ever send work to other Australians? Should I assume that someone from outside Australia can’t do the work? (Now substitute another country’s name in the last two questions and see if you get the same answers!)
  • If you think it’s OK for me (as an Australian) to do work for US companies, then which countries are you referring to when you talk about ‘competition from offshore’? Are some countries ‘better’ than others? Are some countries acceptable, but others not? Which countries? Why?
  • ‘Thousands of miles away’ can mean within country. The US is a vast place, as is Canada, Australia, etc. I work remotely with ALL my clients, whether in my home state (3 hours to my capital city), within my own country (min. 3 hour flight to my nearest state), or on the other side of the world. I am always at least hundreds, if not thousands, of miles away from my clients. It has not been an issue.

A blog post earlier this week from Your Writing Dept in Sacramento — titled Outsourcing vs. offshoring, and how U.S.-based technical writers can stay competitive — adds a slightly different perspective, as well as explaining very well the differences between outsourcing (which is what I do all the time) and offshoring (which is what I do some of the time).

My only beef with this well-written article from Your Writing Dept was the title — despite the reasoned arguments, the good advice, and the excellent final paragraph, the title had a very US-centric feel to it. Which I guess is OK as the writer is based in the US ;-)

h1

What’s wrong with this picture?

June 25, 2009

Our local motoring organization (like AA, AAA etc.) publishes a monthly magazine for members. An article in the June 2009 issue was on the importance of eye tests for seniors, especially for tasks such as driving.

Here’s part of the article:

Eye test article

Eye test article

Anybody see anything wrong with this article (other than it’s a little fuzzy from my camera)?

How about the colors and font size used? The article was on a light to mid-gray background, in white font, and with a font size of about 9 or 10 pts. Surrounding articles were on a white background with black font at the same font size — and were easy to read.

This article aimed at seniors was very difficult to read. I would suspect most seniors would have problems reading it unless they were in good light, had their glasses on and perhaps had a magnifier as well.

Perhaps the editor is only 25, but why did no-one else pick up that decreasing the readability of an article is not a good thing, especially when the target audience are the ones most affected by deteriorating eyesight? And to add to the irony, the article is ABOUT eyesight…

I shake my head.

h1

Presentation: Customizing HTML Outputs from Author-it

June 24, 2009

I delivered this presentation at the annual WritersUA Conference in Palm Springs in 2006.

Be aware that Author-it software has been updated several times since 2004 so some of the techniques shown in this presentation, which applied to v4.x, may not be relevant now.

All accompanying handouts are available from the CyberText website.

The focus of this presentation was on:

  • how the various Author-it pieces fit together and what you need to make it all work
  • how to modify the default HTML templates for HTML-based Help and websites
  • how to set up Author-it to produce HTML newsletters
  • how to set up Author-it to produce HTML-based slide presentations

[Links last checked April 2009]