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?
|