Problem Statement

Corporate and governmental office spaces do not use their lighting systems efficiently. Often lights remain on in unused sections of the building or even after all the building's occupants have left for the night. Furthermore, the lights tend to be controlled in large groups; sometimes a single switch controls whole floors or even the entire building. This eliminates an individual occupant's environmental control as well as creating potentially wasteful lighting plans.

Charlie Huizenga, working for the Center for Built Environment (CBE), has developed a wireless lighting control system that can give building occupants complete control over any light in the building. The implementation of flexible controls has already been shown to cut a building's total energy consumption by as much as 15%. A unique characteristic of this system is that it is designed to retrofit existing lighting fixtures in a cheap and efficient manner. Other more expensive solutions require the installation of entirely new lighting components.

In the new system, individual occupants are given wireless buttons that control the light above their personal workspace. However, there does not currently exist an interface for facility managers to control or monitor the building's entire lighting system. The wireless lighting project envisions that such an interface would allow managers to monitor energy usage, control the lighting at various levels and provide notice when there is a light failure.

The system should provide utility for all levels of users. Upper-level building managers are more concerned with the energy use, whereas electricians and maintenance staff are primarily concerned with spotting outages. There is even the possibility that those within the building might wish to track energy consumption and schedule sensible lighting plans for their floor. The lighting control system will support these tasks.

Our goal is to build a web-based interface that will allow facility mangers fine-grain control over lighting behavior, scheduling and hardware status. The system needs to be intuitive enough to allow ease of use by people who don't necessarily spend the work day in front of a computer. Operation failures must be discernable at a glance and the source of the problem should be readily identifiable. Energy trends should be clearly visible without requiring detailed calculations. Our goal also is to create a system that the user, with little outside support, can configure.

Solution Overview

We have built an interface that will integrate information gathered from a wireless lighting control system. This prototype is implemented as a web browser-based system that can be easily accessed from any Internet connection. Through this interface, building managers can easily monitor energy usage and control lighting within their building. Lighting failures are also reported though this system. Designed for ease of use, this interface will require minimal training and will be accessible to users with a wide range of computer experience.

Personas and Scenarios

Tomas Cupertino

Primary Persona
Age: 51
Title: Facilities Manager

Tomas is good at his job, very good. He has been working for the Austin Natural History Museum for the best part of 20 years and he has seen it all. He is weathered but not worn. No matter what the calamity, Tomas always maintains his sangfroid.

Mr. Cupertino has a loving family. His wife, Linda, and his two daughters are the most important things in Tomas's life. Tomas likes to fly fish and cheer on his kids at whatever is their activity de jour. He confesses it is sometimes hard to keep up with what they are in to on any given day. Tomas Cupertino was born the oldest of 5 brothers in a modest Texas home. Tomas has steadily climbed his way to the top of facilities management for the most prestigious natural history museum of the state. It was no accident; Tomas works hard and is extremely resourceful. He is a republican's poster child of the bootstrap ideal.

Although he never finished high school, Tomas is smart and confident. He does admit to himself that reading is not his strong suit, and he gets a little nervous when confronted by a large amount of text. Probably the combination of a bilingual upbringing and his foreshortened schooling makes Tomas more comfortable around images and diagrams than documentation.

Mr. Cupertino is not a Luddite but really hasn't had time to stop and wrestle with any technology he doesn't absolutely need. He uses a computer to check and send email and Microsoft Word to compose longer letters. Recently the state started mandating that all non-urgent repair requests be submitted online, so now Tomas can find his way around basic web forms as well. Mr. Cupertino would love to "bring his museum into the technology age." He understands that there should be an easier way to manage the building, but has no idea what it might be.

Tomas spends a lot of time wandering the premises checking on the building and checking in with the hundred of other museum employees who might have first-hand knowledge of any facility problems. Once every couple of hours he returns to his desk to check for problems reported by email or by phone. The busiest time is always first thing in the morning. Tomas must check all his voice mail, email and messages left on his desk about problems found during the night. Then he must decide which are the most urgent and act on them. The biggest thorns in Tomas's side are the plumbers. No matter when you call them, they take forever to actually fix anything. His favorite joke begins "what to you call 1,000 plumbers at the bottom of the ocean?"

