The Robservatory

Robservations on everything…

 

Why isn’t macosxhints.com a wiki?

A couple mornings back, while browsing my collection of feeds in NetNewsWire, I came across this entry about macosxhints.com in Chris Clark’s excellent blog, decaffeinated. Chris writes:

MacOSXHints is a community-driven site operated by Mac Publishing LLC (of Macworld and Playlist renown) whose sole purpose is to collect and archive–wait for it–hints pertaining to Mac OS X…little tidbits you probably won’t find in the help files or product pages.

… … …

What we have is a thriving community site that houses a great number of hints, some percentage of them broken or redundant, most of which could be improved upon (and are, if you bother to read the comments) with the aid of a few dozen eyes.

This isn’t what blogs are for. This is what wikis are for.

So why isn’t MacOSXHints a wiki?

An interesting question to read, especially just after waking up. And it would have been interesting to reply in a comment on Chris’ site, but…it seems there’s no ability to do so. (Perhaps I should post a story about why decaffeinated should really be a blog that takes comments? :) ). So I’m posting my reply here, in case anyone’s interested in the answer to the question.

The question about macosxhints.com is a valid one, and one that’s potentially even more interesting when asked at a higher level…

Important note: The following thoughts are my opinions (and historical knowledge) only. They are in no way associated with any official MacPublishing, LLC company policies or plans. Anything I write about what I’d like to see on macosxhints.com is just that–what I’d personally like to see happen to the site going forward. They are not statements of official plans by MacPublishing for the macosxhints.com site (but we are discussing many of these same things internally).

The more general version of the question is this:

  Why isn’t [any given Mac-related community site] a wiki?

If you think about it, Chris’ argument about macosxhints can be applied to basically any site that (a) takes information from the public, (b) edits (and sometimes tests) that information, (c) publishes that information, and (d) accepts comments on that information. As such, why isn’t MacFixIt a wiki? Or Macintouch, with its voluminous Reader Reports? Or MacUpdate, wherein readers could probably update the database more quickly than some authors seem capable of doing? Or even Macworld’s own Mac911 page–why not let readers directly modify the answers provided there? MacRumors and any site choose to be a wiki, instead of a blog or news site or whatever format they did choose?

Before I get to my thoughts on that general question, I’ll discuss macosxhints.com a little bit.

Why isn’t macosxhints a wiki?

There are a number of reasons why macosxhints.com is not a wiki (and I disagree that it’s a “blog,” as it’s really not a site of my personal thoughts and opinions; it’s a community-driven tips site). So here’s why macosxhints isn’t currently, and probably never will be, in a pure wiki format. Note that this doesn’t mean there aren’t “wiki like” features that could be added to the site, and I’ll touch on those at the end of this article.

  • When I launched the site in the fall of 2000, I knew little about wikis, and at that time, they weren’t nearly as feature complete as were the content management systems (CMS) that I was looking at. Basically, the CMS option seemed to offer the best set of features, and I was able to install and test various CMS, even with my limited technical skills.
  • I launched the site to share the knowledge I’d collected about OS X. I also hoped the site would become a repository of knowledge from others, but it clearly wasn’t that in the beginning. Over the first 12 months, I personally wrote about 50% of the tips that were published–and in the early months, it was more like 95%. It took over two weeks before we even ran a hint from anyone else. Given that I was publishing information I had, and had personally used quite often (hence no apparent need for revisions), a CMS made sense.
  • I also launched macosxhints as a hobby, to improve my technical knowledge, and to give me an excuse to use the Mac more often (this was before we had children!). If the site were a wiki, my involvement would be reduced–why bother to login and edit anything, knowing the community would do all the work? Just make the queued stories public, let everyone pick and choose which to publish, and then watch things change (ala digg.com). While aspects of this are appealing from a time management perspective, it would have made me more of an observer rather than a doer.
  • As time passed, the concept of moving from Geeklog to anything else became much more complex. With thousands of hints, tens of thousands of threaded comments, and 65,000+ user accounts, migrating hints to any other system will be a major task, to say the least. And without the existing database of knowledge, there’s not really any point to starting anew–it’s the collected knowledge in macosxhints that makes the site so useful. I suppose we could just launch “generation 2” on some new platform, and leave “generation 1” in its current form, useful only for searching. However, that doesn’t strike me as elegant, and it means I’d have to search two spots to make sure I was finding the answer to a question I might have.
  • There are some aspects of macosxhints’ content that are not really suitable for community-style wiki editing. Imagine someone editing a shell script with some well-disguised code that deletes the user’s home directory. Or worse, with code that asks for the user’s admin password (“to install, please authenticate”), and then sends that data along with the machine’s IP address and the user’s name to a data collection site. Sure, this would be caught and fixed by the community–at some point. But how many people would be hurt before that happened? I wouldn’t want to have published code snippets changed without some form of review, prior to their publication.
  • Inconsistency in editorial tone is a concern with a wiki. When you have an infinite number of possible editors, there are going to be great variations in both writing style and language skills. For some, English isn’t their native language, and unless they’re fluent in English, their edits will read differently than others. Then there’s the whole question of writing style–many hints might wind up in Leet, for instance. Maintaining consistency of style and language requires some sort of editorial input that cannot be overridden by the community at large.

