Monthly Archives: October 2007


What are wikislices? How can I try wikislicing?

I’ve had a very serendipitous journey lately based on my podcast on TechWriterVoices and the work on the One Laptop Per Child project that I want to share. Through others listening to the podcast, hearing about OLPC, and contacting me via my blog, I learned about wikislices, and it just might be a method for DITA and wiki to play in the same sandbox.

This concept seems very apropos to the shift we’re seeing in technical publications away from books. What’s interesting is that there seems to be two directions you can go from books – wikis or DITA, crowdsourcing or singlesourcing. Some times it seems like choosing between wikis and DITA is like new school/kewl kidz versus old school/squares.

But what if there’s a way to have your wiki be the single source (also crowd sourced but with a strong guiding hand, let’s say), but to create cross-sections or wikislices of that content? This idea would essentially allow writers to write in the wiki and then either the writer or an architect would “slice” it.

There is a way to Wikislice Wikipedia already. Go to and enter a subject. You can view this nice slideshow showing the basic features of a wikislice. You can even make offline wikislices available.

There are selected wikislices created already for the One Laptop Per Child project, such as the Great Wall of China, Space exploration, and the Brothers Grimm.

What’s interesting to note is that the Webaroo wikislice of “violin” is different from the one for the OLPC wikislice of “violin” and it appears that the OLPC one is more easily read by a student. Somehow the slices are customized, perhaps for the audience? I’d like to dig deeper into the guts of a wikislice. All I’ve found so far is that they’re built using regular expressions according to the Wikislices definition on the OLPC Wiki.

With the correct use of tagging in your wiki, I would imagine that you could slice the wiki based on audience, language, or content type, such as grouping tasks, reference, or concepts.

It seems like any wiki could be wikisliced, and if DITA maps are the method for the slicing, then you can get a table of contents and PDF output based on a cross-section of your wiki – a wikislice. This process is just a thought piece right now, but my hope is that working on the OLPC project helps perfect the wikislicing process so that it could be used for other end-user documentation projects.


Podcast about wikis with Tom Johnson at

Everyone, please give the site a look or two or three or more. It’s such a great site. I’m not just saying that because I have a podcast there now, Answering Tough Questions about Wikis – Anne Gentle, but because I do want to tell everyone what a great interviewer Tom Johnson is.headphones

Tom sent ten excellent questions ahead of time via email and I spent some time answering them by writing out some notes. I’ve sharpened them up for those of you who, like me, don’t really have the auditory learning style that listening to podcasts serves best. I always want to be able to scan my media and pluck out the pertinent tidbits, and few podcasts have that feature. (Side note: with QuickTime movies you can make chapters which allows you to scan the chapter titles for the content you’re most interested in.)

So, here’s the interview in text form, but not a complete transcript. We skipped around, Tom edited around the audio difficulties, and sometimes I just answered the question differently.

1. How we can manage and re-use content when it’s wrapped up in mediums like wikis? Can you single source topics? Can you export the content to Word? Or is it locked in its own format?
Nice lead in. This is the ultimate question that many people are asking me and I am having lots of conversations via email and lunches, trying to come up with ideas.

Wiki engines are becoming more and more powerful and CMS-like. has 95 wiki engines listed as of this week. Yes there are still very simple wikis but there are also people making wikis run really powerful websites with amazing wiki extras – like threaded comments, conflict resolution, and so on.

But about single sourcing and wikis…

One idea is that you export your source to a wiki, and then when any changes come in, have to have a human cull through all the edits and figure out what should go into your souce files the next version of the wiki should be, like book publishing. This method is similar to going through support forums or support call logs to see what you’ll include in the next version of your book. Lots of work and thinking.

Another idea for single sourcing a wiki is that the wiki files themselves are the source – if we could invent a DITA wiki where a webform is used to edit DITA topics then we’re there. The wiki platform would also become a publishing engine. Also Confluence appears to work on this idea, that the wiki files are the source and you can publish out to PDF.