Tomas is still 9 years from retirement, but he is already worrying who is going to fill his shoes. There is a lot to learn.

Goals:

• To make sure all the maintenance issues get dealt with and the most important ones get handled first.
• To keep track what has been done and what he is still waiting to get done.
• To bring his operation into the "technology age."
• To leave things in a way that someone will be able to pick up where he left off when he retires.

Justification:

Tomas represents the quintessential facilities manager: long on duties, short on time. For our system to work for Tomas, it has to be simple and very practical. Any thing that makes the system too complex or frivolous will probably stop Tomas from using it. He is likely to need to interact with the system several times a day to monitor lighting status and once a month to adjust lighting schedules. His time sensitivity and emphases on making sure important lighting systems are working makes him an important persona. He is also one of our primary persona.

Dan Mason

Secondary Persona
Age: 46
Title: Physical Plant Utilities Manager

Dan Mason is a divorcee with two teenage children from his marriage - Matt, 17 and Beth, 15. He prides himself on being a good dad even though he only gets his kids for weekends and some holidays. When he does have them, he often plans trips to go camping or to the beach - anything outdoors will do. If the weather is bad and he's forced to stay indoors, he'll play board games with Matt or help Beth out with her physics homework. Dan also really enjoys working on his 1964 Corvette; it is cherry red. It has never run quite right and there's always something new to work on, but he loves that car to death.

When he's not with his kids or working on his car, Dan is earning his salary as a manager of the physical plant office at University of Massachusetts, Amherst. One of the primary duties of his job is to pay the utility bills for the entire campus. As a consequence, he feels pressure to try to get all the buildings on campus to be as energy efficient as possible so that the bills stay within reason. Unfortunately, because he only has control of the utility technology at the buildings and not the actual way that the occupants use the energy, it is often difficult to get the occupants and building managers to be energy efficient.

Dan has become particularly concerned about the disconnect between building managers and occupants because of rising utility costs. On top of that, a recent policy from the Regents is calling for a 10% reduction in energy consumption by 2014. To combat these factors, Dan has recently started an initiative to build a stronger relationship with the building managers on campus which includes a positive feedback reward system for buildings that reduce their energy usage.

Meanwhile, Dan is doing his best to research and install technology that will help automate energy usage such as: better thermostats, motion and photo sensors on lights and more efficient fluorescent light bulbs. He has a few tools for tracking energy and lighting usage patterns and he uses these to figure out where to install the technology he purchases.

Goals:

• Save money in university energy bills.
• Be environmentally responsible.
• Comply with federal, state and university energy policies.

Justification:

Dan Mason is an important persona for the LightsOn project because he pays the utility bills for the entire campus and therefore has a strong incentive to see energy usage reduced. The wireless lighting devices are a great technology for Dan to install in buildings because it will help automate the reduction of lighting energy consumption. Using technology like this is easier for Dan than trying to incentivize building managers and occupants to lower energy consumption.

Dan is also important because he is one of the few people on campus who has the power to purchase and install these wireless devices in buildings. He will want to justify his purchase by monitoring the energy usage (and hopefully reduction) by using a software interface.

Dan is different from the other personas mainly because he in a management position. He does not actually do any maintenance work or installation of the technology he purchases. Furthermore, he does not receive repair requests directly from occupants - these are sent to the physical plant call center and then delegated to electricians.

Final Interface Design

The LightsOn Pro system allows building managers to view lighting failures, turn room lights on or off in real time, schedule room lights to turn on and off and compare lighting energy usage over select periods of time.

There are five pages to our design. The first, the dashboard, has three widgets: Unresolved Lighting Problems, What Lights are On, and Lighting Energy Usage Trends. From each widget, the user can navigate to the corresponding page that provides more detailed information.

On the Lighting Problems page, the user can view existing lighting failures visually on the floor layout or textually on the lighting problems list. Users can mark lighting failures as reported when they have notified maintenance and they can leave notes about each failure to review at a later date.

