Journal reference: Computer Networks and ISDN Systems, Volume 28, issues 7–11, p. 1157.

Grassroots: A System Providing A Uniform Framework for Communicating, Structuring, Sharing Information, and Organizing People

Kenichi Kamiya, Martin Röscheisen, and Terry Winograd

Computer Science Department
Stanford University, Stanford, CA 94305


People keep pieces of information in diverse collections such as folders, hotlists, e-mail inboxes, newsgroups, and mailing lists. These collections mediate various types of collaborations including communicating, structuring, sharing information, and organizing people. Grassroots is a system that provides a uniform framework to support people's collaborative activities mediated by collections of information. The system seamlessly integrates functionalities currently found in such disparate systems as e-mail, newsgroups, shared hotlists, hierarchical indexes, hypermail, etc. Grassroots co-exists with these systems in that its users benefit from the uniform image provided by Grassroots, but other people can continue using other mechanisms, and Grassroots leverages from them. The current Grassroots prototype is based on an http-proxy implementation, and can be used with any Web browser. In the context of the design of a next-generation version of the Web, Grassroots demonstrates the utility of a uniform notification infrastructure.

1. Introduction

People are currently using an array of disparate systems in order to keep up with new things happening, to file information they want to keep, and possibly to share them with others. Let us look at Tom, a user. Tom usually starts the day by seeing what has happened. To do this, he has to make a tour: First, he checks his e-mail (he looks through the messages which are queued up in his electronic mailbox). He reads a certain number (the rest remain in his mailbox folder), deleting some of the messages, sending replies to others, and filing the ones which he wants to keep into various mail folders in his (private) folder hierarchy. He shares some items with others by forwarding them. Tom next uses his newsgroup reader to read news much in the same way as he does with his e-mail. Then he uses a Web browser to check a number of hypermail archives for new messages in corresponding mailing lists (because he did not want to have all the mail in his e-mail box); there may of course be no new messages in some of these archives. Finally, he runs through a special list of Web pages [URL-minder] to check whether they were updated; for instance, this list includes pointers to pages about conference announcements which were labeled "Check this page regularly for the latest information." Of course, he also keeps a hierarchical Web hotlist in addition to his e-mail and newsgroups folders.

What Grassroots does for such practice is to provide a uniform interface that is integrated at the activity level, that is, at the level of the actual usages, which might cut across the boundaries of conventional applications such as e-mail or newsgroups. When using Grassroots, Tom would catch up with what happened by simply pressing one single button "goto notifier." This would show him a structured description that summarizes all the events which he wanted to be notified about in one form or another. He selects here which event he wants to view. Note that the events are already structured (e.g., by topic or by chronology); this is not achieved through the use of filters, but instead by the way Grassroots makes structure visible to communication partners. For example, a student sending a brief question to his advisor posts his message directly into his advisor's folder for student questions which can be answered quickly; the advisor typically sets up the notifier in a way which gives messages in this folder higher attention, and the notifier then signals arrival of such new messages accordingly. Generally, from the notifier summary, Tom can file the new items into their default position in an hierarchical archive structure by a simple approval; they can also be filed into any other place, of course, if specified.

Thus, Grassroots is not only a system for personal information management, but its ability for access-controlled sharing also enables the continuous construction of shared representations such as "organizational memory" (when used in organizations) [Conklin, 1992], [Ackerman, 1994]. Moreover, since Grassroots also makes visible the underlying network of information flow, it makes it easy for new members of a community to get attuned to the practices of this community [Agre, 1995]; this includes being able to quickly learn about where members of this community receive their information from, etc.

In this paper, we lay out the general framework of Grassroots [Kamiya, 1996] and describe how Grassroots realizes the various components of this framework. We describe how Grassroots provides a uniform interface to usages and practices currently found in various communication and information management systems [Malone, 1992]. Furthermore, we examine the user interface of the current Grassroots prototype, and describe preliminary observations stemming from its use.

2. Collection-Mediated Collaboration and The Conceptual Model of Grassroots

The activities alluded to in the introductory examples have one thing in common: they are mediated by collections of information such as folders, hotlists, e-mail inboxes, newsgroups, and mailing lists. These collaborative activities mediated by collections are what Grassroots aims to support. We group these activities under the heading "collection-mediated collaboration." Grassroots represents and supports collection-mediated collaboration through a simple model with only four classes of objects-collectors, notifiers, links, and articles-and a small number of generic operations.

