@Device[PostScript]
@Make[Report]

@Style[FontFamily Helvetica, size 11]

@Begin[TitlePage]
@Begin[TitleBox]
@MajorHeading[Pygmalion:
A Multi-Media Message System for SIGGRAPH '89
Conference Committee Report]

@Center[Wendy E. Mackay]
@Center[Massachusetts Institute of Technology]
@Center[Digital Equipment Corporation]

@Center[DRAFT of]
@Center[@Value(Filedate)]

@End[TitleBox]
@End[TitlePage]

@PageFooting[Left="Pygmalion Report", Right="@value[page]"]

@comment[Add thanks and citation to Betty Lynch for help with 
logistics ideas and Bob Kraut and company for help with research 
ideas.  Also, to Lester, etc.]

@Section[Introduction]

Pygmalion was conceived at SIGGRAPH '87 by a small group of people
from different parts of MIT.  We found it odd that SIGGRAPH, which
is well known for its state-of-the-art presentation of computer 
graphics, had provided very little in the way of resources for 
attendees to talk to each other.  Inter-attendee communication 
consisted of pink slips of paper on a bulletin board, and information 
about the conference was limited to beautifully produced paper
pieces -- but nothing interactive. 

SIGGRAPH '89 was going to a local conference for us and it seemed to
be the perfect opportunity for us to both solve a problem for
SIGGRAPH, and to work together sharing our different areas of
expertise (user interface design, multi-media communication,
distributed video, distributed workstation computing, and cooperative
work.)  

We made a proposal to the SIGGRAPH '89 committee to create a
multi-media communication system (called Pygmalion) for the
conference.  The idea was to allow users to send individual messages
to each other (as in an electronic mail system) and to provide a
mechanism for handling messages of interest to everyone (an
information database), which would contain information about Boston,
the conference, and information provided by attendees.  Much 
of the underlying software existed, but the section that would 
be presented to attendees would have to be created from scratch.

The SIGGRAPH committee liked the idea but did not provide any funding
for the project.  (We had asked for support after the budgets had been
submitted to ACM.)  So, undaunted, we decided to try to raise the
necessary funding and get equipment donated by various corporations.
We began two parallel tracks of activities: software design and
marketing.  Over a dozen individuals from MIT and Digital contributed
their time over the next six months in both areas.  On June 8,
approximately two months prior to the conference, we cancelled the
project.  We had obtained most of the equipment needed (over 120
workstations, over 30 videodisc players, and various other items),
professional support for the staging, set up and tear down of the
equipment, had most of the software running, and had received
financial contributions for an explanatory brochure and documentation.
Unfortunately, we had lost some key political support in the two key
organizations (Digital and MIT), and found ourselves facing ongoing
political battles just as we needed to concentrate on the technical
and logistics issues.  The situation was frustrating, because none of
the problems were, by themselves, insurmountable.  We simply ran out
of time; and did not feel we could realistically solve all of the
problems prior to the conference.  Since SIGGRAPH was unlikely to move
their conference back a month or so, we decided to cancel the project.

The purpose of this report is to describe what we did, what we we
intended to do, what we learned and what eventually went wrong, in the
hopes that someone will follow our footsteps and create such a system
for some future SIGGRAPH.  I firmly believe that this sort of project, 
with early and clear support from SIGGRAPH and one or two major 
corporate sponsors, is both possible and will have a tremendous 
positive impact on the conference.

@Section[Planning Process]

We began with a brainstorming session on the use of such a system 
at SIGGRAPH.  We talked about our own experiences at the conference
(feeling overwhelmed, having trouble finding people, wanting to 
find out things about the local area, needing a customized way to 
look at the exhibition).  We then discussed how our different 
research interests would contribute to the project.  (For example, 
we had a working distributed video server.  We had designed an 
integrated message system that balances control of messages between 
senders and receivers -- important for protecting conference attendees 
while giving them the greatest possible access to information.  We 
had conducted research on the use of electronic mail, of information 
filtering systems, of multi-media educational environments, and of 
user-controlled video editing.)  We decided to combine these interests 
into a single system, created and customized for SIGGRAPH '89, 
to meet a variety of needs.  

