Accessibility
 
Home / Developer Center /  

JD's Forum

John Dowdell

John Dowdell

John Dowdell joined Macromedia in 1993 and listens to people in the online communities. He likes to make complex things simpler, and keeps a daily weblog of related news.

View Previous Columns

 
New collaborative publishing techniques

This week the front page of DevNet reports on DevCon 2002, by pointing to weblogs from various writers.

Blogs get hyped a lot these days, but they're only one in a range of new fast publishing techniques. Here's an overview.

A weblog, or blog, is usually a reverse-chronological collection of short articles. It can be authored by a single individual or by a select group. It is written in the browser, in an HTML form, which is then submitted to the server for storage. When a page is requested, the current collection of articles is merged with a template and delivered. After a few days older articles are collected into archives.

An advantage in creating a blog over other publishing methods is that it is very fast to add content... many blogging systems use bookmarklets to call up a new small window prefilled with info and links from the page being viewed, for instance. You can archive information as you find it.

An advantage in reading a blog is that you get very fresh information about what a particular writer finds important. Once you become familiar with a writer it becomes easier to evaluate whether a link they find useful will also be useful for you. Blogs are usually link-heavy, so that you can trace their reactions back to source material.

The disadvantages in creating a blog include material being sorted chronologically rather than categorically, and the difficulty in collaborating with others. Some blogging systems are adding keywords for categorized retrieval, but this is not widespread yet. Although a group can create a single blog, and although blogs can link to other blogs, a single blog is not usually considered a full collaboration method.

The disadvantages in reading a blog include the lack of considered writing and the duplication of links among several blogs. Readers also have to pay a big upfront cost in discovering and evaluating useful writers.

Key blog concept: If you find a writer whose judgment you can use, then you can reap what they find important each day. Finding a half-dozen such writers is like having your own custom, trusted news team. Word-of-mouth is an efficient way to navigate new items, and evaluate whether they're useful to you.

Indirect blog concept: Fact-checking. Because any author can publish to the world quickly, errors are quickly challenged. This is easiest to see in the blogs about political news, such as InstaPundit, where stories from mainstream news feeds are regularly checked against reality. The tradeoff for such fact-checking is that you need to do more reading, because text, once added, is rarely removed.

Blogs are undergoing a rapid evolution in related technology:

  • Indices like Blogdex and Daypop regularly trawl through a wide range of blogs to discover the most frequently-linked addresses of the day. Just as Google presents the most important pages by counting links, indexes discover the new stories which have caught the eye of most writers. These can also be searched for keywords or links.

  • Aggregators collect the XML feeds of several blogs and present them in a single screen for viewing. Some aggregators work on the server and present HTML pages (flog, Full As A Goog, Daily Rotation), while some work on your machine and collect feeds at preset times (Amphetadesk, Radio). (Browsers such as Mozilla can use a single bookmark to open a dozen blogs in tabbed windows.)

  • Commenting systems let readers add info directly to topics.

  • Trackback systems capture the referring link to discover and present what other writers have said about this article.

How to discover useful blogs? Once you find one which covers a topic, it usually links to others which present alternate takes on similar news... you can follow links within articles, or within a "blogroll" of related logs in the page's sidebar. You can also use directories such as EatonWeb to discover blogs submitted within a particular category.

If you're creating your own blog, consider these suggestions:

  • Find an area that's important to you, a topic on which you truly have something to say
  • If you're interested in multiple areas, consider whether multiple blogs may be more useful to readers than a single blog
  • Get to the point
  • Predictable schedules help... give clues so that readers know how often to check you
  • Link well... show where you got info, tie things together for the reader
  • Show why a link is important to you, and what the reader can expect if they bother to click it... "teaser" links with cute mysterious text get old quickly
  • Consider trying test blogs in a variety of software before committing to a permanent location

Where a blog is a very structured chronological collection of short articles in a single page, a wiki is a collection of unstructured documents. The key concept of a wiki is "anyone can edit any page, at any time."

If you haven't seen a wiki before, take a look at FlashCoders, SeedWiki, WikiPedia, or Ward Cunningham's original Wiki. Each page has an "Edit" button to call up an HTML form with the editable region of the page exposed. Clicking "Save" then submits these changes to the server, and your edits are then immediately seen by any viewer.

Seems like unsustainable chaos at first, but it actually works out quite well. It's easier to restore a page than it is to vandalize it. Ideally the text accumulated on a page is "refactored," and distilled down to a shorter version which is easier to read and more to-the-point.

When anyone can object to, clarify, or edit any content, that which remains tend to be useful for all readers. It's a way to include the fact-checking of blogs without having to read all that extra text.

From what I've seen, a wiki can be a great way for a group to explore and distill information about a specific area. But a wiki can also become an amorphous sea of links, where you chase hard info from page to page and never quite catch it. A wiki is a social document which reflects the group that reads it.

Consider a wiki when you have a discrete new area to explore, as well as a group of people who are committed to exploring it, and who are already familiar with wiki editability.

If you're starting a wiki, consider starting with a strong skeleton... a set of categories and pages to be filled in with information. Consider starting with a small team of editors who can add content and structure before running the risk of having a large crowd go off on tangents or duplicating pages. Consider having someone with a special focus on rewriting pages for clarity and brevity.

A blog is a single structured page with a chronological collection of short articles. A wiki is a collection of unstructured pages. What happens when you have a normal website which needs to be updated quickly by a range of people?

In the usual intranet, a content contributor submits changes to a web team, who then translate it into acceptable markup, merge it into the old content, and publish the new content. This takes time.

Ideally any content contributor could directly change their material on the site. In practice, such chaos rarely works.

People have tried elaborate content-management systems where new data can be entered into a database for automated merging, but the system tends to eventually define the publication.

In-the-browser editing has been tried, from Netscape Composer through add-in ActiveX Controls, but the whole page remains vulnerable to unintended changes, and the learning curve remains steep.

What happens if a restaurant chef wants to change the daily posted menu? If someone who knows only Microsoft Word needs to update the "What's New" page? If an exec needs to change an org chart and job descriptions? If a teacher needs to adjust the posted curriculum? If a community organization needs a volunteer to change the calendar?

How can you protect key parts of the page when others edit the changing parts? How can you use advanced CSS when the people who maintain it know only <font> tags?

Should all contributors have to learn advanced markup in order to publish? Would you trust them if they did?

The web team should be free to actually design and test the site. They shouldn't be locked into formatting changes for the entire group. And the group should be free to publish what they know, without waiting for the high priests of markup to approve their supplications.

The explosive popularity of blogs shows that there's a lot of power in rapid publishing. A wiki shows that a group can expose and refine knowledge in a way that an individual cannot.

What happens when a group can efficiently publish their best information in a structured form? What happens when the web team can focus on the site's actual usability, instead of having their time trapped in publishing details?