RSS caught on because it was good at delivering stories from big news organizations and at the same time delivering weblog content. Interesting aggregation tools were possible because there was a critical mass of content. This was and remains the hard work. No format, no matter how interesting, sophisticated or powerful can gain traction without content.

RSS still has more to do. The next big innovation will be blog-browsers, native apps that browse archives of weblogs outside the limits of Web browsers, and archives of weblogs will be in RSS 2.0 because it's a very simple format, you can understand it without understanding any theory beyond what you've already learned with HTML, and because it's an easy evolution for the most deployed formats, 0.91 and 0.92.

The XML-RPC interface for the aggregator will be important as well, it will allow user interfaces to connect up to powerful engines. More XML-RPC interfaces are coming, particularly awaited is the next level of the Blogger API. We hope it will build on the MetaWeblog API.

Anil:

It's time to create a tool that's designed for the job of viewing, managing, and publishing microcontent. This tool is the microcontent client. ...

The primary advantage of the microcontent client over existing Internet technologies is that it will enable the sharing of meme-sized chunks of information using a consistent set of navigation, user interface, storage, and networking technologies. In short, a better user interface for task-based activities, and a more powerful system for reading, searching, annotating, reviewing, and other information-based activities on the Internet. ...

My cryptic summary:

• Searching, improving by searching in context, a la semantic web. Search that understands structured data (yellow pages, auctions, flights, job listings). And that learns new contexts, new semantic structures, as needed.
• Aggregation, not just of news microcontent but also of other structured data (yellow pages, auctions, flights, job listings). And learning new contexts, new semantic structures, as needed. Actively and passively.
• Authoring, actively and passively. Blog posts, metadata including annotations and comments, and other structured data.

I met Bret Fausett at Digital ID World. Brett asks about the idea of a .blog top level domain (like a .com or .net). Lots of good comments; here are mine.

I concur with the general objections stated before. The central identity of blogging is that a human voice (sometimes a small tribe) is found in one place, instead of being scattered in many large community sites.

That said, what creative ways could we exploit a .blog tld?

Might this help with search?

In a world of microcontent, could DNS help each post be unqiuely identified or found? If so, would DNS take part in update notification, perhaps helping with threading of conversation?

I know a number of people who blog anonymously or pseudonymously. Could the registrar help assure privacy of domain ownership?

Assuming everyone will get at least one personal domain for blogging, this could be a very active registry. Compared to businesses, they have short lives too.

Blogging is a form in transition.

Personally, I think blogging as a form will merge with all the other forms of digital expression. With email and IM first. With voice/video conferencing, streaming videos, browsing, and PowerPointing later.

Watch it change:

• as more people blog from their foto-mobiles
• as devices start to blog ("My car's day")
• as audiobloggers create radio shows and videobloggers create televsion programming
• as Sims characters start to blog.

Moving forward, see a convergent software client emerge.

Source: evanwolf group, 2002.

A lot to shovel into one bucket.

Why bother?

Synergy and Usability.  

Synergy because each of their abilities are horizontal and complementary to to the other functions. This is why spell checking rolled into word processors.

Usability, because with great design, learning one feature makes it easier to learn and do the next. Once you learn spell check, any sort of text editing or proofreading tool is a snap. This slashes the incremental user burden of new features. So spell check, for instance, can cross into spreadsheets, presentations, email, even project management tools without taxing the new user.

What else do you need from a converged user experience? What are our collective design goals?

Simplicity. Unity. and Adaptability.

The surfaces presented to a user will adapt to each medium and form. Perhaps I need a storyboard for planning a video; maybe it can also be used for planning a presentation, an extended blog post, an interaction with a customer. Are you presenting on a computer projector, a video stream, or paper? The software should understand how to adjust.

The converged client should also adapt to people. A person's culture, experience, goals, interests, and skills. This is hard as adamantium, but it is what allows robust tools to work for most people in many situations. Some people need help and wizards and automatic spelling correction (think Microsoft Office), others need directly manipulable affordances (think Kai's Power Tools). Small children need different environments (Power Puff Girls) than teens than adults. Grokking world cultures and subcultures, and reflecting those in software, is a fine art.

Adjust to hardware platforms. How do you incorporate the strengths and limitations od the PC fat client, game box, TV set top, and thin clients on the mobile phone and web browser?

Embrace specialized content. Some database tools can automatically generate editing screens and menus and even workflows from data structures and definitions. We need to do the same thing, but across many kinds of content and activities. From blogging movie reviews (with extra metadata and internal structure) to IM conversations guided by scripts. 

A constraint: Adapt while preserving and leveraging the user's prior knowledge, skills, and abilities.

So.