We outlined the basic system in October, 1988, and began to work on
it.  We added new people as necessary and held somewhat irregular
meetings in the beginning to keep each other up to date on our
progress.

I attended the SIGGRAPH '89 committee meetings, which were important
both for meeting the other committee members and in getting advice
from people with relevant experience.  Particularly helpful were the
professional groups contracted for various services, including Graphic
Design, Audio/Visual, Exhibits, Conference Managment, and Services
(such as signs, etc.)  These people had a wealth of experience that
helped us create a realistic proposal that made sense to the
sponsors.

Beginning in February, we held weekly meetings to discuss both
technical and marketing issues.  Some meetings were devoted to special
topics (such as how to schedule video access so that waiting times are
minimized or eliminated), others consisted of reports by each of the
team members.  Separate meetings were held with subgroups to discuss
user interface issues, interfaces between major pieces of software,
development of marketing pieces, and access to sponsors.

@Subsection[Budget]

We did not have an "official" budget for this project and obtained
development resources from our respective jobs at MIT and Digital.
This worked well initially, but soon became a problem because we had
to go through a relatively long process to get donations of equipment
or other resources, some of which were time critical.

If I were doing this project again, I would begin with a full budget
that includes the items that were donated.  The project included time
from over a dozen technical people (approximately 30 person months of
effort), several hundred thousand dollars of equipment, over $60,000
of field service/logistics support, as well as approximately $50,000
for videodiscs and production.  We stopped the project before money
was spent on the latter items, but the project would have cost over
$500,000 had it been brought to completion.  Even with donations, this
was a sizable project.

@Subsection[Logistics]

Someone experienced with tradeshows should be included in the early
stages of the project.  We had many meetings with the technical people
at the Hynes, working out issues with power, telephone (and ethernet)
and video access.  We marked all power sources on the blueprints and
came up with a number of different options for how to arrange the 
equipment.  We also got advice from Digital's tradeshow group and 
the contractors hired by SIGGRAPH.  Some convention centers have 
unions and will not let you do even simple things, such as plugging 
in equipment, yourself.

@begin[enumerate]

@b[Power] Power is expensive and who pays for it should be negotiated
up front.  We found that hallways tended to have limited numbers of 
circuits and extra power would have to be run to put workstations 
into hallways.  Since two workstations take up one circuit, this 
becomes a considerable expense. 

@b[Network]  The network includes telephone, ethernet, and video.
The Hynes has all of these available throughout the exhibtion hall
and the meeting rooms.  A contractor was hired to handle any 
extensions and connectors, but the basic wiring was in place.  This 
can be a major expense if it does not already exist.

@b[Air conditioning] This was provided as part of SIGGRAPH's contract
with the Hynes.  It's another considerable expense if it has to be
negotiated separately.

@b[Kiosk design]  

@b[Kiosk design] We decided to place the workstations in clusters,
both to reduce the number of people required to watch them and to
reduce the amount of waiting in line.  We liked the 4-workstation
clusters that Apple used for their information kiosks at CHI'89. (See
appendix for various designs we considered).


However, since two workstations
use one circuit, it's important to make sure there is sufficient
power.  We were going to try some large clusters (12 workstations) as
well, to see how they would work.  Proposed layouts are included in
the appendix.


@b[Layout] The tradeshow and marketing people wanted the equipment in
the high traffic areas, in and around the exhibition.  They felt that
this would show off their equipment the best.  The people familiar
with SIGGRAPH suggested that they be placed in areas near the papers,
panels, art show and computer graphics theater, to reach the technical
session attendees.  We thought there should be a balance between high
traffic areas (which would probably have lines) and "quiet areas" for
people who wanted to really use the system on a regular basis.  We
also planned to place systems in several committee rooms (student
volunteers, press, SIGGRAPH committee, etc.)