We find that the daily information activities which are mediated by collections of information can be understood by three major concepts: units for statically grouping collections of information ("collectors"), views for presenting "new" information to each person ("notifiers"), and modes by which people communicate by transferring information between collections. In the remainder of this section, we look at each of these in turn, first examining current practice in existing systems and then how these concepts are reflected in Grassroots.

2.1 Units for Organizing Information and People: "Collectors"

Collectors in Current Practice

The most important concept in understanding collection-mediated collaboration is the concept of containers that accommodate collections of information ("collectors"). The following are examples of commonly used collectors.

* Information Categories/Topics: People organize information by creating collectors that represent categories and by sorting and storing pieces of information into these collectors. Macintosh folders are examples of such collectors.

* Groups for Collective Communication: One might want to make a list of a certain group of people and give information to or receive information from them. Such collectors consist of identifiers of the group's members. A mailing list is an example of collectors used for such collective communication.

* Groups for Access Control: When collectors are shared, they need to be access-controlled for various social reasons. A collector can be used to represent a group of people who are permitted to access some other collector.

* Relationships among Collectors: Generally, one would like to link collectors together in the form of a graph. To represent relationships among collectors, another type of collectors is used. This is illustrated by a hierarchy of collectors, in which an intermediate collector lists sub-collectors. Yahoo [Yahoo] is an example of such a hierarchical information collection structure where each page can be thought of as a collector.

How Collectors Are Reflected in Grassroots

The Grassroots collector (g-collector in short) is one of four main object types of Grassroots. The collectors described above can be represented by g-collectors and manipulated with the same set of generic operations. G-collectors can contain articles (pieces of text such as e-mail messages or news articles), links (pointers to other g-collectors or to external objects such as Web pages), or other g-collectors. (Cf. Figure 1.) There are two sub-types of g-collectors: g-collectors for structuring information are folders; g-collectors for organizing people are rosters. Each g-collector has uniform address (a URL in the prototype). In a roster, a link to one of a person's g-collectors represents the person.

Under a g-collector, a user can create objects (links, articles and other g-collectors), change their attributes, cut or copy them, and paste them into another g-collector (cf. Figure 2)

Figure 1. Grassroots Objects.

Figure 2. Grassroots Operations.

2.2 Views for Presenting New Information: "Notifiers"

Notifiers in Current Practice

When information is added into a collector manually by other people or automatically by a system, the owner of the collector might want to be notified of the addition. Usually there are views that notify them of such new events by listing or highlighting new pieces of information. We call them "notifiers". E-mail readers and news readers are examples. A problem found in current practice is that disparate notifiers present a person information arrived by different modes such as mail and news. It is desirable for these notifiers to be unified into one notifier.

How Notifiers Are Reflected in Grassroots

In Grassroots, each user has one notifier. A user's notifier presents the information items brought to the user's g-collectors without involving the user directly. A notifier is automatically divided into sections corresponding to the structure of the g-collectors; then each section lists the items that arrived at a corresponding g-collector.

In addition to the operation described in the previous section, a user can post items on the clipboard (which has been cut or copied) to another user's folder with an operation similar to pasting the items to the folder. In Figure 1, if John posts an article to folder E, the article does not appear in folder E. Instead, the article appears in section E of Paul's notifier. The recipient can choose some of the objects in a notifier, and accept them; they are then moved and inserted persistently into the corresponding g-collector (Figure 2). A user's notifier can be read only by the user.

A user can also post an article (or a link) to a roster. This is equivalent to posting the object to all g-collectors linked from the roster or its sub-rosters. This way, a roster can be used as a mailing list.

Generally, a collector can be conceptualized as having a store for a collection of persistent items, a store for a collection of newly added items, and three ports, one for pasting things into it, one for posting things into it and another for items coming out of it. As shown in Figure 3, post is an operation to insert an item into a folder with notification to the folder's owner while paste is an operation to do so without such notification.

Figure 3: G-collectors and a Notifier.

2.3 Information Transfer between Collectors

When observing the way people collaborate with the help of collections of information, we find that they communicate with each other by transferring information between their collectors. In this section, we analyze how information items travel between people's collectors.

2.3.1 Transfer Modes: Information Pull or Push, Continuous or Ad hoc