Contrast this with Anil Dash's microcontent client. I'm seeing the converged client as a conceptual superset or framework for building microcontent clients.

Can you imagine the plumbing?

You'd want to design for:

• Flexibility
• Interoperability
• Extensibility
• Scalability
• Polylingual

Your architecture would need:

• Shared services. A common chassis. 
• Open APIs. So third party's can connect, communicate, and interact with the client.
• Plug-in sockets. So tool makers can add their own features and extend the client's abilities.
• Standards support. To increase interoperability.
• Heavy transcoding. Transcoding is a fancy term for converting content from one platform to others. The converged client will have to handle a wider range of content than most. From story outlines to storyboards. From audio tracks to text subtitles. From IM threads to blog posts.

So what?

We're on our way. Blogging tools are starting to interact with email and sounds. PIMs are managing contact information across multiple applications. Community and collaboration features are as critical to games as traditional gameplay.

I'm calling it: 2003-2005 will see many clients converge, weblogs among them. The challenges? Immense. The rewards? Many and rich. The fun? Deep and lasting.

[a klog apart klogging]

A friend of mine asked: how many webloggers are there? This is like "How big is the Internet?"

I searched through Nua and a dozen other internet sites and haven't seen any research on the size of the blogosphere.

I ask you:

1. Do you have an educated guess?
2. Do you know of any prior work in this area?
3. Can you think of a methodology or two to create useful measures of the number of bloggers and the number of weblogs?
4. What related questions would you want answered?
5. How might you use this information?
6. Pitfalls to avoid?
7. Would you join a BlogCensus.org to provide and share stats?

My wild stabs:

1. Do you have an educated guess?
   • Not yet.
2. Do you know of any prior work in this area?
   • No. I've looked.
3. Can you think of a methodology or two to create useful measures of the number of bloggers and the number of weblogs?
   • Some vendors host weblogs and have relevant stats. We could add those up.
   • We could look at download and registrations from the top 5 vendors, and add fudge factors to cover other tools and disadoption rates

4. What related questions would you want answered?

   • LiveJournal.com, has a statistics page: (numbers as of 10 November 2002)
     • Total users: 770910
       • Users that have ever updated: 635168
       • Users updating in last 30 days: 280213
       • Users updating in last 7 days: 200543
       • Users updating in past 24 hours: 72587
     • Gender:
       • Male: 201452 (36.3%)
       • Female: 354085 (63.7%)
       • Unspecified: 131153
     • Account Type
       • Free Account: 718109 (93.2%)
       • Early Adopter: 14282 (1.9%)
       • Paid Account: 36718 (4.8%)
       • Permanent Account: 1218 (0.2%)
     • Country of origin (Mostly English-speaking)
     • US state of origin (California, New York, Florida, Michigan lead)
     • Age distribution (mode=17)
     • Client usage (90% web)
     • Activity: posts by day overall (147k posts last Wednesday) Per-person would be interesting too.
     • New accounts per day (eyeballing a chart it looks like 900-1400 new LJ users per day, averaging about 1100)
   • I'd love to know:
     • How many entries have ever been blogged? (the cumulative number of posts).
     • How many links in posts? (excluding blogrolls and navigation)
     • What blogging tool or service they're using?
     • Blog lifecycles:
       • How long to bloggers of various stripes blog?
       • How many change hosts? Change tools?
       • Why do people abandon blogging?
       • Is there a critical mass, a minimum number of posts per day/week/month that separates those that blog from those that fail?
       • Of people who take a break, how many start again?
     • Number originating within a company or operating behind a firewall
     • Connection speed (does broadband make it easier to blog?)
     • Payload distribution. How many people include pictures, sounds, flash games, or movies? How many bytes are home pages?
     • Syndication. What percentage syndicate their sites?
     • Duplication/Overlap:
       • How many blogs per person?
       • Do you post to them equally? How many are updated daily/weekly/monthly?
       • How many tools do you use?
     • What ancillary tools do you use?
       • Graphics and other media
       • News readers
       • HTML editors
       • email clients
       • blog-specific search (daypop, google)
       • blogosphere navigation (blogdex, blogtree)
5. How might you use this information?
   1. As a blogger.
      • Always good to know where I stand in relation to the pack.
      • Trends might tip me to new capabilities
   2. As a consultant or IT leader.
      • Make better choices about deploying blogging and community tools
      • Use the "bandwagon" sell when appropriate
   3. As a blog tool maker.
      • Understand the markets I serve vs. the ones I don't 
6. Pitfalls to avoid?
   • Hype
   • Irreproducible results
   • Bias - vendor, country
7. Would you join an BlogCensus.org to provide and share stats?
   • As a user, with anonymity.
   • As a vendor, sure.

What say you?