As I said in my last post a major issue we were facing in the Reasonate testing was quickly gaining an global overview of a project or individual’s progress without having to read and understand numerous scrapbook-like blog postings. Just to complicate matters these posts are often related to, but not explicit in their overall meaning or relationship to the design’s end goals. Or how I put it more pragmatically last time round:
“What was needed was a mechanism easily ‘wrap things up’ into a format that was easily disseminated by the casual observer yet retained the rich chronological underpinnings the blogging process had successfully established….”
This process of wrapping up tied into something mentioned by both Robert Amor and Mark Burry when I had seen them last (at separate times). Both had mentioned Australian research into the use of Wiki’s in the design process, or more specifically the work of Jane Burry on wiki.
My initial reaction to wiki is negative. This is in part because I’ve seen a number of software projects try to solve their problems by creating a wiki only at the end of the process to have a very expansive website filled with lots of very empty pages. Also I feel by their very nature wiki are viewed as authoritative sources of information rather than places for conversation or debate. Probably the best argument I have for this is that the most successful wiki are authoritative in purpose, such as Wikipedia and community-orientated software documentation like those in place for Ruby on Rails or the Hula Project. In most situations the edits made are not viewed as some form of ongoing debate but rather a case of who can get the last word in on a subject matter usually very close to the author’s heart. There are many examples of this on Wikipedia such as Adam Curry’s revisionist edits on Podcasting and perhaps more worryingly attempts by employees within the U.S. Congress to publicly pimp their politicians.
Attitudes like this don’t bode well to wiki use within the initial phase of conceptual design which is why I have focused more energies on the use of blogging in this area. However as has been found with Reasonate testing, too much stream of thought and scrapbooking of ideas and not enough authoritative opinion can be just as bad as single, dominant personality commandeering a wiki for use as a personal soap box.
Enter the Wrap-up.
One of the most useful things I find about Wikipedia entries is not the text itself but the external references usually listed at the bottom of the page. These references act as reassurance and further reference for the subject matter detailed in the wiki document. The Wrap-up would be the intelligent collection of aggregated project blogs, files and tags provided through the Reasonate API for summarising (wrapping up) in a wiki environment.
Over the last few weeks my attitude towards what Reasonate programatically has changed after a very fruitful meeting with Mike where we discussed Web 2.0 services and how they related to Reasonate. The logic behind this thinking will appear in my next post but to summarise I see Reasonate now as a 'Building Information Aggregation Service' (BIAS). Rather than a standalone user experience Reasonate should be a service that pulls together various project information sources and then projects this information against a defined participant/project structure. The outcome of this process would be an intelligently searchable index interfaced primary via a Google-like API, or for a more simple explanation, think Technorati for design projects.
With this intelligent index you can then construct search terms that form the basis of the project wrap-ups. You could for arguments sake construct wrap-ups out of an explicitly defined set of URL’s but this is ineffective. For one URL’s in the real world are not constant, domain names change, software behind blogs is updated breaking older URLs and content is deleted or edited to the point where it no longer bears any resemblance to its former self. Secondly its difficult to justify something that is arbitrary, a data-set constructed of a specific date-range, tag and author combination by its very definition begins to tell a story, whether it is useful or not comes down to the authors of the wiki wrap-up.
For example a conceptual design wrap-up may specify the following content constraints:
- Published between X & Y dates
- Submitted under the Project A category
- Submitted by members of the design team
This filter would create the backdrop for the wrap-up Wiki entry and through its data-set establish those participants in the project who hold editing rights. The search filter would also be used as the basis for establishing associated resources to the wrap-up Wiki such as links to files, blogs and tag clouds. This would remove a lot of the manual groundwork associated with a wiki and leave the authors free to concentrate on one thing, wrapping up the activities embodied in this aspect of the design process.
Being able to define intelligent search filters would also hold significant productivity improvements when it came to generating the wiki wrap-ups or simply understanding design progress. Rather than having to review the entire process to establish appropriate ‘wrap-up’ moments template rule-sets could be applied based on prior experience. Also perhaps more importantly wrap-ups like the ‘brief’ could be easily reassessed during the design process to see if the underlying conversation has changed significantly enough to justify a reassessment of the ‘brief’ wrap-up. For example, if the wrap-up was written in March how many new posts/tags since then have been introduced to the underlying filtered set and how does this influence the summarised idea?
On a slighty different (but similar) discussion thread
As an endnote something that came to mind as I mentally debated the 'meaningless page full of links scenario' versus a more intelligent search filter based on approach was a recent podcast discussion between Doc Searls and Steve Gillmor. Doc Searls employs a very hyerlink rich blogging style, sometimes to the point that the post itself becomes slightly meaningless (unless reading 'here is good, so to here and here but not this' makes sense to you). Steve's underlying point was that the power of the hyperlink lay not in its end-point but rather its intent and how others have (or have not) found the link as a tool for furthering some intention useful. This concept feeds into his ideas around gestures, especially the Gesture Bank and the AttentionTrust. These movements are something I must admit I struggle to understand but on listening to this podcast I definitely agreed with his opinion that a pool of static hyperlinks without explicit intention hold a lot less value than one may like.