Journals by RSS
Journals by EmailWe held our team offsite event today, and one of the items on our agenda was lessons learned from the STC conference in June. I talked about some of the sessions I attended, one of them being the “What Is Structured Authoring?” panel with Neil Perlin and Sarah O’Keefe. They spent the entire session talking about what their definitions of the term “structured authoring” and how it benefits the writer, and never was the word “user” uttered until I asked them whether structured authoring—whatever its definition—held any benefit for the user.
Neil replied that structured authoring lends itself to having consistent content organization, which is easier for the user to navigate. This was the answer that I pretty much expected, but I wanted someone in the panel to talk about users. User experience should be central to technical communicators’ thinking.
As we were discussing this in our team today, I thought up and drew a little diagram on the whiteboard that I call the Experience Spectrum:
Whatever definition of “structured authoring” we choose, we can go to one extreme and, while being consistent within a team or organization, create a totally new experience. Users could, over time, learn to expect the experience we created. Or we could go to the opposite extreme and choose a structure or scheme of presenting information that is based as much as possible on user research. We just find out what users want and give it to them.
With this being a spectrum, there are varying degrees and mixes of both approaches.
I rarely advocate the extreme of anything, so I think the best practice lies somewhere in the middle. We definitely need some user research so we know what they are accustomed to and like, and then we can create an experience that doesn’t frustrate users out of the gate. At the same time, as professionals, we know some tricks of the trade and some of our engineering of the experience should be based on our expertise. I’m simply asking here that we let the users have some input on the interaction they’re going to have with our content.
Related entries (auto-generated):
Consider Users’ Environment as Part of User Experience
Fight User Frustration: Give Users What They Expect
Taking a More User-Led Approach to Learning
4 Comments to 'Writer-Dictated vs. User-Dictated Experience'
July 23, 2008
Hello,
I ran across your entry and wanted to toss in a few points for consideration…
1. The goal of the panel was precisely to discuss the definition of structured authoring from the writer’s perspective, which is why there was so little mention of the user.
It would be interesting to have a panel that consisted of a representative sample of users to see what they had in mind. About five years ago, I proposed that the STC hold a parallel online doc competition with a panel of users who’d review the same entries as real STC judges to see how their perspectives differed. Nothing ever came of the idea, but I still think it would be interesting.
2. Don’t forget Alan Houser in the list of panelists. He discussed structured authoring from the pure DITA perspective, Sarah from the structured Frame perspective, and me from the templates-without-DITA-or-Frame perspective.
3. I maintain that THE primary benefit of consistently structured material is easier comprehension and navigation. But I will add another user-related benefit. If you’re going to some Web 2.0 model that will call for user-generated content, structure will make it easier for users to submit material in a form that’s both easy for them to use and easy for the tech writers to work into the larger information model.
Thoughts?
Cheers,
Neil
[Reply]
July 23, 2008
Neil, I appreciate your comments. I apologize for not including Alan Houser; I couldn’t remember his name, and I also couldn’t find a list of the conference sessions that had the names of the presenters or panelists, so I went with the ones I remembered—you and Sarah.I don’t know if the panel’s focus on the writer’s side of structured authoring was stated outright, and if it was, I missed it—in which case, the mistake is mine. I like your idea of having a user panel review the contest entries. What’s the reasoning behind your idea not panning out?Good point about providing a structure in a Web 2.0 environment. One source of resistance to wikis for documentation, and I’ll admit this applies to me, is that it would be hard to enforce order. I suppose a wiki page could have text boxes for elements like title, introduction, instructions, warnings or cautions, and so forth, then behind the scenes, tags could be applied to the content of the text boxes. I have contributed to our organization’s helpdesk knowledgebase, and its interface for writing articles contains text boxes much like I’ve described, though I doubt specific tags are applied to the content other than HTML tags for rendering in a browser.
[Reply]
July 24, 2008
Hi Ben,
Here’s the session description from the STC web site:
“Structured authoring can improve authors’ productivity, facilitate single-source and multi-channel publishing, decrease localization costs, and increase opportunities for content re-use. But what exactly is structured authoring? Three experts in structured authoring, XML publishing, and DITA will debate its meaning, and will discuss the benefits and pitfalls of a range of approaches to structured authoring.”
I agree that the user-perspective probably *should* be part of such a presentation, but that simply wasn’t the case here.
I don’t know why my user review panel idea didn’t pan out. It may be that I didn’t push it enough or it may be that the organizers just didn’t think it was that good an idea. And I never followed up on it.
We agree about the difficulty of enforcing consistency in wiki submissions from end-users. My experience is that it’s hard enough to get tech communicaters – e.g. professionals – to be consistent, let alone the non-professionals.
Cheers,
Neil
[Reply]
Trackbacks
Set Me Straight. Leave a Comment.