Why the Web 2.0 infrastructure needs architects - Part I.
This blog entry is cross-blogged between the VNA website and my own blog site. I like to keep my blog entries, as well as my comments to other people’s blogs, accessible through my personal blog site. The result is that people will be entering comments on different locations. Even more, since Plaxo also includes these blogs in my pulse stream, people can even respond to my blogs in plaxo, and I have noticed that these comments do not automatically show up on the original blog sites. Of course one might argue that "cross blogging" should not be done, but at the same time I think it is a defendable stance that I should be able to publish my blog (and their comments) through multiple channels.
This actually triggered me into realising that the Web 2.0 needs information architects. Of course, when an enterprise considers utilizing Web 2.0 technologies an enterprise architect should be involved in deciding-on/designing the best way of doing this. However, I also think the technology itself needs more architecting, or at least some good old conceptual thinking.
I will try to argue in favour of my position by discussing (at least) three consecutive blog entries in which I will briefly look at specific cases. In discussing these cases I hope to illustrate the importance of more conceptual reflection of the design of these technologies. I do not intend to do a redesign. I only hope to raise some interesting design questions. In the first case, this entry, I will look at blog entries and discussion threads. In the second entry I hope to raise some design questions about notifications mechanisms dealing with new web content. e-mails, new discussion items in a thread, etc. In a third entry I aim to look at making a distinction between the applications around us and the communication channels we use to interface with them (be it via Web, e-mail, mobile phones, IM’s, voice, or whatever).
Back to blogs and cross posting. In the remainder of this blog entry I hope to take a journey along a number of design questions pertaining to blogs, news servers, discussion threads, public discussions and private discussions, and e-mail. For people new to blogging, news servers, e-mail, etcetera, the channels through which one can publish/discuss one’s ideas and thoughts are overwhelming. Why does it have to be so complicated? When posting a blog entry, one merely wants to start a discussion/dialogue. The same applies to a posting on a news server, or an (open) e-mail to a group of recipients.
Let’s start with blogs. What is a blog really? At first glance, a blog could be thought of as comprising of an initial posting followed by a sequence of comments, while this construct is usually displayed on some website. But, why make the connection between the content of the blog and its presentation explicit? Any database designer will argue that a distinction should be made between content and different ways/forms/locations of presenting this content! Imagine having a distinction between a blog-content server and blog-presenting applications. This would enable people to submit a blog to a blog-content server, and have it being displayed on multiple (relevant) blog sites. In other words, I would be able to write one blog entry (which you might add comments to), which is stored in one (logical) location, while being displayed (including comments gathered from all directions) at any blog site I choose to.
Once we have taken this step, we can actually think off blogs as being stored on a server with a well-defined interface such as a news-server (NNTP) or a mail-server (IMAP), while being displayed (as an interactive entity to which new comments can be added) by means of multiple applications (blog sites, Plaxo, etc). One might even go as far as to offer NNTP and/or IMAP interfaces to the blogs. Given the fact that we can subscribe to people’s blogs using RSS feeds from our mail clients, why not be able to write (and read) comments to these blog entries using our mail clients?
But, if we are to regard blog entries and their comments as discussion threads we observe on news servers and indeed in our inboxes (see GMail’s discussion threads and/or the thread option in your favourite mail clients), why not unify all of these? Indeed! Why should we have to make a distinction between Web 2.0’s world of blogging and the old world of news threads? Why not unify this into the concept of a “public thread” served on servers and accessible by way of a myriad of applications? With a public thread I refer to a discussion thread that can be read and contributed to by basically anyone (maybe moderated).
In doing so we actually have to slightly revise our initial idea of a blog comprising of an initial entry followed by a sequence of comments. What one can typically see happening on news servers is that discussion threads branch off. In other words, a comment on an earlier posting may lead to comments on the comments rather than on the original positing. And indeed. Why would I not be able to write a comment to someone’s blog entry and regard this as a starting point of a new blog entry with its comments?
How about discussion threads on our e-mail folders? They are indeed discussion threads but they are not public. They live in our e-mail folders. Even more, they live in multiple e-mail folders in a loosely-synchronised way. Each of the participants of an e-mail discussion will be able to find a (partial) thread in their inbox, based on the level at which the participants have shared the discussion among the group of discussants involved. This makes e-mail threads similar, yet different, from public discussion threads. However, from a user-interface point of view (i.e. your e-mail client) there does not have to be much difference, it only needs to offer a “discussion thread interface”.
In the above discussion my aim was not to claim a specific re-design of blogs, e-mail, news servers, etcetera. However, I do hope to have illustrated that a lot of the technologies we currently use for news posting, blogging and e-mailing, which might benefit from some fundamental conceptual (re)thinking. In other words, we need architects to redesign Web 2.0.
This actually triggered me into realising that the Web 2.0 needs information architects. Of course, when an enterprise considers utilizing Web 2.0 technologies an enterprise architect should be involved in deciding-on/designing the best way of doing this. However, I also think the technology itself needs more architecting, or at least some good old conceptual thinking.
I will try to argue in favour of my position by discussing (at least) three consecutive blog entries in which I will briefly look at specific cases. In discussing these cases I hope to illustrate the importance of more conceptual reflection of the design of these technologies. I do not intend to do a redesign. I only hope to raise some interesting design questions. In the first case, this entry, I will look at blog entries and discussion threads. In the second entry I hope to raise some design questions about notifications mechanisms dealing with new web content. e-mails, new discussion items in a thread, etc. In a third entry I aim to look at making a distinction between the applications around us and the communication channels we use to interface with them (be it via Web, e-mail, mobile phones, IM’s, voice, or whatever).
Back to blogs and cross posting. In the remainder of this blog entry I hope to take a journey along a number of design questions pertaining to blogs, news servers, discussion threads, public discussions and private discussions, and e-mail. For people new to blogging, news servers, e-mail, etcetera, the channels through which one can publish/discuss one’s ideas and thoughts are overwhelming. Why does it have to be so complicated? When posting a blog entry, one merely wants to start a discussion/dialogue. The same applies to a posting on a news server, or an (open) e-mail to a group of recipients.
Let’s start with blogs. What is a blog really? At first glance, a blog could be thought of as comprising of an initial posting followed by a sequence of comments, while this construct is usually displayed on some website. But, why make the connection between the content of the blog and its presentation explicit? Any database designer will argue that a distinction should be made between content and different ways/forms/locations of presenting this content! Imagine having a distinction between a blog-content server and blog-presenting applications. This would enable people to submit a blog to a blog-content server, and have it being displayed on multiple (relevant) blog sites. In other words, I would be able to write one blog entry (which you might add comments to), which is stored in one (logical) location, while being displayed (including comments gathered from all directions) at any blog site I choose to.
Once we have taken this step, we can actually think off blogs as being stored on a server with a well-defined interface such as a news-server (NNTP) or a mail-server (IMAP), while being displayed (as an interactive entity to which new comments can be added) by means of multiple applications (blog sites, Plaxo, etc). One might even go as far as to offer NNTP and/or IMAP interfaces to the blogs. Given the fact that we can subscribe to people’s blogs using RSS feeds from our mail clients, why not be able to write (and read) comments to these blog entries using our mail clients?
But, if we are to regard blog entries and their comments as discussion threads we observe on news servers and indeed in our inboxes (see GMail’s discussion threads and/or the thread option in your favourite mail clients), why not unify all of these? Indeed! Why should we have to make a distinction between Web 2.0’s world of blogging and the old world of news threads? Why not unify this into the concept of a “public thread” served on servers and accessible by way of a myriad of applications? With a public thread I refer to a discussion thread that can be read and contributed to by basically anyone (maybe moderated).
In doing so we actually have to slightly revise our initial idea of a blog comprising of an initial entry followed by a sequence of comments. What one can typically see happening on news servers is that discussion threads branch off. In other words, a comment on an earlier posting may lead to comments on the comments rather than on the original positing. And indeed. Why would I not be able to write a comment to someone’s blog entry and regard this as a starting point of a new blog entry with its comments?
How about discussion threads on our e-mail folders? They are indeed discussion threads but they are not public. They live in our e-mail folders. Even more, they live in multiple e-mail folders in a loosely-synchronised way. Each of the participants of an e-mail discussion will be able to find a (partial) thread in their inbox, based on the level at which the participants have shared the discussion among the group of discussants involved. This makes e-mail threads similar, yet different, from public discussion threads. However, from a user-interface point of view (i.e. your e-mail client) there does not have to be much difference, it only needs to offer a “discussion thread interface”.
In the above discussion my aim was not to claim a specific re-design of blogs, e-mail, news servers, etcetera. However, I do hope to have illustrated that a lot of the technologies we currently use for news posting, blogging and e-mailing, which might benefit from some fundamental conceptual (re)thinking. In other words, we need architects to redesign Web 2.0.
Hmm, communication channel fusion. Not a bad idea at all. Why not start an open source project?
ReplyDeleteThe idea of channel fusion is interesting indeed. It's funny to see my "old" research topic being addressed again. I've added a post to my blog (http://van-gils.org/wordpress/index.php/2008/01/16/web-20/) to offer my perspective...
ReplyDeleteInstead of starting an OSS project right away and dive in, we'd better do some thinking first :-)
Welcome to the blogosphere!
ReplyDeleteYou state: Of course, when an enterprise considers utilizing Web 2.0 technologies an enterprise architect should be involved in deciding-on/designing the best way of doing this.
Especially the phrase 'of course' caught my attention. Why do you think enterprise-architects should already be involved this early on in the process? Is strategy in their domain too? I would be very interested in seeing a post why you feel enterprise architects add value to an organization, and what you feel should be part of their responsibilities. If you make me really happy, please address the role of enterprise architecture in relation to the effectiveness and efficiency of information security controls.
Kees