Over the last two years, we have acquired a large amount of data on CoWeb, a knowledge-building environment (KBE) that allows its users to create web pages on-the-fly. We have observed several functions that the CoWeb is serving in its various uses. Now, we are able to reflect on those functions and speculate on what features of our system enable them. In turn, we can take that to design new features or expand on old features that might better enable those functions or even cause new functions to develop.
One function of the CoWeb is writing papers, reports, and write-ups. One of the key features that enables this is that it can be done fast (CoWeb is a derivative of Ward Cunningham's WikiWikiWeb; "wiki wiki" means fast in Hawaiian). To enable that process to be even faster, we expanded the features of our text formatter so that users could write nice looking pages without having to rely on HTML, which is verbose and unforgiving. Also, we added specialty code to some sites; for instance, on a few CoWebs, Matlab users can import their code with just slightly more than copy/paste.
Another function is to organize information. Our older CoWebs made it easy for people to create links to other pages and thus weave the information together. But, the user was only able to browse those pages in a normal WWW one-path way (the user could only see what pages linked from the page she was viewing, but not those that linked to that page, unless someone explicitly built in those links). We have introduced a feature that shows the links to that page on that page.
Here is one speculation of how this new feature might cause new functionality: In many of the CoWebs, participants have a personal page linked by their name. It has become customary that users sign notes in a discussion or identify pages they authored with their name link. Now, with the new functionality, a participant can go to their page and have access to all the links to the pages they have signed. Since this information will be highly correlated to what they are interested in, it will make staying up-to-date on that information easier (similar to bookmarking).
Also, it is important to consider how this new feature might affect old functionality. Many of our users claim ownership of the pages (or spaces) they create; we believe this ownership to be a powerful function. One feature that enables ownership is that much of the screen real estate is based on the user's input. Our new feature will take up some of that screen space. With that insight, it behooves us to minimize the space the new feature takes up without adversely affecting its usefulness.
Moving from function to features and features to functions allows our KBE to keep evolving. We are not only able to grow the features of our design, but can diverge paths to create whole new systems; our KBE can thus cease to just be an implementation and move to being a development platform for KBEs. By going back and reassessing what functions our users invent and correlating that to the features of the system, we gain a deeper understanding of the nature of KBEs.
I am a new CS PhD student, in the College of Computing at the Georgia Institute of Technology, working with Mark Guzdial's Collaborative Software Lab. My principal interests are in educational technology, human computer interactions, and ubiquitous computing. As the main programmer behind the new version of the CoWeb software, I am interested in how it can be used in different situation and how different features can enable different usage. One of my current interests is taking this collaborative group environment (CoWeb) and using it for an audio-based portable personal hypertext knowledge environment for augmented memory and document publishing.
I see this workshop as a way to further my understanding of KBEs, their functions, and their features; I hope to use that to further expand our system and garner ideas for new systems. I would bring to the workshop a designer's perspective along with significant experience in implementing KBE software.