Transfer Modes in Current Practice

Transfer of information between collectors can be characterized by its regularity, by who is initiating it, and by how recipients are notified of it.

One dimension to look at information transfer is its regularity. We consider a transfer to be in continuous mode if all the items incoming to the source collector are transferred to the destination collector, as is the case with newsgroup subscription. In the complementary mode, the transfer between a source and a destination is decided on a case by case basis for each item. We call this the ad hoc mode. For example, each e-mail has its own combination of the sender's outbox as a source and the recipient's inbox as a destination.

A continuous transfer of information items can be initiated by the sender (the administrator of the source collector) or by the recipient (the administrator of the destination collector). We call these modes the pull or the push mode of information transfer, respectively.

Information transfer can be performed with or without notification to the recipient. With notification means that items newly arrived at the destination collector are kept separately or marked distinctively so that someone in charge of the destination collector can distinguish them from older items. In other words, new items appear on the notifier of the administrator of the destination collector. Without notification means that new items are simply inserted into the destination collector.

In summary, people transfer information in one of six modes: ad hoc, continuous pull, and continuous push either with or without notification. Examples are given in the following table.

Table 1. Six Modes of Information Transfer: Examples.

How Transfer Modes Are Reflected in Grassroots

In Grassroots, these six modes can be realized by generic operations including setting and unsetting attributes of objects (cf. Table 2). The operations corresponding to ad hoc modes have been introduced in the previous section.

Table 2. Six Modes of Information Transfer: Grassroots Elements.

Every Grassroots object has a number of attributes, such as the name, the date of creation, etc. Subscription, forward, noticeless subscription, and noticeless forward are attributes of the links. These attributes can be set and unset. If they are set, information flows continuously between g-collectors at the both end of the link. Subscription enables the continuous pull mode while forward enables the continuous push mode.

Consider a folder C, owned by a user John, contains a link pointing to Paul's folder E (as in Figure 1) and the link's subscription attribute is set. Whenever a new item (a link or an article) is brought into folder E, a copy of the new item will automatically appear in John's notifier in section C. If the noticeless subscription attribute of the link is set, a copy of the new item appears in folder C.

Similarly, if the same link's forward attribute is set, then whenever John puts an object into folder C, its copy will automatically appear in Paul's notifier in section E. If the noticeless forward attribute of the link is set, a copy of the new item appears in folder E as long as John is authorized to write into folder E.

A roster can be used to subscribe to or forward to a set of g-collectors at once. A subscription link (a link with its subscription attribute set) from a folder to a roster is equivalent to subscription links from the folder to all the g-collectors linked with the roster or its sub-rosters. The same applies to forwarding.

2.3.2 Inflow and Outflow of Collectors

Inflow and Outflow in Current Practice

People transfer information to and from collectors which they use for collaboration. We call the transfer to and from a collector the collector's inflow and outflow. Reading or displaying information items in a collector is not considered outflow from the collector. Instead, copying or moving one collector's items to another durable collector is considered the outflow from the former collector and inflow to the latter collector. Both inflow and outflow are performed in some of the six modes of transfer described above.

In current practice, people often use collectors with only one mode of inflow and one mode of outflow. Since there are six modes of transfer, we can unfold this into a fine-grained grid of 36 types of collectors. Since the difference between with notification mode and without notification mode is trivial for outflow, the number of types is 18 instead of 36. This is shown in Table 3 with examples for some of the types.

Table 3. Eighteen Types of Collectors: Examples.

For example, Table 3 describes a hotlist (shared or private) as a collector whose inflow is ad hoc without notification mode and outflow is ad hoc mode. This is because the items are put into it on a case-by-case basis without explicit notification to anyone, and since the items in it can be copied to somewhere else on a case-by-case basis. In contrast, items are transferred to a Yahoo page or a mail inbox with explicit notification to someone in charge of those collectors. Newly arrived items are kept separately for evaluation by an editor or marked distinctively so that the recipient can recognize them. Therefore, inflow to them is ad hoc with notification mode.