Those are most of the reasons why macosxhints isn’t a wiki…but there’s another biggie, and since it’s related to the other question I asked, I’ll address it there.

Why aren’t other sites wiki based?

You’d probably get a similar list of reasons as provided above from other sites’ founders. But I think the most common rationale against using a wiki, which also applies to macosxhints.com, is this:

  If your site is wiki-based, you’re basically ceding editorial control to the community.

In some places, that makes sense. The OnMac.net project, for instance, uses a wiki for people to share information about the various “Windows on Mac” solutions. The result is a site that’s updated often with information directly from the community, which helps the site keep pace with a rapidly changing technology. However, it also means that the site’s operators never know what exactly might be on the site. And while that works for OnMac, I don’t think it would work for Macintouch, MacFixIt, or any other site that has “scheduled” updates and relies on advertising revenue to sustain its operations.

On those sites (including macosxhints), there’s typically a daily update, and the content of the page is known and controlled by the editors. This insures that the information that’s published is, to the best of their knowledge, accurate, non-defaming, non-offensive, and (hopefully) mostly grammatically correct. In turn, this means that advertisers can rely on the content of the site they’ve chosen to advertise with.

With a full-on wiki, while editors could choose which articles to run, they couldn’t be certain of the content of those articles, unless someone was watching the site constantly. That’s a tough position to be in, as it would take just one rogue edit by a member of the community to cause lots of problems. Consider my code example from above, or even simpler, if every hint was replaced with a political, racial, or religious attack. Or links to porn or gambling sites. Or consider an irked viewer who dislikes something about a given advertiser, and decides to replace every hint’s content with slams against said advertiser.

And yes, the community would ‘fix’ these problem edits–in due time. But they may remain in their edited state for quite a while before repairs were affected. That’s not really an acceptable situation for most site operators. So is there a happy medium, something between totally free wiki and editorially-controlled content?

Best of both worlds?

There are aspects of the wiki format that I really like. Increased community involvement and increased site content (more hints, more often) would be two things I’d expect to see from a wiki-based site. But by far the most powerful benefit would be having the original hints remain “live” over time, constantly updated to reflect bug fixes, new information, better methods, and system updates.

There are other community involvement features I’d love to see that don’t necessarily come from switching to a wiki. For instance, I’d love the community to be able to rate the hints on a “bad to excellent” scale, making it easier for visitors to focus on the “excellent” hints. I’d also like to come up with some sort of community-based method of rating the complexity of a hint. I’d even like the community to be able to help categorize hints into more than one category, and perhaps to even help create and maintain a keyword-type system to make hints easier to find. Finally, there should be some way for the community to help test hints on different versions of the OS (and to note that a given hint works on a given system), or to mark a hint as simply incorrect or no longer viable.

