|
|
This design briefing describes the design and development of a demonstration which simultaneously utilizes and illustrates the use of SunSoft's distributed object technology, NEO. The design is notable in that the demo is primarily a marketing tool, not a product. We discuss the factors that made the NEO demo different from a typical project, and how we created a successful user experience through the visual design and story of the NEO demo.
Human interface design, objects, NEO, NeXT, demonstration, presentation, visual language, storyboards, graphic design, theatre.
In 1991, SunSoft began working on an application framework called NEO (Network Enterprise Objects). The intent of NEO is to provide customers with an object-oriented technology that will enable developers to construct applications using distributed, reusable components.
In 1993, SunSoft purchased existing software technology from the NeXT Corporation. The NeXTStep environment is being evolved into OpenStep.
As part of the marketing effort for NEO, an engineering team called DOVE (Distributed Objects Vision Engineering) was created. The focus of the team is to create demonstration applications which simultaneously utilize and illustrate distributed object technology. The demo is used by NEO upper management in various public forums to present a packaged vision of the development possibilities available with NEO objects.
The audience for the NEO demo included a broad collection of developers, business people, analysts, and press. Each segment of the audience needed the demo to be convincing. In addition to being credible from a technical and business perspective, the demo had to have high production values and a dramatic impact on the audience. We wanted to capture the audience's interest and impress them with a quality presentation.
This interface was quite a departure from the usual projects we work on at SunSoft. The most obvious difference was that the NEO demo (as we will refer to the project) was not a product and did not have a typical product schedule. The schedule was heavily tied into marketing events, most notably the product announcement.
The interface had to illustrate the advantages of a technology under construction, while presenting something exciting and valuable to the audience, yet not give a false impression of the future product's capabilities. We knew that reality would not be as important as perception in the presentation. As Brenda Laurel writes, "The magic is created by both people and machines, but who, what, and where they are do not matter to the audience." [1]
Finally, the project had a significant level of involvement from NEO upper management. While all projects have some management involvement, on this project, management had to feel comfortable with the presentation scenario, as they would be presenting it often and using it to promote the NEO technologies.
The project had two main goals: to show examples of certain key technologies through the content of the demo and to reflect the process of building applications with NEO technology. Since this was not a hands-on demo, we were not necessarily concerned with total fidelity to usability. Instead, a key goal of the project was to present a theatrical experience for the audience.
To meet these goals we had to have a believable business story to tell. Writing this story was our first milestone and the story became our script. As in theatrical productions, we asked the audience to suspend disbelief and involve themselves in the story even though some parts of the demo were not happening in reality.
As UI designers we had a personal goal of making sure the demo was an example of a great human interface. The entire demo had to be as visually clear and dazzling as possible.
The demo is shown to customers at close range in a demo booth, but it is also presented on huge video screens to hundreds of people in large halls. Displaying a complex technology in a simple, understandable yet dramatic fashion on both types of "stages" was one of our challenges.
The team consisted of a manager, a team of software engineers, and at varying stages, two human interface designers and two graphic artists. Annette Wagner was the human interface designer and art director at the start of the NEO demo project (February 1995) and took the demo through its first implementation and presentation at SunSoft's annual developers' conference. Maria Capucciati took on the project in June 1995 and made the revisions for the NEO product announcement in September 1995.
The authors had multiple roles on the project team. We acted as art directors in making certain the visuals were consistently high quality and the story was clearly presented. We provided UI design expertise for the GUI development to make the human interface of the demo realistic enough that viewers could see how the NEO technology could be applied to their own business contexts.
We played a crucial role as theatrical directors. Many times the software team felt they were too close to the demo to be able to tell if the story was working from a dramatic viewpoint, and used us as reviewers. We dealt with the projection and color issues much as a stage manager or lighting designer would, and we worked as usability engineers by tracking and evaluating the feedback the team got on the demo.
The biggest constraint we faced as a team was our unfamiliarity with the capabilities of the NeXTStep and OpenStep technologies and the fact that all the technology was under construction and therefore a moving target.
We created the GUI for the NEO demo using the NeXT Interface Builder. Interface Builder turned out to be more developer-oriented than we would have liked. It was easy for us to create simple windows and panels, but not to create custom widgets. Nor was it straightforward to connect and run the application to test if it worked.
The demo was written using distributed objects and other NEO technology to process information. Fakery was used only for expediency during crunch times or to compensate for slow performance or missing functionality resulting from building on a constantly evolving software platform.
As designers, we were constrained by the unorthodox color mapping used in NeXTStep. NeXTStep runs with 12-bit color plus 4 bits alpha channel. Moving back and forth between Solaris, NeXTStep and the Macintosh to do visuals meant that we could not trust the colors we saw on any one screen.
The "main event" style presentations of the demo at the conferences utilized a Barco projector to display the demo on huge video screens. The Barco can have unpredictable effects on the saturation level of colors which required us to run special tests with Barco projectors, not a common piece of equipment for most companies. The Barco has a softer focus and requires the graphics and type to be quite large. Small type and complicated icons become unreadable at a viewing distance of 20 feet. In the second version of the NEO demo, we focused on how much text we could reasonably replace with graphic elements to better convey the message to the audience.
Other constraints included having to support running a large and small version of the demo: the large for the Barco presentations and the small for a 17" screen for booths. We had to coordinate where windows came up on the screen relative to each other so that critical information was always visible as the demo progressed.
The team working on the NEO demo lived in two separate buildings at Sun. Meetings usually took place in the engineers' building. The team would meet around a whiteboard and work out the details of the demo with regard to software and story.
A central focus of all our design meetings was whether the design under discussion would be believable to the audience. If we didn't think it necessarily represented reality, our next priority was how to make it look as real as possible. For example, at one point in the story the presenter "wires" in a new NEO object. In reality, a user would probably employ a development tool to wire in a new object. That kind of tool would have complicated the demo unnecessarily. We simplified the concept down to a dialog which looked realistic while intimating complexity.
Schedules were very tight and ideas had to be prototyped and implemented as quickly as possible to see if they fit in with the overall presentation. The designers would prototype the screens in NeXT Interface Builder or on the Macintosh, then send them to the engineers along with a written interaction scenario. The engineers would build and run the application and the entire group would review it.
When we worked in Interface Builder, we tried to do as much up-front visual work for the engineers as possible, including the placement of icons. The Interface Builder files were passed back and forth as much as possible so that we did not get "out of sync" on the human interface design. We also printed and hung up screenshots in the offices of the engineers to keep everyone up to date on the latest design.
Initially, the project was kicked off with a series of meetings with marketing, NEO managers, and customers to determine a story or set of stories that we could base the demo on. We wanted stories about business problems that could be solved with the NEO technology. We encouraged people to tell us war stories about things that worked or not for customers they knew. The gist of these war stories was captured on white boards and big drawing pads.
The role of the art director was to take the story ideas and turn them into rough storyboards. We started by taking the story idea and writing a scenario around it. Scenarios were made as realistic as possible. They contained context on the company, the people, and their business problems. The scenarios were then reviewed and the ones that had the most potential were then merged into one story which was the basis for the NEO demo. The story line we finalized on revolved around an order entry system that needed to have certain critical changes made to it to reflect current business opportunities.
The story was turned into a script and storyboard to aid everyone in visualizing the demo. The storyboard showed frames in which critical interactions took place. Originally, the storyboards were hand drawn, and evolved into reality as screen shots and then code was developed. Eventually the storyboard was completely superseded by the actual demo.
One can think of NEO as an intermediate layer between the traditional client layer (the application GUI) and the server layer (the legacy databases). (This architecture can be seen in Figure 4.) The NEO objects can be set up to talk to either layer. Adding new functionality can be as simple as dropping in a new object and wiring it up.
The NEO demo is targeted at business customers who would use NEO to run their business software and its associated business processes. Each business process has a clearly defined set of steps and rules that have to take place for the process to be completed. For example, for an order to be placed, there are a set of constraints that must be met. The steps and rules for a business process can be encapsulated into a NEO object.
The British director Peter Brook believes that "the notion that the stage is a place where the invisible can appear has a deep hold on our thoughts."[2] As our demo story developed, we realized we really needed a stage on which to show people the invisible: how the business process objects were working with each other and with the other layers of the system. We also wanted to demonstrate how a change would affect the whole system or not, as the case may be.
Figure 1: This was one of the original "Locator" shots. It shows an early attempt to encapsulate business rules into NEO objects.
This "viewer" started out life as the "Locator"; the place where you could see NEO objects sending messages to each other and to servers, etc. Initially no one had a very clear vision of what this window might look like or what it might show. Ideas ranged from icons for each application to icons for each object. Maybe icons could show the underlying rules for how objects interacted with each other. Maybe icons show status, or lines are drawn to show which objects are talking to each other. Some icons could be drawn differently to show they are remote versus local.
Figure 2: Early layout of the Traffic Monitor.
Figure 3: Another early layout of the Traffic Monitor.
Figure 1 shows an initial layout where we toyed with the idea of showing how rules might be encapsulated in NEO objects. We abandoned that as being too confusing and developed several versions (Figures 2 and 3) before ending up with the layout we have now. Figure 4, the final layout, shows three layers: the client layer at the top, the NEO objects layer in the center and the server/legacy layer at the bottom. We called it the "Traffic Monitor".
When a presenter is running the NEO demo, the Traffic Monitor uses animation (Figure 4) to show the interaction between the system layers as actions are performed by the presenter. In that respect it sits in the background as a sort of onstage narrator for events that are taking place elsewhere in the demo. However, it is also used in the foreground of the demo script to show how adding a NEO object affects the business process.
Figure 4: This shows the final layout of the Traffic Monitor for the
first version of the NEO demo. It also shows an example of the animation
that appeared when objects were sending information to each other.
One major marketing thrust for the NEO demo was to demonstrate the ease of changing a system by adding a NEO object transparently. Our story line involved a large retail store chain that needed to respond quickly to business decisions made by competitors. The retail chain, called the "Good Buys", wanted to counter aggressive marketing strategies from the competition by running its own sales promotion. In real life, sales of promotional items would need to be tracked in the store's order entry system.
This piece of the demo was very hard to get consensus on. Management kept reiterating that the change had to be obvious, but were unable to articulate clearly how they wanted to see that happen and many times contradicted themselves. The team went through several iterations on basic ideas before settling on the idea used in the demo. The first version of the demo was limited by the fact that we did not have drag-and-drop functionality working.
Figure 5. An early screen design for the "Installer" concept.
Some people thought the change should be shown in the form of an installation (Figure 5), others thought it should happen from some kind of programming view. Some of the ideas required a context shift during the demo from the store to a developer's office. Audiences usually require the context of changing scenery, costumes or props to realize they are in another space. Because the stage demo had to move rapidly, we had no time to set up a new context; but without a discernible shift we could lose people. We kept coming up with ideas until we found one that worked without a major context shift. This design work was happening in parallel to the Traffic Monitor work. As the Traffic Monitor took on more substance we were able to see how we could use it to show the change.
For the first version of the demo, the change was accomplished by adding a pre-existing NEO object called "Promo", which contained all the business rules for tracking promotional items in addition to regular sales.
In the first version of the NEO demo, we wanted to show some kind of NEO object collection where the user could select the Promo object and then add it, but we ran out of time. Instead the Promo object was selected by bringing up a "Load Module" dialog. Unfortunately, selections in the dialog box were made so quickly that very few audience members realized that anything had changed.
Once the Promo object is added to the Traffic Monitor, we show it being wired into the NEO object layer. Once the wiring is done, the GUI for the Promo object shows up in the Order Entry GUI and the salesperson can determine the additional benefit for the customer (Figure 6). Interestingly, this part of the demo introduced certain tensions. The technical audience needed to see all the steps to make the demo believable for them. The analyst audience thought it was far too detailed.
Figure 6. This is the Order Entry GUI. In this screenshot the Promotion GUI panel is displayed at the bottom of the order form.
For the second version of the demo, we decided to illustrate the assumption that customers using NEO could purchase or build their own object "libraries" from which they can pull objects as needed. (This was implied in the first version.) We designed a window called the "Object Catalog", which showed a collection of objects ready for use (Figure 7). To further accent the change, we used the drag and drop capabilities of OpenStep to show the object being dragged into the system rather than being added through a dialog box.
Another scenario we wanted to visualize in the NEO demo was that of two GUIs sharing information from the same NEO object at different times. The first version of the NEO demo focused on one GUI, the Order Entry GUI. Everyone agreed that including object sharing, or shared services, was a high priority for the subsequent version. It required adding one more GUI which would be a view onto a set of services shared with the Order Entry GUI.
Figure 7: The Object Catalog as used in the final demo.
We needed a way to work the new GUI into the existing story. The original story premise is that the presenter plays a salesperson in a retail store. We added to this scenario by creating a new GUI for commissions and rewards. The presenter could now drag his sales ID from the Order Entry GUI into the Commission GUI. This GUI showed not only the salesperson's cumulative commission, but how close he was to earning a sales prize such as a television set or a trip (Figure 8).
At first, we thought that the Commission GUI should somehow appear when the Promo object was added to the system. It seemed logical that a sales contest of some kind should be associated with a promotional campaign. We concluded, however, that commission is a standard fact of a salesperson's life. It made more sense to say that every sale entered through the Order Entry GUI would have a commission associated with it, and that the introduction of the Promo object would simply change the policy by which commission was paid. So, instead of the Promo object introducing the Commission GUI, the Commission GUI is simply shown as a standard part of the system. Then when the Promo object is added, it changes the set of rules used by the Commission GUI. The two GUIs, Order and Commission, are then shown to share a new "Promo" object in the NEO layer.
Figure 8: The Commission GUI as used in the final demo.
We also added another new object representing the salesperson ("Employee"). Integrating these objects into an already crowded Traffic Monitor while keeping them all readable proved quite challenging (Figure 9). We discussed several ideas, such as adding a new GUI layer above the client layer, displaying each GUI's set of objects one at a time, and duplicating objects in two places on screen. We were finally constrained by the simple fact that there just wasn't enough room and we needed to reduce clutter, not add to it.
Figure 9: The final layout of the Traffic Monitor used for the product announcement.
Since the NEO demo wasn't a product, we performed no formal usability testing on it. This didn't mean that we didn't receive plenty of feedback from a variety of sources. We received notes from the presenters themselves, from the audiences and from the development team. We attended as many of the demo presentations as possible and took copious notes on what worked or didn't work. In this section we will step through the different kinds of feedback and how it affected the final demo.
One of our most pervasive challenges with the NEO demo was making changes to the system more visually obvious. A basic tenet of stage work is that if the audience can't see what the performer just did, they haven't experienced it. Subtlety was not going to serve us well on such a large scale as a conference stage. We needed to find ways of pointing up aspects of the interaction we wanted the audience to notice. Sometimes we were able to accomplish this with big visual cues, such as the Traffic Monitor animation. Other times we worked the change into the verbal parts of story line so the audience would walk through it with us. This was quite different than the usual approach in which the successful human interface is the one that integrates so well into the task as to be transparent to the user.
A good example of a story line change was the section of the demo where the presenter adds the Promo object to the system. As we discussed in the section "Adding Objects", one tactic we used to make the object addition more obvious was to have the presenter actually drag and drop the Promo icon rather than finding the file name in a dialog box. In the first version of the NEO demo, the object was added to the Traffic Monitor and wired up there. We decided to add a twist by having the presenter drag the Promo object to the Order Entry GUI instead. The ability to add an object directly to an open, running application made it more interesting from a technical viewpoint, too.
To further point up the change, the script than called for the presenter to attempt to place an order for a promotional item. It wouldn't work - because the NEO object hadn't been wired up yet. The presenter would then connect the object with the rest of the system and proceed.
In general, as major pieces of the demo were built we would notify the various critical people from NEO management who needed to review the demo. They would show up, we would walk through the demo and story in whatever state it existed, and they would give us feedback. Often we found a certain tension between the requirements of the presenter running the demo, and those of the audience viewing the demo. Many times we received conflicting feedback; for example, they'd tell us to make everything bigger on screen and add more functionality. Obviously, if we added more features then we had no room to make things bigger. The DOVE team manager was tasked with sorting through this feedback and worked with people to clarify their thoughts. The best approach was to do a storyboard or screen shot and simply ask, is this what you meant by X?
However, taking this approach didn't always work. During the demo we use a map to show where the "Good Buys" stores are relative to the competitors' stores. The color had been chosen by the designer to provide the best contrast for the icons that needed to appear on the map. At the last minute before the SunSoft Developers' Conference, management decided it was too bright and should be a lighter color. The engineer went ahead and changed it without mentioning it to the designers.
The result was a map with exceptionally poor contrast on which the icons used to show the stores were completely washed out. We learned not to make last minute changes without testing, and confirmed the color saturation problems inherent with Barco projection systems. In fact, the demo presentation at the conference confirmed many concerns we had with regard to the complexity of icons, color saturation, and type face size. These notes went straight into the next revision of the demo.
The NEO demo project provided many ways for us to stretch our human interface skills and to use skills from other areas of expertise like play writing, storyboarding, acting and art direction.
The theatrical experience is always incomplete without the presence and reaction of an audience. We designed and built a production, and really did not know if we would be successful until we presented it to a live audience. Our measure of success would be if the demo communicated the concepts and ideas that management wanted to convey.
During the first demo at the SunSoft Developers Conference, the authors were sitting behind two conference attendees who closely followed the demo, pulled out the demo white paper, and proceeded to discuss the possible capabilities this might offer them. When they walked away considering ideas on how to use NEO object technology back home, we felt we had accomplished our task successfully.
We would like to acknowledge the DOVE team at SunSoft: Amy Pearl, Pierre Delisle, Malini Minasandram, and Payam Mirrashidi. Thanks also to Michael Quillman of SunSoft and Marsh Chamberlain for their graphic design work, and to Alan Eyzaguierre and Dan Fish for NextStep help.