There are two types of functionality to control the lighting system through LightsOn Pro: Turn Lights On/Off, and Schedule Lights. On the Turn Lights On/Off page the user can view rooms that currently have lights on and the amount of energy that each room is using. The user can interact with the building floor plan to automatically turn lights on or off throughout the building. To schedule lights for a later time, the user can use the Schedule Lights page. On this page, the user can edit existing lighting schedules or step through the Add New Schedule wizard to prepare a new schedule. Schedules can apply to one or more rooms and can have multiple on/off intervals.

Finally, to monitor lighting energy usage, the user can use the View Energy Graph page. On this page, the user can view energy usage for the current day, week, month or year, and they can compare that energy usage to a previous time period.

The interactive prototype was developed using HTML, JavaScript and CSS. These tools make it easy to construct a navigation system and adjust layout and placement of objects. They also facilitate the creation of interactive widgets; form elements are easy to add and actions can be scripted to hide or expose parts of the page.

The tools do propose some difficulty in building pages that may change arbitrarily. For example, on the scheduling page, the number of possible schedules is large, and it becomes impossible to code for every case using pre-written HTML. In addition, saving data is not an easy task in JavaScript, much of the persistent data is currently written out to browser cookies.

Graphing was done using a PHP package known as JPGraph. The software library allows us to pre-generate energy graph images based on fictitious data. These images are stored on the server and selected at run time based on parameters selected by the user.

All of the major functionality is now included in the interactive prototype. The only areas left undone have to do with logging into and out of the system. We envision a standard login system to distinguish users, preferences and privileges allowed to individual users. The login problem has been solved many times and we feel using best practices, a basic login/logout system will work fine.

Of course our wish list of new ideas is bottomless. We would like to add brushing-and-linking behavior to the Turn Lights On/Off page similar to that of the Lighting Problems page. It would be ideal if users could select lights from the lights on list as well as selecting them on the floor plan.

Obviously, we would also love to see the energy graph use real data. Our original plan was to connect it up to the wireless system so we could extract building energy use data. This coordination proved too difficult for the scope of our project. In addition, the previous/next ability only steps back and forward one time frame. In a real implementation, users will be able to step back through the entire history of data collected. We have also added an "Export Data" button that currently does nothing. This should eventually export the current energy usage data to a form that can be easily imported into a statistical software package.

We also never brought back the lighting problem history page. In the future, we would like to include a link at the bottom of the Lighting Problem page to view the history of lights that have been fixed. The utility of this function is not known, but we speculate it might have a limited use for tracking recidivistic lighting fixtures.

Currently, the interface does not check if user entered schedules conflict.

Owing to the heavy reliance on CSS and JavaScript, it remains difficult to effectively support multiple browsers and platforms. Since we are using the same tools as used for the first and second interactive prototype, the third interactive prototype only works in Microsoft Internet Explorer running on Windows XP. Additionally, resizing the browser window may cause the floor layouts to no longer display correctly. Please agree to any JavaScript usage warnings that might occur, these should not appear in a final version.

To begin, click on the provided link provided:

Third Interactive Prototype

Design Evolution

The LightsOn Pro has evolved greatly from the initial design sketches through low-fidelity testing, heuristic evaluations, and final usability testing. While the interface has retained much of the originally intended functionality, the interaction has gone through some major changes while still fulfilling the user goals.

Starting with the Dashboard, there were originally four widgets that have been reduced to three. This is a result of combing the Lighting Energy Usage Trends widget with the Overall Change widget. The widget is still titled Lighting Energy Usage Trends, but now holds both the energy usage graph and the summary statistic picture to indicate the general increase or decrease of energy usage over the past month. User testing established that, separate, the Overall Change widget was completely overlooked.

The Lighting Problems page has gone through several major changes. First, the icons labeling the textual list of lighting failures began with a simple "New" label to show new problems. This proved to be confusing to users. Second, in the first interactive prototype, the lighting failures were given icons with vague semantic meaning. The meaning of these icons was meant to be defined by the user. The heuristic evaluation pointed out that it was taxing for the user to recall rather than recognize the meaning of each icon. For the second interactive prototype, the lighting failures were marked either reported or not reported by a flag-shaped icon. During the pilot usability study, these icons seemed to confuse the study participants. As a consequence, for the final interactive prototype, all problems appear with an orange flag, and can be toggled to an "R" icon which represents clearly that the lighting failure has been reported.