@b[Security] All of the equipment donors wanted to be sure that their
equipment was secure.  They wanted the equipment to be watched at all
times (a tall order for 120 systems) and locked up at night.  We 
were planning to use SIGGRAPH's security, but had been warned that 
this might not be sufficient.
@end[enumerate]


@Subsection[Fund Raising]

We decided to raise money by charging for "video ads".  A small local
video production firm volunteered to provide professionally produced
video ads for vendors at the conference.  They benefited from the
exposure to future potential customers and it provided a useful source
of revenue to cover videodisc production and other small hidden
expenses.  We felt that providing video production services at the
conference was important for two reasons: it demonstrated the power of
the video-based message system, which can handle up-to-the-minute
information, and did not require the exhibitors to pay for professional 
video production services for a "commercial".  We had decided to 
charge $1,000 for the service of adding 30 seconds of video and 
help in the design of a message.  Most people considered this 
inexpensive, but we did not have the opportunity to find out 
how many people actually would have paid this amount.  (The 
cost of pressing a 30 minute videodisc is approximately $2,000, 
so the breakeven point would have been two messages.  The idea
was to fill the videodiscs with other SIGGRAPH-based information 
from the Computer Graphics Theater, the Art Show, and other sources.)

We also asked for money from different vendors.  Asking for funding 
for a specific project (e.g. creating the brochure with the 
user documentation) worked much better than asking for general 
support.  

Most importantly, we asked for large quantities of equipment.  For our
own sanity, we decided to try to get most of the equipment from a few
major vendors rather than trying to get small amounts from many
different vendors.  This was important both to simplify logistics and
also to reduce the time spent fundraising.  However, very few vendors
will be able to supply all of the equipment required for a project
this size.  IBM and Digital are large enough.  Perhaps Apple and HP
are as well.  Smaller companies are unlikely to be able to produce the
required number of systems.  (We had a modem vendor who initially
promised us 20 modems and then backed out, because they could not pull
that many from inventory.)  However, we wanted the system to be
multi-vendor, so we created different roles for systems and asked for
equipment that way.  Thus, we asked for (and received) 120
workstations from DEC, but also went to Sun and Parallax for a smaller
number of video workstations.  It seemed that vendors were most
interested in talking to us immediately after NCGA -- although giving
them plenty of advance warning (especially in small companies) was
appreciated.

@Subsection[Specifications and Documentation]

We wrote numerous documents in the course of this project.  The 
first was a one-page executive summary and a 3-page proposal 
that described the project.  We used this for everything in the 
beginning -- getting technical volunteers, talking to the 
SIGGRAPH committee, talking to potential sponsors.  

As the project became more solid, various other documents were
created.  We created several technical specifications: the overall
architecture spec, the Galatea video server spec, and the user
interface specification.  The Architecture spec was designed as a
working document to describe the various components of the system and
identify potential holes.  The other two large pieces of code had
their own specs, which provided greater detail.  We also created
storyboards of the use of the system, including screens that users
would see and descriptions of the different kinds of functionality.

We held a marketing brainstorming session (which should have been done
earlier than February) which focused our attention on what we believed
were the most important parts of the project.  This provided the basis
for our internal marketing plan.  We used it both to help us
prioritize our activities and also to help us present the project to
different audiences.  From the marketing plan came two important
external pieces: the sponsor's package and the attendee brochure.

I contacted every sponsor by telephone.  Every one who offered us
support asked for a description of the project and a specific
proposal.  Rather than creating separate proposals for each, we
designed a sponsor's package that included: executive summary,
Pygmalion overview, outline of the benefits of sponsorship, SIGGRAPH
description, the schedule, and the Pygmalion technical specification,
the design teams' credentials and a SIGGRAPH brochure.  The piece was
continuously updated and sent with a cover letter that referred 
to the phone call and asked for a specific donation.  This piece 
was also helpful for the public relations group, to help them 
understand what Pygmalion was all about.

