Subscribe to RSS
Posts Tagged ‘editor’
STC Intercom - Editorial Calendar progress
Thanks everyone for the great comments and feedback on our starting list of theme and article ideas for STC Intercom’s 2009 editorial calendar. I appreciate that comments are still coming in, from all around the globe. I’m enjoying the international and generational communication we’re seeing, so thanks very much!
We posted ideas and requested feedback on blogs, the STC forum, and tapped Ed Rutowski’s experience and knowledge as well as hearing results from survey data he has gathered over the years. All venues have resulted in view points and reflections that are helping us on our journey to assemble an editorial calendar for next year’s ten issues.
In the weeks since I posted that entry, the advisory panel has met twice. In between the two meetings, we performed what is called a card sort using the web application at websort.net. I thought I’d share our process with you, since I found it fascinating, but also because the card sort was extremely helpful so that we could narrow down and focus the ideas from 50+ to just 10.
Websort is a Web-based card sorting tool, and the site’s intent is to help web designers improve the organization of their site. Panelist Rhonda Bracey had used it previously and thought it would be a good match for our needs. Great thinking, Rhonda!
To create our study, I used a list of keywords created from our brainstorming and invitations to the larger community to give their feedback. I had stored the keywords in a Google Spreadsheet, with one column for the keywords, and a second column for a more detailed description of what the originator meant by that idea or concept. I was able to copy and paste the keywords into the sorting tool, and then create tooltips for participants to see the longer description when they hoovered their mouse over the keyword.
Next, I sent the invitation to participate to the editorial advisory panel using the WebSort tool and the list of email addresses. Whenever a participant completed the study, I could use an RSS feed to be notified. It took me about 45 minutes to complete the study myself.
Once everyone had done the sort, I could view the results and analyze them in different ways. One analysis is called a tree view, which I sent to everyone in a PDF file that you can download. The groupings are bunched as if in a tournament bracket, with groups colored red or blue, and it offers a visual representation of how the participants grouped things in common, although the names of their groupings do not appear. You download the tree words list separately.
You can download a spreadsheet analysis tool after the study is complete, and then download and an Excel macro that takes the tree words list and compares it with each participant’s list and groupings. It produces a set of frequency tables for each item, containing a list of the groups in which that item was placed across all the participants.
Before our second meeting, I sent out the tree view PDF file and the spreadsheet with the macro run on the data. During our meeting, we then discussed the results and analysis and seven topics were clearly indicated. Our job then was to ensure that we had three theme-worthy categories and also to make sure that no topic slipped through the cracks or was ignored completely.
We discussed the difficulty in choosing a theme that will have the right content so that any issue of STC Intercom has something relevant to nearly all members, despite knowing that technical communication contains a diverse set of jobs, tool sets, and career paths. Our hope is to produce a set of themes that are relevant and that we’re realistic about recruiting writers for the articles.
We’re still working on the final list and I’ll be sure to share it. STC Intercom’s editor, Ed Rutkowski, is leaving at the end of the month, and we’ll have our list ready for the new editor. Ed has served the Society for eight years and we’ll miss him. He has been great to work with - so best wishes to Ed at his new magazine editor position! If you know a qualified applicant, and STC members are encouraged to apply, review the job description and follow the instructions in the announcement linked from the STC home page.
What if users wrote the manuals?
Inner gang? Mini empires? Am I talking about the online encyclopedia, Wikipedia? Why yes, yes I am. I’m reading “Who Writes Wikipedia” which is a study on how Wikipedia is edited and maintained. Is it really “a small group of colleagues working together toward a common goal?” A small group wrote that much content in about four years?
I’m interested in this subject because Wikipedia is a wonderful reference site full of content that usually is accurate and rings of authority even though it is maintained with an all-volunteer content creation and editing team. Seeing it and liking the results, I wonder how a wiki could be used in a similar fashion to build technical documentation sites that are user-built and maintained while offering the best, most thorough, most accurate technical information about a certain product or technical subject. Could we really get as valuable a reference for product doc by having a “small group of colleagues working together towards a common goal” — a goal of an excellent set of product documentation online?
Outsiders provide content, insiders clean it up
Come to find out, according to the article, over half of the edits are done by less than 1% of the users, about 500 people are considered to be the inner circle of editors, building consistency in wording and categories while fixing typos and editing content where needed to build more quality into each entry. The most active group of about 1400 people have done nearly three-quarters of all the edits. These statistics and claims are made by Jimbo Wales, the face of Wikipedia. Now, the article’s author, Aaron Swartz, tracks a few more nuances of this claim by studying random wikipedia entries, such as the one for Alan Alda. And here is his conclusion based on his study:
When you put it all together, the story become clear: an outsider makes one edit to add a chunk of information, then insiders make several edits tweaking and reformatting it. In addition, insiders rack up thousands of edits doing things like changing the name of a category across the entire site — the kind of thing only insiders deeply care about. As a result, insiders account for the vast majority of the edits. But it’s the outsiders who provide nearly all of the content.
Wiki for tech doc
Now, I’d like to try to translate this to what might work well for a wiki geared toward product documentation. You’d need a core set of very knowledgeable content providers, like a team of experienced users of the product. Those users would contribute a core body of knowledge to the wiki, and hopefully choose to first document the items that are either most popular tasks or the most-referenced information or the toughest concepts to grasp. Most likely that would be the subject matter they’d be most familiar with anyway.
But is there vandalism?
It also appears that my wiki graffiti concerns are likely unfounded… the article says, “A tiny handful — probably around 5 out of nearly 400 — were “vandalism”: confused or malicious people adding things that simply didn’t fit, followed by someone undoing their change. That’s such a small percentage, just over a tenth of a percent, that it seems for the most part there are few writers with malicious intent in their edits.
Real wiki writers tell their experiences
Reading through the comments, I also appreciated the “user experiences” from people who are actively editing Wikipedia content. One commenter notes that he “went crazy” adding content in areas where he had knowledge but found that once his knowledge limitations were surpassed or the well was dry, he went into a maintenance mode. With a “burst of new knowledge” he’d add more content to those areas but found those to be few and far between. I think that with product documentation a similar ebb and flow would occur — knowledge or experience with a relatively new feature would cause activity on certain articles but then maintenance would occur again.
How do you get enough contributors?
Probably the major limiter for a product documentation wiki that’s maintained by users is that the user base would have to be significantly large in order to draw enough content providers. If 500 people maintain Wikipedia, you’d probably need 50,000 users to get 500 committed people to provide content (or would you actually need half a million?).
How do you ensure consistency?
Wikipedia has a basic information model to follow that most people are familiar with, also — the encyclopedia and it’s article-like writing style and the content you expect to see in an encyclopedia is well known and the style is easily copied by any writer. Product reference would need some excellent modeling to follow, which is why I lurve the idea of a DITA wiki — structured content models that 500 people could follow consistently, writing concept topics, tasks, or reference topics on a regular basis.
I’m warming up to the wiki
We can learn a lot from Wikipedia’s success and I plan to continue to track their progress as it evolves and more policy is put in place. Perhaps the wiki has potential as a great product doc format.
What do you think as a writer? Would you be willing to write and maintain content for product doc in a wiki? What do you think as a product user? Would you want to read and would you trust the content provided by thousands of fellow product users? Maybe I should experiment by combining the two groups — user and writer — and start a FrameMaker wiki. Surely the FrameMaker user base just isn’t large enough to generate the content it would need to succeed. What do you think?
