Grammar Rocks! – Literally!

Do you know someone who abuses the word “literally”?

Maybe they just want you to know they really, really, really mean it. Maybe they actually mean “figuratively”, but didn’t look it up.

One simple music video can change all that…

Horrible Histories Viking's "Literaly" video

You know who paints the whole town red, literally?

Vikings, that’s who.


Thanks to the BBC’s “Horrible Histories” show for disguising facts as fun.


Sample of Creative Editing and Editing with Online Best Practices

Original Online Mission Statement

Revamped Online Mission Statement

The most important change is: rather than saying MarinLink is “nimble”, show that it is nimble using active language that takes less time to read.

My big question is are those arrows too garish?

GUI Principles: Focus on the Users and Their Tasks, NOT on the Technology

This topic is of utmost importance for all Technical Communicators in all sectors.

Even non-help system documentation is rarely in print anymore, but needs to be legible and useful from a computer screen of various dimensions and display capabilities. We must admit that it needs to be useful for reading on the fly at the particular time it is needed, often in an emergency.

We are the only ones who read manuals in advance of need, and we cannot win as professionals if we hold on to that ideal.

We need to make complex information easy to read onscreen, clear, compact, precise and easy to navigate.

To do that the main focus needs to be the audience and their vital needs. This focus is true for Software Architects, User Interface Designers, Document Publishers, Help Designers, and every person implementing their slice of the product.

The User Interface is the product. Features are not implemented, when they are obscured. The doers of the work are likely learning on the fly as they try to do their work with your new tool, as in a stressful economy, the training and education budget is one of the first to be axed. Even if the tool will do the job, if it is unknown, or difficult to operate, Users want to get a new tool, and often can.

The best thing that you can do is test your piece of the Technical Information on as many members of your audience as you can quickly grab (in with the developmental stages is even better). More people and more recording is better, but a half an hour with a basic screen mock-up on single office/personal volunteer is priceless in building the best.

Jeff Johnson has a wonderful section in “GUI Bloopers 2.0” on understanding the Users and the Tasks that should underpin every tool or document. Many people have also written well the topic of using surveys and interviews to learn about the audience. What shines is Jeff’s discussion on technical level, and his breakdown of the types of information to study:

  • General Computer Knowledge
  • Task Knowledge
  • System Wide Knowledge
  • Goals of using the tool.

Knowing users’ reasons to use the tool could impact how the user interface, help feature, and documentation is shaped at a very fundamental level. Knowing the architecture of the whole system should similarly help shape the conventions of presentation, and division of content. The level of security clearance required for certain tasks could result in the need for two separate documents, as an example. General Computer and Task knowledge might correlate along predicable lines, or not.

If this principle of the highest dedication to users, goals, and tasks is followed above all, we can and will prevent frustration, stress, and create client success.

The Bloopers associated with failing this principle are from all types, but the Management Bloopers in Chapter 8 are some of the worst offenders, which will be the next topic. That is bloopers made by Management (ie: The Man), not errors of writers’ or editors’ management.

I look forward to future rants discussions on:

#64: Treating UI as a low priority.
#66: Discounting the value of testing and iterative design.
#67: Anarchic Development.
#68: No task expertise on the team.

Metadata Tips for Microsoft Word and Photographs: Presentation on Wed 9/21

I am speaking on “Metadata Tips for Microsoft Word and Photographs” at the September 21st (Wednesday) SF STC Chapter meeting @ SF State Downtown Campus, 835 Market Street, Room 608

More details at the STC San Francisco home page, including reservations and free first visit! Please come!
What is “data about data,” and how can it help you organize files: text, media assets, and Microsoft Word docs? Today’s content management systems demand a working understanding of metadata. We will cover the basics and the specifics about how to access, add, and customize metadata in the Microsoft Operating system, so you can reap the benefits in your own files.

The Periodic Table of SEO Ranking Factors: Visual Elements Showing Relationships and Flow

