Anyone who wears several IT hats in an organization knows the phone doesn’t stop ringing some days.
During my time as a database administrator, sometime-helpdesk, Netware apprentice, and general purpose “tech guy,” I expected a few calls a day from just about everybody.
The calls started to get out of hand, though. When you’re sitting down to working out how to make a RDBMS that doesn’t understand SQL at least speak with a SQLish accent, interruptions can be hard on your productivity. So I put up a Web page.
It wasn’t much, but it had a few useful details, like “the database is backed up as of this time” and “if you were waiting for that reindexing so you can start entering this quarter’s data and still see the last’s, it’s done.”
I wrote articles explaining how to accomplish a few small tasks users could print out, along with a few tasklists.
It didn’t set the world afire, but it gave me something to tell people to go read when they had a problem, and enough did that my life got a little easier.
Though Web-based comment boards were nothing new, even then, they preserved an essentially one-way relationship between an information wrangler and the readership.
I could have chosen to don an editor’s cap and taken ‘submissions’ from a few of the more advanced users who wanted to write up assorted tips and tricks they’d learned, but I didn’t want to be an editor, and there weren’t many inexpensive, simple tools for making myself more of a publisher shepherding a whole community of editor/writers.
If all that seems far afield for a database administrator and part-time network gnome, it really was part of the job: sometimes the resident technician is as much an enabler as a fixer, charged with helping her user community solve problems using technology they themselves can’t identify by discrete components, let alone manipulate creatively.
And even if your users don’t want you to think it up for them, they’ll want you to implement it.
So what’s better since my one-way experiment in micropublishing? Several things, actually, two of which are the weblog and the wiki.
Weblogs Make Micropublishing Easy
If you’ve been keeping up over the past few years, you’ve heard about Weblogs: personal journals maintained by, these days, anyone smart enough to do about what it would take to open a My Yahoo! account.
Weblog (or ‘blog) maintainers (lately they’re referred to collectively as “bloggers”) link to and write about whatever’s of interest to them (even if that’s just blogs).
Some are more interesting than others, some are inveterate navel-gazers. What’s interesting about ‘blogs isn’t necessarily the culture surrounding them, but the technology that’s growing up to enable the process of quickly and easily committing thoughts to the Web, offer limited discussion/talkbacks, and syndicate new items to make it easier to keep up without constant checking back.
Weblogs and most software that produces them specialize in “micropublishing” and “microcontent.” They aren’t seeking a mass readership, and they usually they aren’t worried about presenting book- (or manual-) length bodies of text.
They tend to seek a focused audience (or even affinity group) and provide smaller, article-length items, sometimes just links with a few words of comment.
Though in the wild, most weblogs are single-author/editor affairs, some allow multiple editorial accounts with varying levels of access privileges, turning them into collaborative online writers’ colonies.
A few examples of weblog software you can try out for free include Movable Type and Greymatter.
Both can be installed and configured in as little as an hour with minimal tweaking.
Radio Userland is very popular, too, and offers perhaps the most user friendly interface and setup, though if you’re responsible for bringing Weblog technology to your organization, you should be competent enough to set up the others on your own servers.
So what would you do with a weblog? Or more appropriately, what would your users do with it?
For one, it’s an excellent way to allow anyone to publish content on an Intranet Web server quickly.
Most weblog software design acknowledges that not everyone is conversant in HTML, so it’s usually possible to simply type the content without worrying about tags.
The content is almost instantly available via a Web browser, which is another score for simplicity where readers are concerned. Informal documentation, announcements, link-sharing, and limited dialog about any of those are prime territory for weblog software.
Even if your users don’t need the tools weblogging software provides, you can use it to keep them up to date on technical issues in a way I wish I’d had when I was writing static update pages and tossing them up on the local servers. They’ll even be able to talk back.
As an administrator, you’ll probably appreciate weblog software, too. Most of it “just runs” with very little maintenance once installed, taking a minimum of server resources, with an eye toward keeping bandwidth usage down in the default page templates.
The Wiki Way To Collaborate
Though weblogs often allow readers to talk back via discussion areas, they retain a tone, due to their presentation, of a one-way communication to the reader, who can offer a correction but not have an effect on the content to which they’re responding. Another Web-based publishing technology, the wiki, provides an alternative.
Most people, when first confronted with the key concept behind wikis, will probably furrow their brows and wonder whether it’s a particularly wise approach to knowledge sharing.
A wiki’s core concept includes the idea that any document created on a wiki is subject to edit by any other of its users.
Most basic wikis placed out in the open on publicly available Web servers are subject to the contributions (good and bad) of casual passers by, and they provide a very simple, almost markup-free way to do so, which means contributors don’t have to use HTML to create documents for posting on a wiki.
The Portland Pattern Repository is probably the best-known wiki, and one of the more simple examples available, and it offers a large collection of links to other wiki software packages.
So what do people do with wikis? It depends on the needs of the user community forming around one.
In wiki originator Ward Cunningham’s The Wiki Way, companies as disparate as Motorola and The New York Times are reported to use wikis for everything from workflow management to troubleticketing to collaborative documentation projects.
Some wikis are formed around communities of software users, and others concern themselves with creating an entire encyclopedia.
Maintaining a wiki for your users doesn’t mean you have to risk a careless user (or vandal) ruining things by editing the content into oblivion.
Many of the more sophisticated and complex wiki packages allow for incremental backups, user logins, and page locking to ensure the safety (or at least retrievability) of the content.
What About “Enterprise Solutions”?
Wikis and weblogs both suffer and gain from something in common: the ease with which they open publishing to everyone with a browser.
That ease can create a level of informality and horizontal communication that will seem alien to organizations that crave vertical relationships and formal voices.
Weblog software will tend to be less of an issue because it’s more easily account- or identity-driven than much basic wiki software, though even wikis can tag who made a change to a file by username or IP address.
Microsoft has also shown signs of understanding the attraction and power of more direct collaborative tools than e-mail attachments and the software-specific features of individual commenting/markup that packages like Word provide.
Its own “portal server,” Sharepoint, provides a number of ways to provide collaboration and group communication.
In the midst of Microsoft’s current Tablet PC push, Sharepoint is getting attention as a natural for digital-ink-driven technology because of the potential to share and mark up documents in a way that might feel more natural to many users than mouse and keyboard.
Sharepoint is manageable through a Web browser, aimed directly at Intranets, and stresses ease of input on top of a subtle shift in terms of file sharing that moves documents away from their traditional resting place of “network shares” and into collaborative libraries, where they’re easily retrieved, marked up, and saved back in a more metaphorically comfortable manner.
Sharepoint Team Services are available as part of Microsoft’s FrontPage 2002, or as part of the Office XP Developer Suite, so it may be you already own a copy of the basic publishing software.
It’s something to consider for smaller workgroups. The Sharepoint brand finds its fullest expression in the Sharepoint Portal Server, which provides more sophisticated versioning, collaboration, and publishing tools and runs into steeper costs ($3,999 for the server, $72 per each device that accesses it).
Just Do It
Whatever style best works for the users you have to support, each of the approaches I outlined places an emphasis on something many users and admins will welcome: speed and relative agility over complex and over-formalized processes.
Rather than fretting about perfect design, or requiring you to pull in a Web development team to get a basic service running, they stress “canned” designs that work out of the box and they deemphasize the process behind publishing information.
In other words, you don’t have to turn your users into technicians to use what you’re providing. Next time you’re tasked with helping them all collaborate, keep that in mind.