The other day, I released a mind mapping gadget for google wave, and its proven to be quite popular. Popular for something I knocked together quickly anyway. There's an active wave discussing features, which also serves as the main description of the gadget. Its getting a bit long now, and I'm aware that there is a limit to how big waves can get before they start to slow down. It also gets to the point where I want to simplify things so that a new reader coming upon the wave doesn't get confused by the threads of conversation there.
The way that I am using wave at the moment is that there is a single shared document at the top (the root blip) which contains the topic of discussion, and in this case, a mind map of features and votes for features. The blips that come afterwards are a discussion list, much in the same way that comments can be added to blog posts. Whilst they form an important part of the wave, the value of information they contain decreases as they become less topical. It is really the latest comments and blips that are the important bit, at least to people that are returning to long running conversations.
Other systems show the most recent comments on the top, and show older comments on separate pages to stop the page from getting to big. I'm tempted to suggest that wave should do the same thing, but I wonder if its because we're all still figuring out the best way to use wave. Are there different usage patterns for waves that means it makes sense to have every single blip on the screen, even if it means the page is three miles long? I'm still mulling that one, but in the mean time I think there is a need to come up with a way of managing long running waves. Here's my thoughts on how it could be done.
Option 1: Create a new wave to "Continue Discussion". This is what most people seem to be doing at the moment, but it means that anybody who has linked to the page is now linking to (or embeding) a dead version of it, and would then need to click through to see the new version. It also breaks the fundamental principle of URLs in that a URL represents an object for its lifetime.
Option 2: Delete the old crufty posts. That's not very nice to the people that wrote those posts in the first place. Besides, those comments provide useful context for a new reader to be able to catch up with the rest of the people on the wave. In the end, you are removing information from the system, rather than presenting it in an accessible way, and thats never a good idea.
Option 3: Have an archival bot participant on the wave. This bot would monitor the wave, and when the number of blips starts to get high, it would progressively copy the older blips into an archive wave and subsequently delete them from the original. It would also add a link to the end of the root blip showing people where the archive wave is.
I've had a quick look to see if anyone has done this yet, and I haven't found anything, but I think its a great idea. The only technical issue with this approach that I see at the moment is that the archived blips would not have the same author(s) as the original blips, as it would be the bot that authored them. The bot could add some text indicating who the authors were, but its not quite the same.
I really like the idea of the archival bot. Once I get back from Sydney I might give it a go.
Thursday, November 5, 2009
Subscribe to:
Post Comments (Atom)
Option 4: Hierarchy of waves. The main wave can have the content and also keep a list of waves that have the discussion with only actual content changes happening on the main wave. When a discussion wave gets too long (or after a fixed period) create a new link on the main wave - perhaps insert it above the the other discussion links. People link to the main wave so they will see that a new wave discussion has been added and can start following it. This could be done hierarchically so for really long discussions you could have a a link to waves (eg monthly waves) which has links to more waves (one for each day).
ReplyDeleteAh yes, thanks for that one. That's another popular choice out there at the moment. In order to make it work properly, you need to have the discipline to create the waves up front, and you need to encourage your users to use them in the right way. Trying to get internet users to do what you want is like trying to herd cats.
ReplyDeleteIn the end, the thing I don't like about this is that it isn't automatic. The system should make our life easy... one click if possible. It shouldn't require us to perform manual steps all the time.
I still like Option 3 :)
I still like option 2 - One useful application for the wavelets is like a wiki - a repository of collaborated information with contextual notation and temporary discussion. Used in this way, the most important blips to keep may actually be determined by context, rather than age. In this case I would probably leanm towards option 2 - agreed content is added, updated (replaced) and retained in place in the wave, and transitory converstation blips are pruned when out of scope and obsolete information is overwritten or removed. In this case you're not actually losing the information, because it is still available via the playback functionality (so the storage is external to the wave interface and only accessed on an as required basis).
ReplyDeleteThough you're quite right that the etiquette of deleting other peoples blips is pretty sketchy - busts open a whole new can of worms around wave ownership :)
Good point. Yeah, date alone isn't the only measure of relevance. Any real measure though requires understanding the context of the conversation, making automated decisions difficult. Personally, I'm not that keen on regularly going through my waves to maintain them. That'd take too long.
ReplyDeleteI wonder if there is a option which consists of a hybrid of two and three. Again we have a bot automatically moving things around, archiving things, potentially collapsing conversation threads down into more compact forms, that sort of thing. This is managed by a more complex rule engine than just date of post.
For a start, if any blip has a reply, then the entire thread is considered as fresh as that reply (as a start, you could get sophisticated with when and how you recurse the archival into sub-threads). This could also allow threads to come back into the main wave from the archive wave.
Secondly, authors (or wave gardeners) can mark some threads (either with their own reply or by editing the blip) to add tags which indicate how they should be treated. You could have the following tags
#FAQ
#troll
#RTFM
#helprequest
#himom (for those posts where people just say "testing")
#selfpromotion
#criticism
#suggestion
and so on and so forth.
The bot then uses its rule engine to determine what to do. Authors could even start self-tagging their posts, although the potential for abuse is there.
How does that sound?
I guess it's always going to come down to some level of user accountability, and to a certain extent ownership. Ultimately, who has accountability for (or authority over) the wave?
ReplyDeleteIt will depend on how the wave is used A bunch of kids with a 500 blips of pointless jibber jabber (damn kids, get off my lawn!) is going to be unmanageable no matter how you poke it.