The best info-graphic explaining White Hat Search Engine Optimization (SEO) best practices that I have ever seen:

I love this great resource and had to share. Note the division of SEO factors that need to be provided on the site itself, other online, and geographical reality. And the steps and elements themselves aligned with the concepts.

Handy Black Hat SEO trends are also listed. Make note of everything on the list, especially the violations that can kill or delay a pages inclusion in one or more search engines.

 The info-graphic shows a Periodic Table of Elements grouped in sections: On the Page SEO, Off the Page SEO, Violations, and Blocking.  On the Page CEO Section has three columns: Content, HTML, and Architecture. The Content elements ar: Quality, Research, Words, and Engage. The HTML column elements are Titles, Description, and Headers. The Architecture column elements are Crawl, Speed, URLs. Off the Page CEO Section has four columns: Links, Social, Trust, and personal. The Links elements are Quality, Text, and Numbers. The Social Column elements are: Reputation and Shares. The Trust column elements are Authority and History. The Personal column elements are: Country, Locality, History, and Social. The Violations Section has a row of elements: Thin, Stuffing, Cloaked, and Paid links. Stuffing is associated with the Hidden element, and Paid Links to Link Spam. The first letter of each “SEO element” comes from the subgroup that it’s in. The second letter stands for the individual factor.

A Few of Their Short Tips for Search Engine Optimization

Search Engine Optimization Factors Work In Combination

No single SEO factor will guarantee search engine rankings. Having a great HTML title won’t help if a page has low quality content. Having many links won’t help if they are low quality links. But having several positive factors can increase the odds of success. As for negative factors, they obviously can worsen the odds.

On The Page search ranking factors are those that are entirely within the publisher’s own control. What type of content do you publish? Are you providing important HTML clues that help search engines with determining relevancy? How does your site architecture help or hinder search engines?

Off The Page ranking factors are those that publishers cannot directly control. Search engines use these because they learned long ago publisher signals alone don’t help relevancy. Some publishers will try to make themselves seem more relevant than they are, for example.

More important, with billions of web pages to sort through, looking only at on-the-page clues isn’t enough. More signals are needed to better estimate what are the best pages for any particular search.

Make no mistake. Search engines want people to perform SEO. They provide help directly about SEO techniques and encourage this, because good SEO can improve their listings.

However, there are some techniques that they deem “spam” or “black hat,” acts that if you do could results in your pages getting a ranking penalty or worse, being banned from the search engines entirely: Blocking, Weighting, and Violations.

Here is a link to a PDF version of the Table Guide. Also a link to the PDF version of The Periodic Table of SEO.

Table used with permission.

My Very First Mistake: Blooper # 22: Inconsistent Terminology

Art Technology Group hired me as an Administrative Assistant for their San Francisco Software Support team at the start of 2001,  and automated a large part of my job only two months later. I started apprenticing as the team’s licensing issue “expert” (it was a frequent and easily solved problem), and gradually worked up to harder cases as I gained more experience with Java and tools we worked with.

The very first mistake I caught myself making, I would later realize was Jeff Johnson’s blooper #22,  Inconsistent Terminology.

Coming from an English Literature and Grammar background, I had umpteen years of schooling that synonyms were worth extra points in pleasure writing.  You could shade meanings, vary the tone and rhythm of your prose, reach a more sophisticated audience, and generally get a higher grade. I found I had an aversion to using the same term over and over in a technical discussion or instructions. It sounded redundant to my ears.

I found that when I did succumb to the lure of the that alternate wording, I soon regretted it.

My audience needed more clarity to make sure that my instructions were understood. And in a crisis situation, no one wants to be unsure.

There are so many complex programs in our workplaces and personal lives, you just can’t read the manual first, you need to find crucial information on how they work, as you go, often, in the middle of a crisis.

And if your application or documentation can’t be understood on the fly in a crisis, you risk loosing your audience.

Lose that synonym habit!

Posted in Tip