The attendee brochure was going to be included with every registration
package.  The goal was to describe Pygmalion, set expectations,
provide a quick reference guide and provide enough information so that
even people who were unable to use it would understand what it was.
We planned to produce 35,000 of them, with the extras to be used 
at the 120 workstations around the conference center and to be 
given to the press.  (The graphic design and writing was donated; 
the budget for production was approximately $10,000, which was 
donated by Digital.)

@Section[Managing Risks]

We knew this was going to be a high-risk/high-payoff project, so we 
tried to manage the risks in several ways.  We chose a "go/no go"
date, and held off spending our sponsors' money until we were 
confident that we could proceed.  The date was chosen to be 2 months 
before SIGGRAPH, primarily because of publishing deadlines (the 
attendee brochure and final program).

We designed "Pygmie" (the small version of Pygmalion) as a backup, in
case we could not obtain all of the necessary equipment.  Pymie
required only 20 workstations and was a complete subset of the
proposed software.  (The "complete subset" part is important.  The 
programmers did not have to change their specifications at all,
but were able to prioritize their work so that the Pygmie version 
would be completed first, then the full version.)

I was concerned about setting expectations properly.  I didn't want
people to evaluate Pygmalion as a product and be disappointed.  I
wanted them to view it as a risky experiment that accomplished far
more than anyone expected.  I purposely billed it as an an
@i[experiment] in multi-media communication, and tried hard to resist
efforts to oversell it.  (The latter proved somewhat difficult, as
people, eager to help, sent out glowing descriptions of it.)  The 
sponsors appreciated this approach as well, since it fit well 
with SIGGRAPH's reputation as being a place for daring new 
experiments.