So I think an ideal format for macosxhints going forward would be something that melded the current editorially-controlled content with a higher level of involvement from the community. In my mind, the process would work something like this:

  1. Hints are submitted by the community (and myself or other editors) as always.
  2. A group of ‘associate editors’ reviews the submissions. They delete spammy submissions (more than you’d think, even though the site is moderated), check for duplicates, and then “take ownership” of hints they feel are worthy of publication. Associate editors are responsible for testing hints, verifying facts such as URLs, and correcting grammar and style to match the site’s standards. These associate editors would be chosen from the pool of macosxhints’ tip submitters, based on the quality of their prior submissions.
  3. Once a hint was edited, the hint would then be submitted for final approval to the ‘senior editors’ (presently yours truly, but ideally, there’s more than one of these, to allow coverage throughout the global day). The senior editor takes one final look at the hint, and then publishes it to the site.
  4. Once published, comments can be added to the hint, just as always.
  5. Through the use of an “Update Hint” button (or somesuch), any reader can tag any comment as one that should be used to update the original hint. Once tagged, the comment would be sent to the associate editor who edited the hint originally. It would also be copied to a set of ‘junior editors,’ which is a large pool of people who have expressed an interest in helping keep the hints current.
  6. Any junior editor who wishes to can then edit the original hint, to incorporate the flagged comment’s modifications. The comment which was flagged is then marked somehow (“This info has been incorporated into the main hint”), and the Update Hint button for that comment is disabled. The associate editor receives a copy of the edited hint, just to make sure everything looks correct (but the junior editor’s edits are active as soon as they’re made).

I think the above plan would allow the community to really get involved and take ownership of the existing hints on the site, while still retaining some element of consistency through the editorial process.

Note that the job titles above are completely made up; I just wanted to use something that established some clear differences in each of the positions. I would envision the ‘junior editor’ group as being quite large–hundreds, if not thousands, of people who simply wish to help keep the hints database current. In this way, the junior editors would be much like anyone who contributes to help keep wikipedia current and correct.

The associate editors are a much smaller group, as they’re really only directly responsible for the daily hint postings. I would like that group to “span the globe,” though, so that hints could appear throughout the 24 hour day.

As I stated up front, these are my thoughts on where we go from here with macosxhints.com. But we have discussed many of these things internally (more community involvement, hint ranking, keeping historical hints current, etc.), and we’re starting to take some steps in these directions. My goal, as always, is to make sure macosxhints.com remains the best source of OS X tips and tricks on the net. Getting the community even more involved seems like a great way to do that, and it’s definitely the direction we’re trying to go.

4 Comments

Add a Comment
  1. Wow! Sounds really cool to me. I’ve been reading MacOSXHints since the 10.0 days, which is before I even had a Mac (it was one of the things that made me switch!). I can definitely understand the historical reason for MSH not being a wiki. I remember how hard it was just to switch to GeekLog, and in those days, there was no such thing as Wikipedia, so few people understood the concept of a wiki.

    That said, I think your proposed changes would make the site even better. Here’s hoping something like that will happen in the years ahead. Good work so far, and thanks for all the tips!

  2. Backwards compatibility. Legacy prevents change. When you have years of archived material, and an existing way of folding the new discussion in, based on whatever your server allowed way back when, your method has, to some extent, already been written in stone. This affects everything from the data itself to the editorial workflow, the daily grind and habits needed to pull it together.

    Can anyone name any successful updates, from old school, to Web 2.0+, CSS, or wiki?

  3. To CSS? Um, any site available before 1998 and available now.

    To the other stuff, yeah, that’s hard.

  4. Pingback: payday loans

Leave a Reply

The Robservatory © 2018 • Privacy Policy Built from the Frontier theme