Journal reference: Computer Networks and ISDN Systems, Volume 28, issues 7–11, p. 1157.
http://pcd.stanford.edu
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Figure 9. Grassroots Menubar: Screenshots.
The corresponding function of each button is described in Table 4.
Table 4. Grassroots Menubar: Possible Actions.
Figure 10: A Folder: Screenshot
Figure 11: A Roster: Screenshot
Table 5. Collector: Possible Actions.
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
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.
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.
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.
Acknowledgments
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.
Agre, P. (1995). Community and Democracy. The Network Observer, July. Available at URL http://communication.ucsd.edu/pagre/tno/july-1995.html#community.
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 http://pcd.stanford.edu/Grassroots/.
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 http://www.netmind.com/URL-minder/URL-minder.html
Yahoo. Available at URL http://www.yahoo.com/
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 http://pcd.stanford.edu/rmr/.
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.