Paul Kandel at Intel has this idea that you’d have an offline wiki, with synchronizations every once in a while (you’d set the time parameters). He’s talking about the Dojo Offline Toolkit (, which is based on Google Gears ( ), could provide an outstanding solution to the issue of generating offline doc formats. You could enable the wiki itself to be viewed offline, and user additions could automatically synchronize with the online version. I’m not sure I fully understand the advantages and disadvantages here, but the source could be “frozen” in time every once in a while.
Another idea is to be very selective in what you put in a wiki, and make the wiki the source for that selective info only.

Many wiki platforms have import and export capability. However, as my co-worker Mary said on the Author-it users Yahoo group, try not to have your precious content be downstream, meaning, if someone asks you to export all your Author-it topics to Word so that they can be imported into Wikimedia, try to find a way to have the content go the other way around (export Wikimedia content and then import it into Author-it).

I’m also working on the One Laptop Per Child project which is an education project to provide opportunities for children to explore and express themselves. It’s a neat project where we would really like to figure out how to go from wiki content to Author-it and then use Idiom for translation… but it’s probably a “copy from the OLPC Wiki and paste into Author-it” method because the content is not written for the audience we have in mind. The docs for the kids are translated into at least seven languages. It’s an interesting project to be on, and I’m learning so much as I go.

2. You found that with Wikipedia, fewer than 1 percent of users contribute more than half the edits. Should technical writers expect the same 1 percent user contribution effort with the wikis they create?
I just read on that even the MSDN wiki has 5 top contributors. Of the 1876 contributors, 5 contributors (three from Microsoft) made about 1500 of the edits (out of 5800 edits).  I believe you should expect a similar contribution effort as long as those numbers continue to be displayed in other wikis. I suppose the key is recruiting and maintaining relationships with those users. And really, you probably want just a few core inner circle type of people so that you can maintain positive relationships. It’s like an active listserv – you can probably count on one or two hands who the inner circle of contributors are. Those are your experts who are also helpful and giving.

3. If it’s only 1 percent, and your audience is 500 users, that’s only 5 people making edits. Is the wiki even worth it then?

It’s certainly worth it to the 5 contributors who are motivated for whatever reason. And the audience size is difficult to speak to the value – if your manuals had an audience of only 5 people, would you write them anyway? In some cases, yes, because many products need the manual for quality purposes – it’s just an expectation of a software or consumer product. For some products, a wiki is an expectation (probably as an extension of highly visible/visited forums).

I write more about motivations for contributing to wikis in this article on The Content Wrangler. (Think of Reciprocity, Reputation, Efficiency, Attachment to a group).

4. What type of information is a wiki best suited for? Reference? Troubleshooting? Living documents? Why?

I believe that there are several reasons to use a wiki for certain types of information. For Reference information, a wiki is searchable and allows for easy upload of large log files (although if the reference info is in tables, well, I’m not sure how each wiki engine would handle table formatting). Troubleshooting info in a wiki follows the “better than a support forum” model for wiki building. A document that changes often or should change often might be suited for a wiki. Internally, developers can use wikis to explain why the software was designed the way it was, what gotchas in the code to be aware of. Wikis are quick methods for team meeting note-taking and that sort of thing, which would be reference info. So I guess the type of information is the type that people want fast and want to collaborate on.

One person on Gordon McLean’s website onemanwrites said that a wiki plus a Google search appliance is a really good thing. I found that to be the case at BMC for the internal wikis and searching, the combo was killer for finding info or for finding collaborators quickly. That commentor also had the good sense to say “it’s worth watching what goes into it to guard against people setting bad advice in stone.”

5. Is the typical wiki editor robust enough to support all the complicated styling that technical writers do? Can you create your own styles? How hard is it to work with graphics?

Some wiki engines are robust enough… lots of technical writers that I talk to like the Confluence editor’s robustness. I’m not sure if technical writers do much complicated styling really, compared to magazine layouts and glossy brochures. Or if we do need complex styling, the copy is sent to layout.

I’m also not sure how complex tables are in most wiki engines. I think for the most part, you get headings, paragraphs, and lists. Beyond that and levels of those, what else do you need for much technical writing?

Graphics can be a complete bear to get in… apparently one of the Motorola writers had a heckuva time importing the graphics from the user manual into the Mediawiki-based wiki with the time crunch she was up against.

6. Who is actually using a wiki? Have you personally used a wiki successfully for a product?

Many people are using wikis internally. I myself was more interested in wiki use externally for product documentation, and interviewed Emily Kaplan at Motorola and Dee Elling at Borland for information about technical product documentation house in a wiki or wiki-like structure. Harry Miller at Microsoft also interviewed one of the PMs for the MSDN wiki.
Wikis are a favorite quick website set up for many open source-type projects. Also the gaming communities seem to have flocked to wikis either as a replacement or enhancement to customer support or game discussion forums.

I’m using for my current job, and it’s highly effective for making quick web pages for internal or external use. Plus the search engine is useful. It’s a Drupal site but nearly every page has an Edit tab, so it’s wiki-like.

7. Wikis have been around for 10 years. Wouldn’t they take off if they were going to?
I think they have taken off in certain circles, just not yet in ours. I think that with a set of best practices or push from customers or employers, wikis will be in demand, and it’s a matter of positioning your tech pubs department as the overseers of that content. Without a strong guiding hand, a wiki isn’t that useful because people don’t know what to contribute or how to handle revisions and so forth.

8. What if a user makes a change you don’t like? Do you change it back, offending the contributor? Or do you leave it in, offending the other users? How long do you stick around making these decisions?

I think that you almost need to think of the contributor as a team member, and then behave as you would with a colleague writer. If it’s inaccurate, you change it and reason with the person as to why it has changed. If you’re looking to save time, or don’t have the time to arbitrate, then don’t take long to make those decisions, or don’t get involved with that particular change. But don’t expect to build a wiki and have all these contributions come for free or little resource or time investment. That’s just not realistic.

9. How does a wiki build community?

In itself, a wiki can’t build community. There’s a great quote from Wiki for Dummies with a heading entitled something like “don’t go on a wiki suicide mission.” It says “Wikis don’t have magical powers. They cannot create camaraderie where none exists, nor can they streamline an out-of-control operation. They are not powerful information magnets, nor will they make your team better writers, more organized, or more intelligent. In short, without a strong guiding hand, wikis are useless.

Wikis cannot promise instant returns or unbelievable creativity. Wikis allow users to quickly and easily update and upload information.

I enjoyed the heck out of that quote. But, many web workers are finding that a wiki is a place to find other like-minded individuals trying to tackle the same problems and offering similar solutions, much like a customer support forum. So a wiki can help build community by offering information and identity to the contributors.

10. As a technical writer, are you ever done with a wiki project?

I’d say No. Wiki building is a lot more about relationships and connections so you’d never want to sever those ties if there’s still a bond there. Anyone who thinks that starting a wiki will make less work for their techpubs team by crowdsourcing the writing is fooling themselves. But if you want to serve and connect with a certain set of customers, you’ll do what it takes to keep the wiki alive and kicking.


Who else wants to be a technical communicator?

I have been reading many essays and articles lately about “where has technical writing gone” (including a nice reaction countering the manual-less existence Jared Spool perceives) and “woe is technical writing.” Okay, I made the last one up.

But all of this reading and other recent experiences has made me think about the core competency of writing and writing well. Avi commented in a previous post about how our (writers’) business case and value-add is that others don’t want to write or are not as good at it as we are. One conclusion is that we should know our core competency and stick to it.

But does sticking to writing as a core competency work in the age of self-publishing?

Others are asking and answering this question. I found the article “Is the Net Good for Writers?” a though-provoking piece. Especially this quote from Clay Shirky pretending to write in response to whether Herr Gutenberg’s new movable type is good for books and for scribes.
In the same way that water is more vital than diamonds but diamonds are more expensive than water, the new abundance caused by the printing press will destroy many of the old professions tied to writing, even as it puts in place new opportunities as yet only dimly with us.

It’s a long article, containing well-written and dense prose – which is exactly what some of the contributors say the Net doesn’t value. My takeaway is that your goals as a writer will dictate your reaction to the net’s value to writers. Is your goal to be paid, and paid well? Then the net might be watering down the market (supply and demand). If you goal is to make connections, then the net offers opportunity that might never have been available in the day of the printing press’s invention.

I also think of the US-based screenwriter’s guild threatening a strike because they are not getting paid every time someone views a Season 2 DVD of an entire season of shows, or downloads a show on iTunes and watches it on their train commute on their iPod video. The writers didn’t come up with the idea of watching a TV show on a handheld device. Their core competency is writing. And we all know deep down that the best shows are the well-written ones. So how can our profession learn from the screen writers guild? Learn that good, fast, high-quality writing is valuable. Learn that a voice and consistency is important, though subtle.

The Society for Technical Communication recently worked with the US Department of Labor to to update the job description for “technical communicator.” Susan Burton discusses it in her Intercom letter You May Already Be a Technical Communcator! Now I won’t jump into the STC forum discussion about this particular word choice, substituting communicator for writer, but it is part of what I’m trying to parse out for my own professional job description and also describe what I like to do and what I’m good at.

I’m also thinking about minimalism and how to achieve it with writing alone. I am beginning to think that it can’t be achieved with writing alone. You probably need a team including a designer and illustrator to communicate the minimal message, and probably an information architect. As Bill Gearhart says, the Lego documentation is a gold standard of minimalism. But there is so little writing that I wonder where my value add would be in trying to emulate this minimalism? I’m not a designer or illustrator. I need a team to support the writing value that I offer.

I think the title of this post could be “Who else wants to be a designer?” And the answer might be, “technical writers.”


Audience considerations – writing technical doc for kids, parents, and teachers for One Laptop Per Child

I’ve recently (read:last week) learned that there is active recruiting going on for end-user documentation for One Laptop Per Child. The OLPC project, as it is also known as, is Nicholas Negroponte’s education project that hoped to build a US$100 laptop and take it to developing countries. It turns out, the product they plan to ship this fall with the Give 1 Get 1 program at is closer to US$188. For $400 you get to give one laptop and get another laptop. Wow, what a neat project and what an amazing difference it could make in the life of a child.

OLPC class in Nigeria

So far I am reading like crazy to try to understand the project and its audience, especially to understand the language and translation ramifications. So I have plenty to offer in background reading, such as these items:

The OLPC Wiki – OLPCWiki –
Laptop: A learning tool created … –
Vision: Children in the … –
Children: Children actively … –

FAQ for OLPC –

Especially good to read are the core principles: (1) child ownership; (2) low ages; (3) saturation; (4) connection; and (5) free and open source.

Last night I was even able to emulate the Sugar operating system using a great how-to emulate Sugar and the XO article on IBM’s developerworks site.

Unfortunately, after I created my user name, clicked Next, and then clicked the colors to make my “person” blue with a yellow outline, the emulator went into some reboot loop from which I could not escape. Every subsequent attempt to start up the emulator met with an X in the middle of the emulated screen.

To the OLPC Wiki I went, searched for “emulate” and found “Using QEMU on Windows XP,” and “Emulating the XO/Help and Tips” trying to troubleshoot my problem and see if anyone else had a similar situation. Interestingly, I found the “GUI won’t start” problem in the Sugar instructions wiki page. So I am deleting the original disk image I downloaded and trying to unzip it again.

And… that was it! I’m probably going to move that bit of troubleshooting information over to that Help and Tips page. Here’s the screenshot with proof that I can emulate the Sugar environment on my Dell laptop:

XO emulated

I’m very excited to be a part of this effort. If you’re interested in helping out, and don’t mind a chaotic process with references to wiki information that’s not necessarily the final answer to your questions, and want to translate things like “The units will ship with some kind of human-powered charger that plugs into the DC socket.” into child-friendly minimal task-oriented documentation, please email me using the Contact page.


Now you can take the technical writing class but skip the tests

I just discovered the greatest course syllabus for a technical writing class, English 107, at Lehigh Carbon Community College in Schnecksville, PA. Makes me wish I was taking this class.

Course reading list (on a wiki, no less!)

Weeks nine and ten really have me excited. Because I’m a technical writing dork that way. Here’s a copy and paste.


Week Nine: Web 2.0 and Education

  1. Watch Web 2.0
  2. Watch Tim O’Reilly’s Interview about Web 2.0
  3. Watch Web 2.0 and Language Learning by Graham Stanley
  4. Watch EdTrends
  5. Watch Feel Again
  6. Watch Greater IBM and Second Life
  7. Watch IBM Second Life Highlights


  • Educators and businesses are using Web 2.0 and the 3D web to save money. What costs are saved by using 2.0/3D web technology? Write a memo and send it via WebCT.
  • Create a semi-formal report comparing and contrasting the uses of Web 2.0 OR Second Life in Education and Business. Explore the advantages and disadvantages. Your report should have:
    • A Title Page
    • Overview
    • Background
    • Methodology/Criteria for research
    • Research findings
    • Discussion
    • Conclusion
    • Works Cited

Week Ten: Web 2.0 and Technical Communication

  1. Read ” The Quick Web” for Technical Documentation by Anne Gentle
  2. Read Writing Becomes Industrial by Neil Perlin
  3. Read Complete Information Gets Used by Geoffrey JS Hart
  4. Read Top Ten Tips for Writing Online Surveys
  5. Read Managing conflicts within a Team of Writers
  6. Read Open Source for Tech Writing Teams
  7. Read Web 2.0 for Technical Communicators

1. What is the role of the technical writer in business and industry? Send me an email detailing your ideas.
2. Create a web survey using Survey Monkey and ask everyone you know to complete the survey. Find out how they use technical writing in the workplace. Survey at least twenty people.
3. Create an analysis report of the data collected in the surveys and submit via WebCT.
I’ve interviewed two graduate-degree earners, but neither of them would have looked at Web 2.0 in the way this class is headed.

I am setting aside some time to do the reading assignments myself. You may want to also. A highly successful director at BMC used to set aside two hours of reading time a week for articles like these (no emails, just uninterrupted reading time), and it showed in her forward thinking and leadership qualities.

DITA wiki

Are structured authoring and wiki opposing forces?

It was one of those light-bulb-type discussions. Ideas popping and synapses firing. I had lunch with Chris Almond and Don Day this past week, discussing the potential authoring of wiki articles using DITA. We went through possible workflows, from a web-based DITA editor – to authoring in another tool and merely using DITA as an intermediary and transforming to wikitext.

If you know about DITA, you recognize Don Day as the chair of the OASIS DITA Technical Committee. Our lunch companion was Chris Almond, an innovative forward-thinking project manager. From him, I got the sense that internally at IBM, there is a perception of DITA as a technical writer-only tool to have in your toolkit. Chris coordinates and manages the authoring of IBM’s RedBooks, a very popular and technical set of documentation that are not product documentation but rather they show users how to implement a specific set of products, integrated together. He’s coordinating teams to do the scenario-based writing that applies the product in real-world situations. Many techpubs teams are striving towards use cases and scenario writing, and RedBooks are a great model for how to do it well. I know we tried to emulate it at BMC Software, and Bill Gearhart has an article about “Scenarios and Minimalism” in the CIDM Newsletter that discusses scenario and case study authoring.

Chris is trying to figure out how their current writing methodology and processes can be protected but also enhance the tools used and improve the resulting connections after the deliverable is written. Currently they engage with teams of authors to outline scenarios using mindmapping software and then divide up the actual writing assignments according to the author’s experience with the scenario. I immediately thought of JoAnn Hackos’ and Dan Ortega’s suggestions to have field personnel contribute scenarios to a product’s wiki when Chris described their process.

How do you actually empower the teams to write these wiki articles and assemble them into a useful (maybe book-like) wiki? Another question to Chris was, how do you layer an outline or table of contents on to the wiki, and then test and fold in any changes that wiki contributors make?

After at least an hour discussion I’m not sure we ever came up with the correct toolset. Or rather, there was a toolchain that could be used which is certainly do-able but not the ideal that he wanted to get to. I suppose one ideal is a DITA-based wiki with a web editor interface that would change editor strictness based on the author’s permissions. Authors who knew DITA and were most comfortable writing structured tasks, reference, and concept topics would get an XML-validating editor and authors that preferred more free-form would just use a rich-text editor that was nothing more than HTML headings, paragraphs, and lists underneath like what you use in Drupal, WordPress, or Blogger.

Suddenly it became apparent to me (but I won’t and don’t speak for Chris and Don) that some people are more determined to keep the editing quick and easy, but sacrifice that structuring and vetting step that structured authoring gives you.

This realization gives me a sense that there are two camps in technical documentation. There’s the “quick web” folks who connect easily and author easily, and then there’s the “structured quality” camp that requires more thoughtful testing and time spent on task analysis and information architecture. Also, the types of information that these authors are trying to capture are opposed in some senses. Then I thought a diagram might help.

wiki-fast-easy <-----------+-----------> DITA-difficult-tested

high-level scenarios <-----+-----> detailed dialog boxes

With such an easily diagrammed moment, you’d think I’d have an answer for the process we could use for a DITA-based wiki. Unfortunately it’s not quite refined, but I feel a step closer to understanding why this process is difficult to create – because the process is paved with these tradeoffs and apparent compromises and decisions you have to make along the way.


Author-it webinar on version 5.0

Our team is so excited for the new Author-it version 5.0 that we invited other Austin techpubs teams over to our office to watch the US & Canada webinar. It was like a movie premiere. Okay, we’re not really that big of dorks. But we had a good time with it.

By my calculations, it was about four AM Australia time but both the presenters were troopers, even when the typed-in license key didn’t “take” during the migration portion of the demo. All of us in the room empathized with her and she smoothly avoided any delays.

Ribbon bar and organized styles and templatesI’m mostly excited about the new interface. And Australians New Zealanders say “ribbon bar” so sweetly. It’s such a nice update. I’m really looking forward to using it. The organization of styles and templates makes sense as well, and I am glad to have separation between paragraph styles and character styles.

The search bulk-ups contain the features my co-worker was looking for – search within a folder and match case or whole word. Also the search within a topic as a customizable panel pop-out is going to be highly useful. That new editor interface is especially exciting. It reminds me of XMetal’s editing environment.

Author-it publishing profilesWe can’t wait to start trying publishing profiles. We wanted to just start clicking in the dialog boxes displayed during the demo. Their knowledge base says that eleven profiles are shipped right out of the box (mapped directly to publishing outputs). The output types I see in version 4.5 are DITA, Word, PDF, HTML, XHTML, HTML Help, Microsoft Windows Help (RTF-based), Java Help, Oracle Help, XML, and Author-it Website Manager format. Since that list adds up to eleven types, I guess there are no new outputs with this release.

Author-it XtendWhile we don’t currently have a use for Author-it Xtend, I found it fascinating as a concept. Why would a techpubs department pay money to a vendor for an embedded search engine to try to encourage writers to re-use? Why not just spend that money in training (or hiring) writers to think more about topic orientation and re-usability?

My co-worker pointed out that in a translation situation, Xtend might pay for itself in one translation round. It seems so very Google-like. There’s this sliding bar for more Fuzzy matches and more Relevant matches. There’s color coding for matches. I’m automatically drawn to it like a moth to a back porch light, yet I’m not sure of the best applications for the search hits nor what problem teams should expect to solve with this functionality. Perhaps someone can tell me the best scenarios for this add-on?

We copied the Questions and Answers from the webinar, and people asked plenty of questions. Here’s just a sampling – does 5.0 run on SQL Server 2005 (yes), does it run on Windows Vista (yes), questions about the new Project Manager (purchased as a separate module but is integrated into 5.0), is the 5.0 upgrade covered by a maintenance contract (yes), can you upgrade from 4.3 to 5.0? (yes), are presentations part of 5.0 (yes), and the final question was a good comparison: Can I use the Filters (Variables) on the Publishing Profiles as I would have used conditional build tags in RoboHelp to include/exclude content from specific output types? Am I understanding this correctly? The answer: yes, that’s correct.

So, exciting new features abound and we can’t wait to get our hands on them. I’ll keep you posted on our progress.

The “Quick Web” for Technical Documentation

STC Intercom article “The Quick Web for Technical Documentation”

I’m happy to report that my article about using wikis for technical documentation was published last week in the STC Intercom.

A PDF my article is available for anyone to download, STC member or STC non-members alike.

I’ll be giving a presentation about wikis for technical documentnation to the STC Austin community on Tuesday November 6th at the Commons Center, which is located at 10100 Burnet Road, Austin, TX 78758, near the southwest corner of Burnet Road and Braker Lane on the University of Texas J. J. Pickle Research Campus. Map

If you’d like to see what else I’ve written about wikis, take a look at the articles in my wiki category, or check out this list from my blog.

So many people helped me with the Intercom article. Kelly Holcomb is an excellent editor and helped me with it in her small amounts of spare time. Emily Kaplan read an early copy and also helped me sort through my notes. Michael Cote has sent me interesting items about wikis that he has found and also constantly tags useful information in Diane Fleming was investigating wikis on her own, asked me about them, and then gave me great feedback on an early copy of the article. Tom Johnson was extremely positive when he first read it as well. I spoke with Dee Elling who had two excellent experiences to talk about in her interview with me. Harry Miller had a podcast interview with Molly Bostic, the PM on the MSDN wiki team, that was very informative.

It takes a community to write about online communities. Thanks, everyone!

Tag and category cleanup

With the announcement that WordPress now realizes the difference between tags and categories, I’m going through my 34 posts to date and re-tagging them and limiting the categories.

The way I see it with my technical writer lens on, categories are broad general topics and I’m hoping my blog will have about a half dozen categories. Tags, on the other hand, are more like index keywords. So I’m re-reading my posts and trying to define categories very conservatively and carefully, but with tags I’m probably going overboard, approaching it like creating an index on an entire book, using any keyword I can find in the title or the text or the headings and making the keyword a tag.

To avoid being the anti-social taxonomist that I can be sometimes, I will keep an eye on what other people using are using for their tags so I can be like them. Apparently not a lot of folks use “techpubs” for their tagging so I’ll probably start using “technical-writing” instead. Another case-in-point of my tendency to use odd keywords for tags – while Michael Cote uses “thekids” in to bookmark links pertinent to what the Net Generation is doing, I would probably chose to tag mine “tehkidz” because I’m a dork that way. 🙂

Twenty-two more posts to go.