When a person subscribes to a newsgroup, all the items incoming to the newsgroup are transferred to the news inbox, which conceptually exist at the subscriber's side. This is similar to the situation involving a mailing list, where all the items arrived at the mailing list are transferred to the mail inboxes whose addresses are on the list. One of the differences between them is who controls the transfer. Newsgroup subscription is decided by the subscribers, not by someone in charge of the newsgroup. For this reason, the outflow from a newsgroup and the inflow to a news inbox are continuous pull mode. In contrast, the administrator of the mailing list controls whether to have an address on the list or not. Therefore, continuous push mode applies to the inflow to a mail inbox whose address is on a mailing list and outflow from the conceptual set of messages arrived at a mailing list. A hypermail page receives mails in the same manner as a mail inbox whose address is on a mailing list, while a hypernews page receives articles in the same way as a news inbox.

Usually a newsgroup receives articles spontaneously from various people. A mailing list receives mails in the same fashion. Therefore, their inflows are both ad hoc mode. When they are moderated, their inflows are ad hoc with notification, since the newly arrived items are not inserted directly but kept separately on the moderator's notifier.

The outflows from the collectors in the first row of Table 3 are all ad hoc since, usually, items incoming to these collectors are transferred to somewhere else spontaneously or are not transferred to anywhere at all.

How Inflow and Outflow Are Reflected in Grassroots

Grassroots provides elementary objects and operations that correspond to six modes of transfer. Any mode can be used as inflow to or outflow from a g-collector as depicted in Figure 4. By combining these elements, a g-collector in Grassroots can be used as any of the eighteen types described above. A g-collector can be flexibly transformed from one type to another by adding or removing appropriate elements. In addition, a g-collector is allowed to have any combination of six modes as inflow or outflow (instead of having only one inflow mode and one outflow mode).

Figure 4. Inflow and Outflow: Any mode can be used.

2.4 Controlling Flow with Access Control

Access Control in Current Practice

In current practice, access control to collectors is sometimes not very flexible or might even not be available, such as in newsgroups. Shared hotlists on Web servers can be access controlled, but a user has to register a password for each server. As for shared filing, in many systems operations for manipulating the access control list and that for manipulating data are not uniform. As a result, for people other than system administrators, it is not very easy to set up a group for access control or to control access using a group.

How Access Control Is Reflected in Grassroots

Whether an item can flow into a g-collector or whether it can flow out of it is uniformly constrained by an authorization mechanism based on access control policies.

Users have an identity representation with their g-collectors; they are expected to be authenticated on a per-user basis. Access control policies can be articulated with respect to groups of people. Such access-control groups are just the same kinds of human-organizational g-collectors which have also been used to represent mailing lists, etc. In other words, it is as straight-forward for an end-user to maintain an access-control group as it is to maintain a hotlist of specific documents.

In the model of Grassroots, access is controlled by three attributes of g-collectors, read protection, write protection, and post protection and three attributes of links, read authorization, write authorization, and post authorization.

For example, in Figure 1, if folder C's read protection attribute is set, no user except for John can read the contents of folder C. However, if read authorization attribute of the link from folder C to folder E is set, Paul, can read the contents of folder C. Similarly, if write authorization or post authorization attribute of the link is set, Paul can change the contents of folder C or post articles to folder C.

A roster can be used to authorize a group of people at once. A read-authorization link (a link with read authorization attribute set) from a g-collector to a roster is equivalent to read-authorization links from the g-collector to all the g-collectors linked with the roster or its sub-rosters. Then, owners of all g-collectors linked with the roster or its sub-rosters are authorized to read the g-collector. The same applies to other authorization rights.

3. Usages of Grassroots

3.1 Using Grassroots for Usages Found in Existing Systems

Grassroots provides a uniform interface to functionalities provided by existing systems such as e-mail, newsgroups, or any of the other examples which fit into the table of 18 types of collectors in the previous section. Often, Grassroots is not only able to cover functionalities of existing systems, but also offers advantages over them.

3.1.1 Example: E-mail

A Grassroots folder can be used in the way an e-mailbox is conventionally used (Figure 5). People can post articles to a folder, and its owner can be notified of them through his or her notifier. The difference is that, unlike in conventional e-mail, Grassroots provides each user with multiple mailboxes (the folders), organized in a hierarchy that is visible to senders.

With many addressable collectors as mailboxes, Grassroots avoids the need for "intelligent filters," etc. at the receiver's side because the incoming information items are not indiscriminately mashed together into one stream in the first place. That is, under a conventional e-mail system, since a user generally has only one mailbox, all the messages addressed to her will flow into it. She then has to read and categorize the mail for processing or storage (possibly with the aid of filters, etc.).