Initially, I was prepared to use the team of volunteers to set up the
equipment at the Hynes.  (These are bright MIT students and graduates
with experience in setting up and maintaining a network of 900
workstations for MIT's project Athena.)  However, I was convinced by
the people with years of tradeshow experience that setting up and
maintaining equipment of this type is a specialized skill that should
be handled by experts.  This was an unexpected cost, but turned out to
be essential in obtaining equipment donations.  The vendors wanted to
know that their equipment was going to be handled in a professional
manner and someone with insurance was formally responsible for
problems.

@Section[Design Considerations]

Unfortunately, I can't provide data that proves that our design 
decisions were correct.  However, I hope that almost a year of
design review meetings by a talented, diverse group with experience 
in distributed computing, interactive video, information design, 
electronic communication and user interface design will not go 
to waste.

@Subsection[User Protection] 

We wanted to provide a mail system, to enable users exchange private
information.  However, mail systems are often abused, because it is
equally easy to send a message to everyone as one person.  So we
designed Pygmalion to permit person-to-person communication, but to
restrict person-to-everyone communication.  If the author of a message
wants to make it available to everyone at SIGGRAPH, the author is
asked to annotate the message (to make it easier for others to find)
and send it to a central database.  Other people can then browse
through the database to find what they are looking for.  Another
advantage is that only one copy of each message is necessary.

@Subsection[Video]

We felt that video (or at least still images) are important for
SIGGRAPH.  We wanted to allow people to see the visual parts of
SIGGRAPH and also to contribute their own.  Thus, we planned to have
still video and text available on all workstations, with moving video
available on a small number of workstations.  (This technology is
still relatively unstable -- perhaps in future years it will be easier
to obtain more workstations with live video.)

@Subsection[Simple editing]  

We restricted the functions of Pygmalion to make it easier for people
to learn.  We calculated that the average user would be able to use it
for a total of 15 minutes during the conference (perhaps in three
five-minute sessions, perhaps in one 15-minute session).  Clearly,
some users would have much more access, and some would not use it at
all, but it was important to make the design simple enough that 5
minutes of experience was sufficient to send and receive messages.

@Subsection[Message board]  

We decided to keep the message board for several reasons.  First, if
the system broke down or was inaccessible, paper is a good backup.
Second, some people don't like to have to deal with technology.
Third, we wanted to compare usage.  We had arranged that telephone
messages would be posted both on the message board and entered into
Pygmalion.  We discussed the idea that people could have their text
messages entered as well.  @end[enumerate]

@Subsection[No passwords]  

After much agonizing, we chose to eliminate passwords
and let users identify themselves with a name and an affiliation.  We
wanted to make it absolutely clear that Pygmalion was no more secure
than the notes on the message board.  If a person wanted to masquerade
as another user, he or she would have to do it explicitly.  We 
were prepared to give passwords to committee members, exhibitors, 
and VIPs who might prefer a protected account.

@Subsection[Research]

We had intended to videotape use of the system and analyze the on-line
usage data.  We obtained permission first from SIGGRAPH, and then from
MIT's human subject's committee.  (The latter took almost six months
and several iterations.)  By not using passwords, we addressed one of 
the major concerns of the human subjects committee, which was that 
we would not report data about individuals.  Since we did not 
know that any person was really that person, we did not 

@Section[Advice]

I suppose my main piece of advice is to be sure that there is at 
least one high-level person who is willing to take some heat for 
a project of this magnitude.  We were careful to inform everyone 
about what we were doing, but when I made a change from one 
group to another at MIT, I did not anticipate the reaction until 
it was too late.  One needs a sponsor who asks "what can I do 
to buffer you and what resources are you having trouble with?".
Without that, the project will be subject to endless rounds of 
justification and rejustification, which takes valuable time 
away from the actual running of the project.

The project was always extremely ambitious and risky.  We were 
careful to have several levels of backup plans for the technical 
end of things.  (For example, there was the "Pygmie" version, 
which consisted of 20 workstations and would have been simply 
an information system, rather than a full-fledged message system.)

We needed full support from SIGGRAPH earlier.  While they were 
very helpful, the project was always treated as something that 
could be eliminated, and thus it was difficult to make final 
plans for layout of the equipment at the conference center, etc.
For a project of this size, it is very important to get the 
logistics worked out as early as possible.

Digital had offered to stage all of the equipment in one of its
staging facilities, even equipment from other vendors.  I don't
believe it would really be possible to put all of this together for
the first time at the conference, given the participation of different
vendors.  This raises a tricky issue though.  Video vendors, who have
an on-going relationship with Digital, were happy to have their
equipment staged on Digital property.  It is not clear that competing
computer vendors would have been willing to do this.  (This was 
an unresolved issue.)

We were running late on the user interface software.  Although we had
a demo running in May, with some limited user testing, we really
should have had it available earlier for rigorous testing.  Previous
experience with product development (and observation of both
successful and unsucessful information systems at other conferences)
says that you simply can't predict everything.  MIT has a facility
with six video workstations and other facilities with large numbers of
non-video workstations.  We had planned to bring in people to test
both the user interface and also what the system looks like when
loaded.  I don't think I'd try a project of this size without a
similar environment for user testing.

Finally, while I am very disappointed that we were not able to 
bring this project all the way to SIGGRAPH, I feel that we made 
a great deal of progress and that the time is almost ripe to 
try this.  For us, the project timing was ideal (the right combination 
of people, location, and potential sponsors).  Perhaps it will 
work out for someone else next year or after that.

@Section[Appendix]

This appendix includes the various documents that were produced for
Pygmalion.  Note how things changed from the first proposal.  Since
these were working documents, what you see here is the state they were
in when the project was terminated.  There are some inconsistencies, 
some of which had been resolved and others of which were still 
under discussion.

@begin[enumerate]
Proposal to SIGGRAPH '89 Committee

Committee reports

Sponsor's Package

Brochure Design

Architecture Specification

Galatea Video Server Specification

User Interface Specification
@end[enumerate]
