BABYL OPTIONS: Version: 5 Labels: Note: This is the header of an rmail file. Note: If you are seeing it in rmail, Note: it means the file has no messages in it.  0,unseen,,, Summary-line: 4-Sep jbs%WONKO.MIT.EDU%eddie.M #dialup Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/k) id AA02023; Sun, 4 Sep 88 15:51:49 EDT Received: by cayuga.cs.rochester.edu (5.52/k) id AA11634; Sun, 4 Sep 88 15:51:15 EDT Received: by WONKO.MIT.EDU (5.54/1.2a) id AA13842; Sun, 4 Sep 88 15:49:30 EDT Date: Sun, 4 Sep 88 15:49:30 EDT From: jbs%WONKO.MIT.EDU%eddie.MIT.EDU@eddie.mit.edu (Jeff Siegal) Message-Id: <8809041949.AA13842@WONKO.MIT.EDU> To: mintz@CS.ROCHESTER.EDU Subject: dialup The machine is DIALUP.MIT.EDU [18.80.0.9] It is running the old release (5.5T), so you probably can't compile everything there (X Toolkit stuff, in particular), but you can log in and do most other things. Jeff  0,unseen,,, Summary-line: 6-Sep mackay@ATHENA.MIT.EDU #IF YOU GET IN EARLY... Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/k) id AA23044; Tue, 6 Sep 88 05:42:50 EDT Received: by cayuga.cs.rochester.edu (5.52/k) id AA04159; Tue, 6 Sep 88 05:42:10 EDT From: mackay@ATHENA.MIT.EDU Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29105; Tue, 6 Sep 88 05:42:09 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA09575; Tue, 6 Sep 88 05:41:28 EDT Message-Id: <8809060941.AA09575@E40-368-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: IF YOU GET IN EARLY... Date: Tue, 06 Sep 88 05:41:25 EDT please send me comments ASAP. It goes to Howard Tuesday afternoon. ============================================================================ Proposal for Athena Lens, Phase II Wendy E. Mackay 6 September 1988 ============================================================================ The Athena Lens group has successfully delivered a working prototype of the Information Lens, written in C under Unix and X. We held a series of design review meetings throughout the summer to help transfer what we learned to Digital engineers and to obtain their advice. Other Digital Engineers are following our progress via electronic mail. We feel we have successfully met the goals of phase I of the project, and would like to propose continued funding for phase II. This proposal explains what we did, what we learned from it, what we plan to do, the anticipated benefits for BOSE and the proposed budget. I. WHAT WE DID The functional specification and preliminary documentation provide a detailed account of the technical and user interface aspects of the project. What follows are the highlights: TECHNICAL ISSUES: Athena Lens uses modules, objects, and resources. Modules include the various Athena Lens editors (rules, rule sets, message types, etc.), the rule runner command, parsers, and data collection. Objects are handled by modules and include messages, rules, rule sets, message types, data etc. Resources are used by everyone and include registries, folders, files, message syntax, and user interface guidelines. The rule editor, rule runner, registries for verbs, simple message types, and fields, message objects, a rule language, predicates and actions were all identified as top priority. Extensibility was an important part of the design. Thus, many extra functions can be added easily, even though they were not included in phase I. 1. Managing scale issues. The original Lens was designed for and tested on a small, homogeneous work group. An important goal of Athena Lens was to address the technical problems associated with handling large organizations and cross-organizational boundaries. Message types are organized into registries which are owned by different organizational units (of any size). Individual users have registries that keep track of the relevant message type registries (including their own). This permits Lens to scale across organizational boundaries. 2. Expanded number of mail handlers: Lens was designed for a single mail system in a LISP environment. Athena Lens was designed to work with a number of different mail handlers, both to significantly increase its potential audience and to test the generality of the Lens ideas. The folder object was designed to be easily modifiable to handle radically different mail handlers (currently mh and Xmh, and soon rmail). The design will permit future extensions into voice mail, Fax and graphics. 3. Default settings: Athena Lens provides a system of defaults for all programs, beginning with system-wide defaults. Users can create their own preferred sets of defaults in their home directories, and they can further specify changes in defaults when individual programs are called. USER INTERFACE ISSUES: 1. Multiple rulesets with different triggers: The best method for handling a message changes over time, depending on a number of variables. Athena Lens accommodates this by letting users run sets of rules at different times, based on different triggers. Users can have prioritizing rule sets for handling incoming mail, reminder rule sets for outgoing mail, and "cleanup" rulesets for archiving mail or users can specify their own triggers. 2. Rule editing: Athena Lens provides a simple, visual interface for creating rules (similar to filling out a mail message). Lens provides a large number of possible actions, including: move, copy, delete, set and modify user-created properties, react to states of the message (such as number of lines), run arbitrary programs or run other rulesets. User properties are very flexible and can enhance the operation of other rulesets. Fields can be of different types, including strings, combinations of strings (e.g. AND), a sophisticated date parser and integers. 3. Flexible Message types: Athena Lens allows users to easily create new message types, simply by adding new fields to messages. (One program provides a menu of all the available message types specified in the user's registry of message type registries.) The rule editor displays the possible message types and allows users to change message types while editing a rule. We expect that this flexibility will prove useful to groups with constantly changing communication needs or those moving through different phases of a project. USER TESTING: Athena Lens has an extensive data collection facility, which is available both to users (for monitoring their own use of mail), and to researchers (to use with permission). Different kinds of data can be collected separately, including messages sent and received, rule creation history, rule firing history and message types. All data collection is independent of the mail system chosen. II. WHAT WE LEARNED The group made remarkable progress over the summer, learning the X Window system, the X toolkit, and the Athena networked workstation environment. The toolkit work was much slower than anticipated, for a number of reasons. First, all of the available toolkits were very buggy. Much of the groups' effort was spent in debugging the Athena and HP widget sets and sending over 100 pages of bugs back to their authors. Second, the toolkit metaphors are not as simple as advertised. Widgets are almost objects, but not quite, which makes it more difficult than if they were completely objects or not at all. A number of assumptions made by the original Lens group weren't possible with Athena Lens. For example, we needed to create an intermediate rule language that both ran quickly and yet was easy to parse by the rule editor. Rather than use LISP, we created a post-fix language that is also readable and changeable by users, if desired. The group had to handle some very difficult data and memory management problems and so we created standard structures for passing information from one module to another. Darrays provided useful data access capabilities and storage that everyone can use. Individuals did not have to reinvent tools for these tasks for their own internal code and were able to save time and increase overall efficiency. A more difficult problem, which has not been entirely solved, has been to create conventions for deciding which modules create, modify and destroy shared blocks of memory. Cross-module conventions are needed to allow individual programs to work together. In general, user interface issues have proven to be difficult. An early version of the rule editor was designed to allow users to link different fields with AND's and OR's, using a variation of the Boxer language developed at MIT. Many issues arose as to how to make it clear how to create complex rules without interfering with the creation of simple rules. Data collection proved both more difficult and more interesting that originally anticipated. The design of a consistent way of collecting data (and similarly, a consistent way of handling errors), caused better design decisions in the code, with greater modularity. The Digital engineers raised the issue of the X.400 standard. The concepts of Lens fit within the standard as it is currently defined, but it may be better to investigate how Lens issues may influence the standard. III. WHAT WE'D LIKE TO DO NEXT We have a simple version of Athena Lens with many hooks to extend it in interesting ways. We would like to find one or two projects that will have a significant impact on Athena, both to encourage its widespread use and to provide us with experience with a large group of users. To accomplish this, we propose enhancements in the following areas: TECHNICAL ENHANCEMENTS: 1. Anyone server. Athena currently has a problem (shared by many large organizations), in which messages are copied to large distribution lists. Athena Lens can provide an alternative by allowing users to write rules to select interesting messages and send them to the "anyone" server. The anyone server can receive all of the mail addressed to these distribution lists and send out pointers to them. (The messages will usually be stored in a database.) Lens is especially appropriate because Athena has a number of different conferencing and mail systems, so a very flexible solution is required. 2. On-Line Consulting. Athena has students and paid staff who answer questions from Athena users. Lens could provide a mechanism for keeping track of different kinds of messages and sending them to the appropriate consultant. USER INTERFACE ENHANCEMENTS: 1. XUI. It is important that we work with a solid toolkit. It is also beneficial for DEC that the toolkit be DECWindows. We plan to use XUI and rewrite the rule editor, rule set editor and message type editor with it. We will provide extensive comments and bug reports as necessary. 2. Complex rule editor. We would like to implement a visual rule editor that allows users the full functionality of the text-based rule language. We have outlined a scheme based on a system called Boxer that we'd like to implement and test with users. 3. Message type editor. We would like to create a message type editor to make it easier for users to create and register a range of message types. USER TESTING: 1. Small group test. While the above enhancements are taking place, we would like to systematically test the use of the existing version of Athena Lens on a group of volunteers from the Athena staff. We plan to listen to their suggestions to increase the usability of the user interface. 2. Large group test. If all goes well with the enhancements, we would like to test Athena Lens with one or more large groups of users. Current possibilities include the full Athena staff and the department of Electrical Engineering. We would like to take advantage of the data collection routines and analyze the use of Athena Lens over a number of months. TECHNOLOGY TRANSFER: We plan to continue to hold design review meetings for individuals from Digital, Athena and Sloan. We will provide bi-weekly updates for people on our Email interest list. Wendy will continue to manage the project and Tom Malone, Dan Geer and George Champine will continue to provide consulting and support. The final deliverables for the project will be: 1. Working prototypes and documenatation of the rule runner, anyone server, extended rule editor and message type editor, 2. Preliminary data and analysis of use by several groups of users, and 3. Transfer of the underlying software architecture and user-system dialogues into BOSE. IV. BENEFITS TO BOSE BOSE has already invested in the training of these three students and the development of a working, extensible prototype. As a result, BOSE is now uniquely positioned to test the concept of intelligent filtering ideas with large groups of users across organizational boundaries. The project will provide a rigorous test of the DECWindows toolkit software and provide early identification of problems. With the completion of phase II of the Athena Lens project, we believe that Digital will be in a unique position to build intelligent filtering features into its mail products. V. WHAT IT WILL COST The three students funded by Digital will be able to continue working on the project part-time throughout the school year. The following budget assumes that the project will continue from the September 2, 1988 completion date and continue through May 15, 1989, excluding holidays. It is assumed that students will work 20 hours per week during the semester and full time during January (MIT's interim activities period). These students have already worked in the Athena environment, so the following budget does not assume a learning curve. BUDGET: At current rates for 20 hours per week the maximum cost will be $26,000. This assumes that students will not be paid for holidays and vacation. If students take more than two weeks of vacation or study time, or decide to work less than full time in January, the cost will be correspondingly less. Wendy's time and the time of the other advisors, as well as equipment, office and other overhead costs, will continue to be provided at no cost to BOSE.  0,unseen,,, Summary-line: ?????? UPSH003%FRORS31.BITNET@CU #reply Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/k) id AA02765; Tue, 20 Sep 88 08:48:16 EDT Received: by cayuga.cs.rochester.edu (5.52/k) id AA06489; Tue, 20 Sep 88 08:48:08 EDT Message-Id: <8809201248.AA06489@cayuga.cs.rochester.edu> Received: from FRORS31.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 0284; Tue, 20 Sep 88 04:23:57 EDT Date: 09/20/88 09:51:22 To: mintz@cs.rochester.EDU From: UPSH003%FRORS31.BITNET@CUNYVM.CUNY.EDU Comment: CROSSNET mail via SMTP@INTERBIT Return-Receipt-To: UPSH003%FRORS31@vm.cc.rochester.edu Subject: reply to: Toby Mintz from: Jacques Mehler I would be very happy to have you in my lab next year. I suggest you propose me a project so I can react. Best wishes, Jacques Mehler  0,unseen,,, Summary-line: ?????? UPSH003%FRORS31.BITNET@CU #possible project Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/k) id AA23157; Mon, 26 Sep 88 12:02:36 EDT Received: from [128.228.1.2] by cayuga.cs.rochester.edu (5.59/k) id AA12588; Mon, 26 Sep 88 11:18:08 EDT Message-Id: <8809261518.AA12588@cayuga.cs.rochester.edu> Received: from FRORS31.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3281; Mon, 26 Sep 88 11:16:25 EDT Date: 09/26/88 16:10:38 To: mintz@cs.rochester.EDU From: UPSH003%FRORS31.BITNET@CUNYVM.CUNY.EDU Comment: CROSSNET mail via SMTP@INTERBIT Return-Receipt-To: UPSH003%FRORS31@vm.cc.rochester.edu Subject: possible project to: Toby Mintz from: Jacques Mehler Your project looks fine to me. Best wishes, Jacques  0,unseen,,, Summary-line: 11-Oct mackay@ATHENA.MIT.EDU #Re: Hi. Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/k) id AA22703; Tue, 11 Oct 88 00:11:37 EDT Received: from ATHENA.MIT.EDU by cayuga.cs.rochester.edu (5.59/k) id AA13840; Tue, 11 Oct 88 00:11:20 EDT From: mackay@ATHENA.MIT.EDU Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23161; Tue, 11 Oct 88 00:11:38 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA06835; Tue, 11 Oct 88 00:10:47 EDT Message-Id: <8810110410.AA06835@E40-368-1.MIT.EDU> To: mintz@cs.rochester.edu Subject: Re: Hi. In-Reply-To: Your message of Wed, 05 Oct 88 13:02:35 -0400. <8810051702.AA09100@hemlock.cs.rochester.edu> Date: Tue, 11 Oct 88 00:10:45 EDT Thought you might be interested in this, once you recover... (Your name is even in it, as a programmer of Athena Lens.) W ================ PROPOSAL FOR A RULE-BASED MULTI-MEDIA MESSAGE SYSTEM FOR SIGGRAPH '89 Wendy E. Mackay 10 October 1988 SIGGRAPH is not only a place to see the latest in computer graphics; it's also a wonderful opportunity for people to meet and talk to each other. The problem, of course, is that with 30,000 people, it's very hard for people to find each other; especially if they don't even know each other. Past SIGGRAPH conferences have provided highly sophisticated multi-media displays for speakers, but relegate inter-attendee communication to an out-of-the-way bulletin board filled with pink slips of paper. We need a better way for them to communicate. We would like to work with the SIGGRAPH '89 Conference Committee and industrial sponsors to develop a state-of-the-art rule-based multi-media message system for participants at the conference. We envision the following: - Everyone will be able to write personal messages to each other, containing text, graphics and a limited amount of video. - Organizers of special events will be able to create multi-media messages of interest to a subset of attendees. - Vendors and job seekers will be able to submit pre-recorded multi-media messages prior to the conference. At the conference, attendees will be able to: - Receive personally addressed messages containing text, graphics and video, - Subscribe to special interest distribution lists, - Write simple rules to identify and receive interesting messages from a pool of public messages, and - Record useful messages on 1/2" videotape to take home. Information kiosks will be available throughout the exhibition hall, main meeting rooms and at conference hotels. The most common will have monochrome workstations that support text, graphics and still video images. Users will be able to create and read mail messages, ask for directions to get around Boston, and find out information about the conference. SIGGRAPH cards will serve as identification. 15 special kiosks will be set up in the exhibition hall to handle all of the above as well as display messages containing full motion video and record them on 1/2" videotape. In three vendor booths, users will be able to do all of the above as well as record, edit and send messages containing video. Attendees will be able to find out that they have new mail whenever they enter the exhibition hall or paper sessions (e.g. "Wendy Mackay. You have 3 new messages.") or by looking at video monitors with scrolling lists of people with new messages. What we can offer Most of the necessary software for this system exists in prototype form. The basis for the system is the Athena Information Lens project, a non-proprietary Unix/X Windows application that works with the mh mail system. Key concepts include the ability to write rules that filter electronic mail messages and the ability to create "semi-structured" messages which increase the usefulness of those rules, by adding additional message fields (Malone et. al, 1987). Previous versions of Lens have been extensively tested for ease of use (Mackay, 1988). We have received funding for the current academic year to extend and test Athena Lens with users at MIT. One extension will allow users to send messages of general interest to "anyone". Other users can then see these messages by sending rules to the "anyone server". Another extension will combine Lens with our work in interactive video and handle multi-media messages, including voice, video and animation. In context of SIGGRAPH, this means that users will be able to specify the subjects or topics of primary interest to them at at the conference. Vendors will be able explain their products with multi-media messages, job seekers will be able to display their portfolios, party-givers will be able to create invitations with maps, and SIG and BOF groups will be able to solicit participation from new members. Project Participants 1. Project Management: (Wendy Mackay) Work with industrial sponsors and the SIGGRAPH '89 Conference Committee. Supervise software development team: a. Athena Lens: (Brian Gardener, Toby Mintz, Rich Pito, Jeff Siegal) Edit message types, rulesets, and rules that filter and process electronic mail. b. Video Editor: (Brian Michon, Evelyn Schlusselberg) Record and edit video segments of messages. c. Video Mail: (Brian Gardner, Brian Michon) Create and edit messages containing text, graphics, animation, voice and video. Create rules for filtering multi-media messages. d. Boston Directions: (Jim Davis, Mark Ackerman) Provide text directions between any two points in the Boston area, with appropriately scaled maps and video from the Rotch visual collection. e. Galatea Network Video Server: (Daniel Applebaum) Provide computer- controlled access to a video network and a bank of videodisc players. f. Database: (Mark Ackerman, Rob French) Provide storage and retrieval of general interest messages, maps and conference information. 2. System Management: (Win Treese) Provide the network and underlying Unix integration of the various programs. 3. Technical Consultation: Dr. Lester Ludwig (BellCore), Dr. Sara Bly (Xerox PARC), Dr. Phil Gust (HP Labs), Professor Tom Malone (MIT), Professor Andy Lippman (MIT), Dr. Dany Guindi (Georgia Tech), Dr. George Champine (Digital Equipment Corporation), Dr. Nathaniel Borenstein (Carnegie-Mellon). 4. SIGGRAPH '89 Committee: We will need to coordinate our activities with the Local Arrangements Chair, the Registration Chair, and the Video Chair. 5. Vendors: We need extensive support from Digital, as well as video, network, modem, and other equipment manufacturers. Resources Required SIGGRAPH '89 is a large, distributed conference with over 30,000 attendees. We must work through the logistics issues now and obtain significant support from industry sponsors to make this work. We would like to work with Digital, because our software runs on their equipment and they have experience setting up a mail network for 50,000 attendees at DECWorld '87. We must also identify a sponsor for assistence with the video equipment. Our design requires a standard computer network, a videodisc switching network (Applebaum, 1988) with a bank of videodisc players, and three classes of workstations: - 100 Class I monochrome microVAX II workstations distributed throughout the main conference area and at conference hotels. Remote workstations will be connected via 9600 baud modems. - 15 Class II color microVAX II workstations with parallax video boards or separate video monitors and a 1/2" videotape recorder connected to the videodisc switching network. - 3 Class III color microVAX II workstations with parallax video boards, two video cameras, and a write-once videodisk player, connected to the videodisc switching network. The numbers of workstations are negotiable and are limited primarily by hardware resources. We will need acceptable strategies for limiting access to scarce resources, particularly the video workstations. Options include: video message quotas, restricted audiences (e.g. technical session attendees), and access time limits for video workstations. We are interested in suggestions from the Conference committee on how best to resolve this issue. Prior to the conference: We must arrange for equipment donations from sponsors to develop, test and integrate the system at MIT and to provide sufficient numbers of workstations at the conference. It is essential that we have at least a 4-month fieldtest of the system at MIT. The field test will include three groups at MIT: Project Athena, the Media Lab and the Center for Coordination Studies. Project Athena has class I, II, and III workstations, but the others will need additional hardware, including video boards, cable TV links, video switching hardware, additional videodisc players, and a small budget for videodisc production. We would also like help with funding for students to customize the software for SIGGRAPH and to integrate our system with SIGGRAPH's registration and card system. Conference setup: We need both equipment and time from vendors to set up the workstations and network. We will need help from SIGGRAPH or a vendor to build the kiosks. During the conference: We will need student volunteers to help with the maintenance of the system and answer questions. Again, coordination with SIGGRAPH's local arrangements chair and video chair will be essential. Proposed Schedule October: Present proposal to SIGGRAPH '89 committee. Request resource commitments from vendors and other participating groups. November: Provide a detailed budget/resource request to SIGGRAPH '89 committee. Request resource commitments from vendors. Field trip to Hynes auditorium. December: Install network hardware at MIT and begin integration work. January: Test videomail with initial set of users. Create applications for Athena (registration program) which will be converted for Conference. February: Begin large-scale user testing of text-only version of Athena Lens and the anyone server. Begin low-volume testing of video mail. March: Begin coordination with SIGGRAPH '89 conference software. Begin conference information applications. April: Begin large-scale testing of Videomail. Demonstrate limited version at CHI '89. May: Videomail field test. Work out logistics issues with Local Arrangements Chair. June: Videomail field test. July: Videomail field test. Software freeze. Installation of system at Conference. Biography I have over 5 years of experience managing $2 million dollar budgets, have built and managed a software development group (2 supervisors, with 33 developers who produced 35 separate software products, shipped on time and under budget in a period of less than 3 years) and created an R&D group (3 supervisors, 18 researchers who produced software that reduced the cost of multi-media software development to 1/5 of previous costs with a significant increase in user satisfaction.) I managed video for the CHI '86 conference which was held at the Westin and Marriott hotels in Copley Place. I am a Digital employee currently working at MIT full-time on my Ph.D. in Management of Technological Innovation. I am managing the Athena Lens project and work with the Visual Courseware Group at Project Athena. The project team consists of MIT students, Digital employees assigned to MIT and MIT employees. They include: Mark Ackerman (MIT, Ph.D. candidate), Dan Applebaum (MIT undergraduate), Kevin Crowston (MIT, Ph.D. candidate), Rob French (MIT undergraduate, DEC staff), Brian Gardner (MIT, Ph.D. candidate, DEC staff), Brian Michon (DEC staff), Rich Pito (BU undergraduate, DEC staff), Evelyn Schlusselberg (MIT staff), Jeff Siegal (MIT undergraduate, DEC staff), Win Treese (DEC staff).  0,unseen,,, Summary-line: ?????? UPSH003%FRORS31.BITNET@CU #application Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/k) id AA05714; Thu, 20 Oct 88 06:03:29 EDT Received: from cunyvm.cuny.edu by cayuga.cs.rochester.edu (5.59/k) id AA11550; Thu, 20 Oct 88 06:03:23 EDT Message-Id: <8810201003.AA11550@cayuga.cs.rochester.edu> Received: from FRORS31.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 2445; Thu, 20 Oct 88 06:02:57 EDT Date: 10/20/88 11:01:21 To: mintz@cs.rochester.EDU From: UPSH003%FRORS31.BITNET@CUNYVM.CUNY.EDU Comment: CROSSNET mail via SMTP@INTERBIT Return-Receipt-To: UPSH003%FRORS31@vm.cc.rochester.edu Subject: application to: Toby Mintz from: Susana Franck Your Fulbright application forms arrived, have been completed and returned. I trust they arrive OK the Mails here are more or less on strike.