Friday, June 26, 2009

Shout out to Balsamiq for believing me when I said I had a license but I changed laptops. They sent me a new license (thanks, Val).

Check out their product Balsamiq Mockups. It's a low-fidelity wireframing tool that has an informal hand-drawn look. I have used high fidelity wireframe tools and one of the problems is that people fall too easily into pixel pushing if it looks like it's meant to be a final product.

At any rate, check them out; it's $79 and way cool--and they're way cool!

No this isn't a discussion of hyphenated vs. not hyphenated. It examines the difference between putting a PDF file on the Internet (what I call an on-line document) and having a truly electronic Web presence for that content (what I call an online document). Unfortunately, the two often get bundled together.

I have a UXmatters column called PDF Manuals: The Wrong Paradigm for an Online Experience that highlights my arguments for not putting user manuals on line as PDF files. It deals with the artificial constraints such as page breaks that make no sense in the context of an online experience.

In my blog today, however, I want to focus on other kinds of publications, namely journals and magazines, and the impact of taking them...what? online or on-line.

But first, let's play a mind game. Anybody still remember encyclopedias? What if encyclopedias were bound, NOT alphabetically by topic but by when the articles were written. Is that a better organizational scheme? Not at all! But in essence, isn't that what a collection of journal issues is? With the exception of a few theme issues, the only thing the articles in a volume have in common is their publication date. So if I want to read about Usability, I have to grab a handful of these issues to get to all the articles. Can you imagine trying to read about the Civil War in an encyclopedia and first having to find the volumes that applied--based on when the sections were written?

Because of how journals and magazines were published, this was an artifact of the technology and the processes imposed. It was never a good way to organize content.

OK, so as we go online with the content that has traditionally been in journals or magazines, why would we keep this organizational structure?

Let's take a model I am very familiar with and have a lot of emotional attachment to: Technical Communication and Intercom, the two STC publications. I personally love having them in print for two reasons:

I like publishing in them and being able to display them on my coffee table--I realized that about myself when I published in the UPA Journal, an on-line journal, and noticed the lack of the "hunter's thrill" in not being able to display my trophy.

Just having the physical presence of them arriving makes me feel smarter, or at least feel I'm about to get smarter--if I read this issue, and I will, let me just put it here with some other stuff I haven't quite gotten around to reading yet, hmmmm, this one is March 2002, my my time has certainly been flying.

But if I quit thinking about publications for a moment and think instead of knowledge and some realistic contexts of when that knowledge could be useful, journals and magazines just don't seem to be the answer, or their capabilities pale in comparison to what current technologies can do.