Using Grassroots, both senders and recipients can choose the destination folder to which items will be posted. A recipient can choose the destination by choosing one of his folders and giving its address to potential senders or to some mailing lists. A sender can choose the destination by browsing the recipient's folder hierarchy and choosing the folder that looks most appropriate to post objects to. The sender can also keep a link to that folder and post objects onto that link. When a Grassroots user opens his notifier, all objects are already sorted according to the organization of his collectors.

Figure 5. Grassroots and E-mail.

Figure 6. Grassroots and Newsgroups.

3.1.2 Example: Newsgroups

A folder of Grassroots can take on the role of a conventional newsgroup (Figure 6). This would be the case if people subscribe to a folder and post articles to it. The Grassroots way of having newsgroups has advantages pertaining to ease of creation, access control, enabled competition, and as-needed-only replication.

Light-weight, Decentralized Creation: Note that creating a Grassroots folder by clicking on a button is much easier than running through the process of lobbying with your local system administrator (to create a new UseNet newsgroup) and with 100,000 other system administrators (to carry this new newsgroup at their site). Indeed, a user does not even have to worry about whether a certain topic is worth a wide distribution since creating a folder costs no more than creating a new Web page. This ease of setup enables and encourages the creation of "micro-newsgroups," that is newsgroups of a finer granularity in terms of topic or time of coverage. Of course this advantage is made possible by the new network environment (Internet).

Replication On an As-Needed Basis Only: If we look at the way UseNet replicates news all over the place, we see that this is a good trade-off for the case where a particular item is read everywhere. However, for all other cases, when certain items are not read at certain sites, they are unnecessarily replicated there. Grassroots replicates news to a subscriber's storage only. If a news item is a link to a document (quite common in Grassroots), only the document's address is replicated to the subscriber's storage. The document itself remains in its original server, replicated only to the browser's memory when the link is selected.

