McGee's Musings:

I find that creating knowledge is hard work. And, I've found that keeping a weblog is one absolutely essential tool for helping me catch ideas before they slip away and then working to develop them into something useful.

[via Mathemagenic]

What are the shortcomings of weblogs? How do we solve those problems? What comes next?

Curiouser and curiouser! in There's a hole in my bucket....

As a klogger, over the past 3 months or so, I have recorded & published tens if not hundreds of thoughts.  I doubt if I shared one quarter of output during the last 6 years I worked at various companies.  Oh I would probably have emailed here and there, spoken up during meetings.  But I wonder just how much knowledge is being lost, second by second, in most companies by each employee.  Then multiply up...

But even if they would catch those thoughts, it's going to be very difficult to find something relevant and to understand it our of the context. More or less like forum discussion: you have to follow for some time to make sense of it.

Going through blog archives is not easy... So far I benefit more from the distributed dialog and from the collective filtering. So, blogs is more for sharing, rather than capturing...

[Mathemagenic]

A good point! If klogging is about sharing, then you have to have both parts of sharing: the giving and the receiving! Quite often, the receiving might be just as tough as the sharing -- for a variety of reasons. First, the recipient has to be receptive to learning, receiving knowledge (especially since learning is much more than just receiving knowledge). Second, the recipient has to be able to actually receive the information! If it can't be found, or if it is not in the appropriate format to be able to answer a question, then it is useless and the klogger has wasted his time.

A fabulous idea.

John Udell about on the writeable web, the uses of storytelling, and project weblogging (via Radio Free Blogistan and KMpings):

Nice "sanitized picture" of the projects weblog with a commentary

•  Time line. In the weblog tradition, recent items appear at the top, and older ones rotate out to archive pages.

• Commentary. Entries on the time line refer to, and comment on, landmark documents.

• Categorized items. The time line generates narrative flow, but it doesn't categorize items along other important dimensions which are, at the moment, hot issues to resolve, and agreements on how to resolve them. So, these appear in their own columns, and expand on the teasers that appear in the time line.

• Directory. Names, e-mail addresses, phone numbers.

• Files. These include PDFs, spreadsheets, Word documents, HTML documents, and -- crucially -- selected e-mail messages that I have intercepted and promoted to the status of landmark documents.

It looks like a newspaper and, indeed, serves a similar purpose...

[Mathemagenic]

This could be a big deal.

John Robb on using Radio as the next generation desktop [via Mathemagenic]

He says:

His idea, which I think is wonderful, is to put K-Logs at the center of the desktop for these employees and surround them with digital dashboards that connect them to the data they need to do their job.

Indeed. We need to make it easier to gather useful information into a single place; or at least to have the information indexed in a single place. Having a "digital dashboard" through which you can push information into the appropriate bins would be a great step.

Search, very much like a Google on the desktop, would tie it all together.

Google on the desktop would be great. Actually, I think you can do even better. If you're entering the data, you can apply categories and keywords that you trust. You don't have to worry so much about someone spamming the keyword index when you're working within a cooperative organization.

Basically, the K-Log would serve as the routing system for employee data entry.

I can see some problems with this. But there's an opportunity for customized klog input interfaces. Front-ends that are equipped to gather specialized, formatted types of knowledge. Something to think about.

Beyond the infrastructure, you have to think about how the content of all those weblogs scales. Sure, you can put 10-20k weblogs on a single static server and fit the 5-10 required servers in a rack. (Note: I don't know a whole lot about the resources required for this; I'm trusting John Robb's numbers here.) But how can you find what you're looking for over 10-20k weblogs?

It's very easy to throw hardware and bandwidth at sites and make them scale. The costs are more or less distributed depending on your architecture. What's difficult is building a scalable community, of finding like-minded souls. And thus we have the Radio Community Server, the Blogging Ecosystem, blogdex and others — or the less-sophisticated GeoCites Member Pages directory.
[The Peanut Gallery]

This point can't be emphasized enough. Without some kind of way of either organizing or being able to search (or filter) the information on a large number of weblogs, you end up with the chaos that is the Web, albeit on a smaller scale (but without Google!). So it is crucial to be able to organize those weblogs into some kind of useful structure.

I'm watching the action on the ecosystem/indexing front to see what happens. (And participating on the blogchalk front, although the organizational scheme and the idea behind it is much less formal or useful compared to, say, the Blogging Ecosystem.

The Peanut Gallery discusses a John Robb post on "Communities of Scale":

If done centrally, you could probably put a thousand or two weblogs on a single server. That would take 50-100 servers, extensive rack space, and a huge budget for admin of those servers given that there is complex functionality on the server. In a decentralized model, you could put 10-20 k weblogs on a single static server. That would require only 5-10 servers (a single rack) and a very low admin budget.

This depends entirely on how the system's built.

First, let's distinguish between the centralized and decentralized models. In the centralized model, all functions are hosted on the server-side. In the decentralized model given here, the server exposes your works to the world, but editing and other tasks are completed on your desk. The classic web hosting arrangement is this decentralized model. For ease of use, to get away from the complexity of synchronizing filesystems over FTP, many vendors provided web-based HTML editors, and moved to the centralized model. But at some point it becomes easier to buy GoLive or DreamWeaver — unless you're using Blogger, Moveable Type, or one of the Userland tools. Think of the server as your upstream cache.

In a centralized environment, the systems performing the editing tasks are often segregated from those serving the final product. Usage shows that pages are read more frequently than they are written, so the editing systems need only support a small fraction of the total membership. If you store the data separate from the presentation, and render the two on the fly, then you run into some processing bottlenecks, but most on-line editors generate static HTML of one variety or another. The point being that you don't need 50-100 servers for 100,000 weblogs unless you're Manila.

[The Peanut Gallery]

Using the Internet as a prime example, I think it's much easier to scale a decentralized system. You mostly have to add resources at the edge, where necessary. The impact of growth on those few centrally located resources is less than in a centralized system. Especially if you're talking about the (relatively) small amounts of bandwidth and storage required by webloggers.

One issue with the decentralized model is that security can be difficult to implement -- generally speaking, it is easier to secure something when all the resources are concentrated. In many enterprises, this is something that can't be ignored.