Other major changes to the Lighting Problems page include mapping the textual list of lighting failures to the visual display of those same failures to the floor plan. The final design includes brushing-and-linking upon mouse-over of both the list or floor plan to emphasize the connection.

The What Lights are On went through an evolution in itself, from being categorized under Lighting Control options with more interactive pages such as Turning Lights On/Off in the first interactive prototype, to being grouped under Lighting Energy Usage with the View Energy Graph page in the second interactive prototype. Finally we combined it with the Turning Lights On/Off page, under that name. We decided that this page caused confusion because its functionality was so similar to that of the Turning Lights On/Off page.

After testing with the paper prototype, we removed room grouping functionality from our interface. Thus, the functionality in the What Lights Are On and the Turns Lights On/Off pages that leveraged this feature were also removed. As for the What Lights Are On and the Turns Lights On/Off pages themselves, no functionality was removed when they were merged in the third interactive prototype. For the low-fidelity prototype, users had a really difficult time determining the interaction with the floor plan. This difficulty was attributed to the medium and the equal challenge of supplying instant feedback to participants on how the lighting system changed after the actions they took. From the first interactive prototype to this final prototype, the interaction has been consistent, breaking the task into two steps, first selecting rooms to be turned on/off, and then second, selecting either the Turn selected lights ON or Turn selected lights OFF button.

The Schedule Lights page has gone through a major evolution during the design of the LightsOn Pro interface. The original plan to schedule groups of lights to turn off/on at a later time was broken into first grouping the lights together on one page and then applying a schedule to that group. We decided to combine that functionality onto one page, allowing users to only define a group only when they are creating a schedule. The original intention was to create a wizard to guide users through the scheduling process. Due to time constraints, the wizard was not implemented until the second interactive prototype, but this was in time to receive feedback during the pilot usability study. User testing provided some very useful feedback, including a change to make the step-by-step breadcrumbs interactive.

Finally, the View Energy Graph has gone through several visual iterations as well as one major overhaul of graphing options. Since we are not pulling real data from the wireless devices, we chose to test the visual display of data and find out what is important to see for our users. The graphing options were very hard to test during the low-fidelity prototype testing because of the large number of possible display options. For the first interactive prototype we greatly simplified the interaction. We re-worded the graphing options and trimmed the number of possibilities. In the second interactive prototype, we changed our graphing package. This helped us fix problems with the axes labels and the legend. For the final prototype we pulled the summary statistic icon from the dashboard onto this page. We found participants in our usability study rarely used the dashboard to determine energy usage and we hoped that a tighter integration with the energy graph would increases its visibility.

User testing with the first interactive prototype and the pilot usability study provided the most valuable data. While the paper prototype allowed us to test the basic layout and organization of the interface, it did not allow us to test the interaction flow in a manner that was natural to the user. Shuffling small pieces of paper as a "human computer" in low-fi testing did not allow us to test real-time feedback. Using this paper testing model, participants did feel comfortable exploring the interface because of the amount of effort required by the "computer" to update the screen.

In comparison, the first interactive prototype let the heuristic evaluators explore and interact with the interface in a familiar web browser. The heuristic evaluation provides us an opportunity to get honest feedback.   Unlike testing with users, where politeness might have stifled candid feedback, the expert evaluators were able to give us poignant criticism as to where our design fell short.

The pilot usability study also allowed participants to test all of the changes made to the interface since the first interactive prototype. This round of testing allowed our team to quantitatively evaluate our new scheduling interface. Of particular note, this testing revealed some glaring bugs in the wizard scheduling interface flow. Screen recording software also allowed us to closely analyze participant testing sessions in subsequent replays.

In the end, we learned important things from ever step of the process, but there is no substitute for observing real users.

Presentation

Work Breakdown