Competition: Finally, the ability to set up newsgroup in a decentralized way allows us to have more than one folder with the same topic; these can then compete for popularity. For example, if one newsgroup about a certain topic contains a lot of noise such as low-quality items or the same item repeated multiple times, people can move over to another newsgroup about the same topic (if there is any such other group; if there isn't, there would be reason to set one up).

3.2 Continuous Cooperative Information Gathering and Routing

Grassroots realizes continuous cooperative information gathering and routing. It implements a form of social filtering with an articulated structure that is in contrast to experimental approaches based on comparing feedback statistics.

Information Gathering

Using the subscription mechanism, Grassroots users can create a network for information gathering (Figure 7). When people are gathering information according to each person's interests, everyone profits from this by getting the latest findings from the other people who share the same interest. Grassroots enables such cooperation by letting all users subscribe to each other's folders (unless access restricted); in the larger context, this defines an information gathering network.

Such a network in effect implements a form of social filtering. Recall that even under the same topic different people gather different kinds of information into their collectors. A user can choose which of these collectors best match her interest and subscribe to them. Such a choice essentially filters the information flow. As a result of a subscription, the latest items of other people's collectors will be brought to the subscriber's notifier, where the user can then choose some of the items and accept them into the corresponding collector or disregard others. This choice does further filtering. In this way, subscribers can populate their own collectors and let others subscribe to them. Contrast this with UseNet newsgroups where users form their own combination of subscriptions, but no one else can see or take advantage of this combination.

In Grassroots, the use as a referral network is explicit. Grassroots can make visible who gets information from whom. By following subscription links, one can find people who are working on or interested in a certain topic. Of course the folders that contain the links can be access controlled if needed.

Figure 7. Information Gathering.

Figure 8. Information Routing

Information Routing

The "forward" mechanism can be used as a tool to program a network for information routing (Figure 8). By chaining multiple forwards, one can create an "assembly line" for information objects. Each user on the route can contribute in adjusting a route according to a changing situation.

Comparison to Statistical Systems for Social Filtering

Social filtering in Grassroots contrasts with other social filtering systems such as Tapestry [Goldberg, 1992], GroupLens [Resnick, 1994], etc. (for newsgroups filtering) or any of the "agent" type systems (for instance, Ringo for music recommendations, etc. [Maes, 1994]). These systems take the approach of trying to statistically match users with similar interests, compare their evaluations, and propose items to a user which other users with similar interest considered "good." Such statistical systems effectively try to "compute interest groups".

Grassroots clearly takes a quite different approach there. It makes group and information flow structures visible to cooperative people, who then can understand what kinds of information they are getting from where and what they are missing out on. They can explicitly choose why they might want to do so for specific sources, and they can play what-if games quite easily, that is, they can browse for which kind of information they would get, if they were to create a certain subscription link.

4. User Interface of the Grassroots Prototype

In this section, we describe the user interface of the current prototype of Grassroots. The current Grassroots prototype is an http-proxy based system which allows users to interact using any Web browser. There are no client-side augmentations. For each new user, a Grassroots account has to be set up in advance. This is because Grassroots deals with authentication (and users have to log in initially).

The current implementation is a set of perl scripts running on a Unix CERN http proxy server. This proxy code intercepts browser requests in the usual way. It then either generates a reply when it is a request to the proxy itself, or in the usual other case it will just add a menubar to the top of the page which the user is viewing.

4.1 The Grassroots Menubar

Figure 9 shows an example page with the Grassroots menubar added near the top of the page. The Menubar includes menus such as news, copy this location, etc.

Figure 9. Grassroots Menubar: Screenshots.

The corresponding function of each button is described in Table 4.

Table 4. Grassroots Menubar: Possible Actions.

4.2 Collectors: Folders and Rosters

The user interface of a folder and a roster are shown in Figure 10 and Figure 11. The collector's path name is displayed in a large font at the top of the page. By clicking on any item in this path, the collectors at any level in the hierarchy can be opened. Below the path name, there is a row of buttons whose function is described in Table 5. The same row is also replicated for convenience at the bottom of the page. Though it is not desirable to have buttons in a document, we took this approach as a temporary solution to make the prototype accessible using currently wide-spread browsers.

Figure 10: A Folder: Screenshot

Figure 11: A Roster: Screenshot

Table 5. Collector: Possible Actions.

Notes: 1. Each Grassroots user has a persistent clipboard in the proxy server where the user account is registered. The clipboard can keep multiple items.
2. If nothing is selected, the objects will be pasted at the top. If multiple objects are selected, the top one is considered "the selected object".
3. The objects will appear as the top items of the selected collectors.
4. If nothing is selected, the objects will be posted to the currently open collector. If links to collectors are selected, the objects will be posted to the collectors pointed by these links.
5. Dito. Cf. the footnote for the corresponding paste attribute.
6. Dito. Cf. the footnote for the corresponding paste attribute.
7. Dito. Cf. the footnote for the corresponding paste attribute.

The list of items in a collector are presented between the two rows of buttons. Folders present the list in the following way: At the left end of each line, there is a set of icons that describe the objects according to the scheme shown in Figure 12. Next to the icon is the name of the object (which is also an HTML anchor). If the object is a link, clicking on its name results in jumping to the location. If the object is a collector, it can be opened by clicking on the name. The date and time of the last update are also shown.

Rosters present the list in almost the same way except for links to folders. When a link to a folder is created or pasted into a roster, the user profile of the folder's owner is retrieved. With this user profile, a link to a folder is displayed in the scheme depicted in Figure 11.

Figure 12. User Interface Icons

4.3 The Notifier

An image of a notifier is shown in Figure 13. In each section, the name of the corresponding folder appears on the top and serves as a heading.

Figure 13: Notifier: Screenshot.

Below the folder name, there is a row of buttons whose function is described in Table 6. Below these buttons is the list of objects in this section. The format of the list is similar to the one in the folder. If an item has arrived because of subscription to folder F, the line indicates "news from F". Similarly, if an item has been forwarded from folder F or posted from folder F, the line indicates "forwarded from F" or "message from F" with "F" being an anchor with the URL of folder F.

Table 6. Notifier: Possible Actions.

5. Interaction with External Systems

Grassroots allows a user to have a subscription link to any Web page. All links (HTML anchors) newly added to the page will be brought to the subscriber's notifier. A page consisting of a list of links is a good target for subscription. Subscription to a hypermail archive brings the subscriber new messages that have appeared on the archive page. This effectively allows a user to get on or off the mailing list without bothering its administrator. A page of Yahoo is also a good target for subscription, because it consists of a list of links gathered under one topic.

6. Experimental Feedback

Grassroots has been in experimental use by a small number of users for about three months. We have a number of qualitative observations which we can already point out at this preliminary stage. Overall, testers generally report a very favorable impression. In particular, the uniform way Grassroots deals with notification is highly favored presumably a need filled by a gap created by the absence of anything like this in the current Web. Users report having gained back a sense of control on information inflow; for instance, the ability of resting assured that Grassroots will check events and notify appropriately, for instance, when certain conference information is provided, etc. The uniform notification mechanism especially enables a number of usages which are possible but often not practiced in the current Web. This includes "subscriptions" to on-line newsletters available on the Web.

Since January 1996, a CSCW course in the Computer Science Department of Stanford University, which consists of 30 students, has now been using Grassroots as the main communication medium and as the basis of a virtual community.

7. Conclusion

Grassroots is a system that supports collection-mediated collaboration. It uniformly integrates functionalities from many existing systems such as e-mail, news, and shared hotlists in one simple user-conceptual model.

In particular, we see Grassroots demonstrating a clear need for a uniform mechanism of notification, that is, something which is not available in the current infrastructure including World-Wide Web. Grassroots identifies notification usages and provides a framework for how to understand them. It also shows how a uniform mechanism might be attained in a next-generation version of the World-Wide Web. For example, we can supplant current Web concepts such as its notion of a link with concepts from Grassroots such as its various attributes of links like subscription and forward.

Grassroots can thus be seen as the communication medium of the 21st century.


We would like to express our sincere thanks to all people who helped and gave advice to Grassroots project, used the system as experimental users, encouraged the system development, and inspired the original ideas. Grassroots project has been conducted in conjunction with the Stanford Integrated Digital Libraries Project.


Ackerman, M.S. (1994). Augmenting the Organizational Memory: A Field Study of Answer Garden. Proceedings of Computer-Supported Cooperative Work (CSCW 94), pp. 243-252.

Agre, P. (1995). Community and Democracy. The Network Observer, July. Available at URL

Conklin, E. J. (1992). Capturing Organizational Memory. Groupware `92. Morgan Kaufmann Publishers.

Goldberg, D., Nichols, D., Oki, B.M., and Terry, D. (1992). Using collaborative filtering to weave an information tapestry. Communications of the ACM (Dec. 1992) vol.35, no.12, pp. 61-70.

Kamiya, Kenichi, Martin Röscheisen, and Terry Winograd (1996). Grassroots Home Page. Cf. URL

Resnick, P., Iacovou, N., Suchak, M., Bergstrom, P., and Riedl, J., (1994). GroupLens: An Open Architecture for Collaborative Filtering of Netnews. Proceedings of Computer-Supported Cooperative Work (CSCW 94), pp. 175-186.

Maes, P. (1994). Agents that Reduce Work and Information Overload. Communications of the ACM (Jul. 1994) vol.37, no. 7, pp. 31-40.

Malone, T. W., Lai, K. Y., and Fry, C. (1992). Experiments with Oval: A Radically Tailorable Tool for Cooperative Work. Proceedings of Computer-Supported Cooperative Work(CSCW92), pp. 289-297.

URL-minder. Available at URL

Yahoo. Available at URL

About the authors

Kenichi Kamiya is a master’s student in the Computer Science Department at Stanford University. His interests include Human- Computer Interaction and Database Systems. He has been working for NEC Corporation. As a software engineer, he has participated in development of groupware systems. He holds a BSCS from the University of Tokyo.

Martin Röscheisen is a PhD candidate in Computer Science at Stanford University. His dissertation is on rights management for privacy and intellectual property control, and he has recently been involved in the design of numerous other projects, more information about which can be found at his home page at

Professor Winograd’s focus is on developing the theoretical background and conceptual models for designing human-computer interaction. He is a principal investigator on the Stanford Digital Libraries Project, developing models that can provide information collections and services in an integrated framework from a wide base of heterogeneous distributed materials. He directs the Project on People, Computers, and Design and is developing teaching programs in Human-Computer Interaction Design. Winograd is a founder of Action Technologies, a developer of workflow software, a regular consultant to Interval Research, and on the national board of Computer Professionals for Social Responsibility, of which he is a founding member and past president. He is on the national advisory board of the Association for Software Design and a number of journal editorial boards.