OK, let's do the Conan O'Brien thing where we put a flashlight under our chin and someone chants in falsetto "In the year 2000" (Yeah yeah it's well past 2000 but Conan knows a good tag line when he finds one) and see what it would mean to have a truly online (no hyphen) journal and magazine.

I have a question about Usability, maybe a big question like "what is it" or a tiny question like "how do I do a card sort?" I go to the STC Body of Knowledge Portal and enter usability. I'm taken to a web page that has a general overview of what usability is and its place within the practice of Technical Communication. Now I see that I can link to rigorous research articles, practitioner articles, vendor websites, and other websites that deal with usability. I decide to read an article that says it's been peer reviewed and meets the rigor of scholarly research--let's say the abstract associated with the link made me believe it would be of interest to me. I open the article and get a little overwhelmed by some of the research methodology, as in, "Yikes what is an ANOVA?" Wait, a link in the sidebar "Tell me about ANOVA." I take it and get a quick layman's description of what it is and what I should look for as a critical reader. I read the article and it seems to make a lot of sense to me. Wait, here's a comment from a reader that says the literature review missed some important contributions and provides them. Hey! Speaking of literature review, about half of the references at the end of the article have links to the references themselves. And of course, the Amazon.com technique of "Readers who read this article also recommend..." Wow, here's a link to an STC content focus group on usability. Let me check into that as well.

Suddenly, I'm missing my journal and my magazine less. I know as an author, I will not be able to put my contribution on the coffee table and I would be lying through my teeth to say I will not miss that. But publishing should never be about pleasing the author, it should be about serving the reader.

I know as a reader, I must give up the vicarious joy in that others are smart and I will be too as soon as I get time. But now I can get smarter on a just-in-time and as-needed basis because I know where to go when I need to be smarter about a topic in my field.

Monday, June 22, 2009

State of the ark: A phrase I coined (I think) to represent feeling that the technology you are using is so cool when in reality it is like so yesterday.

For example, I got a new phone this weekend that I think is neat because it slides open, and I can display my wife's picture and have a special ring-tone when she calls. Other than that, it just makes and takes calls. Someone wanting to mock my enthusiasm could say "Mike's new phone is state of the ark." It would simultaneously mock my phone and my technology naivete. Sort of like "Bless his heart."

Friday, June 19, 2009

One of the themes that keeps coming at me as an officer of STC is that STC needs to modernize its image so that it has more appeal to the upcoming generation of technical communicators. Our demographics certainly show that we have to increase our appeal to a younger segment of the industry.

It reminds me of when I was speaking at a CDC conference on healthcare communication and my topic was Web usability. Someone in the audience asked the question, "I'm designing a Website for young African-American males, what advice can you give me?" My reply was "Don't take advice from a fifty year old white guy."

Good advice then, and I'm in a similar dilemma now (only ten years older). I need to recruit people whose skills I really can't judge, and I need to direct work I'm not situated to evaluate. I just have this amusing vision of me and my peers among the board and senior staff (albeit with some exceptions) sitting around saying, "Yeah, this is the stuff that young people want."

The best advice I can come up with is "Use the Force, Luke." Seriously, I need to include younger folks I trust at a gut level who seem to have a good reputation among the demographic I'm trying to reach, and then suspend my own "But that's not how I would do it" reflex.

In fact, it might be a good idea to reject any proposal I like. {sigh}

Thursday, June 18, 2009

I took a pretty intense course during my doctoral studies that explored different ways we can study our interactions in groups. I learned a lot about myself, and the title of my blog today is the title of the reflective report I wrote. It was the defining characteristic I had discovered about myself that was making the wheels come off in some of my key interactions.

I still have the problem, but I am more aware of it and hopefully self-regulate faster and better when I fall back into it. For example, I corrected my wife last night when she referred to that thing I use to propel my kayak as an "oar." "No, honey, it's called a paddle." I knew what she meant, so why sidetrack a perfectly good conversation? At least it was just the two of us--sometimes I stop the flow of a meeting or presentation to make a similarly useless point. Hopefully not as much as I used to.

Why am I blogging about this?

Technical communicators, as a breed, suffer from a similar hang-up, perhaps more accurately described as "I must copy-edit every document and conversation I touch." Perhaps the worst offenders are The Typo Eradication Advancement League (TEAL), who actually go as far as to deface historical artifacts they feel have been punctuated incorrectly. But there is a little TEAL in all of us.

What's wrong with taking a stand for correct language?

First, by who's definition? I am notorious for getting as much use out of a document as possible, so I get to see myself edited on what is essentially the same article by multiple editors. Trust me, folks, there is not a consensus even among top editors about the best way to turn a phrase. What I change to suit one I must put back to suit another.

Second, it's often idiosyncratic. It's not that what the original person has said is wrong, it's just not how the person correcting it would have said it. Fine, get in on the act when the page is blank and you get to say it exactly as you would like.

Third (and most important) it gets in the way of the conversation and shifts the focus from substance to style. Sure, edit away at a user assistance file that's going out to the public, but we can keep quiet about the typo in the e-mail or worse yet what a person says in conversation.

Here are some questions I am going to try to ask myself more before I say, "Shouldn't that be...?"

Is it worth the speed bump I am about to insert in the conversation or the process?

Will it make a real difference in meaning or am I just spraying the bushes to put my scent on them?

Monday, June 15, 2009

The Atlanta STC chapter had a great community-building event: We went to a minor league baseball game as a group. We went to see the Gwinnett Braves (the farm team for the Atlanta Braves). Tickets were $6.00 and parking was $3.00. We tailgated and had a fun time. Great little stadium, cold beer, and a lot of grass I don't have to mow. What more could you ask for? There was one fist-fight over the serial comma rule, but other than that, a good time was had by all. (OK, I'm kidding about the comma rule fist fight, but a good time was had by all.) Thanks, Jen and Rachel for a creative event to bring professionals together in a social context.

Friday, June 12, 2009

I am working on writing some high level patterns for what kind of content users need. One of the patterns is "Product Overview" and I was just starting to think about it when...

...all of a sudden I win a copy of Madcap Flare! Now, this is the third time I've won a copy of Madcap Flare, and the first two times I donated them to my alma mater, Southern Polytechnic State University. This one I'm going to keep. For one thing, now that I am sixty, I realize that one day I will retire from IBM and not have access to the Information Developer's Work Bench, so I had better start coming back up to speed on other products if I want to teach/consult/contract.

Also, having a new product to learn will give me first-hand insight into the "new product out of the box" user experience. I have only one shot at using this product for the first time, so I want to notice what's going on in my mind and what information I need.

First, they have a very nice dynamic help pane. Mind you, this is something I usually advise against because the real estate it consumes is very precious, and I argue that UI development will some day take it back or the user will. But there it is on a prestigious product so I'm thinking maybe I'm being a curmudgeon.

I decide to take a 30 minute "tour" (they also have a tutorial, but I traditionally hate those because they make me do a project I don't care about). Tour is working pretty well as they show me what's what, and then very early they do an interesting thing:

They close the dynamic help pane in the tour's example so that they have more room.

Even the Help writers shut down the dynamic Help pane because it takes up too much room! Not only that, but it's one of the first things they teach the user to do.

So it validates my point: Don't put too many eggs in the dynamic help pane basket--it won't be there for long. Have a UA strategy that delivers embedded assistance without the footprint of a dedicated Help pane.

Monday, June 08, 2009

I finished posting my novel Iron Hoop to the Internet over the weekend. It's interesting that a blog turned out to be a fairly OK way to post a novel. Not ideal, but free, accessible, and I know how to do it.

I'm not sure what I expect to get from this. If nothing, else, just a chance to tell a story that amused me in the writing of it (ten years ago). Oh sure, an off-the-wall chance that I can bypass the agents who have shown no interest in it in hopes that a publisher or screen writer finds it and likes it. Or maybe I'll win the lottery.

At any rate, I feel like I've got one more thing on my bucket list checked off.