Design
Overview
The overall structure of our application is similar to the one we initially envisioned when constructing our paper prototype. It is data-centric, with two dimensions of tabs controlling the information displayed in the main, split-pane interface. A graph is displayed in the top pane, with textual data and related actions (e.g. selling power, changing device settings) available in the bottom pane. Tabs across the top of the screen allow the user to change the source of the data shown: from consumption devices, generator devices, or from the power grid. Tabs along the left side of the screen allow the user to control the time interval for which data is shown. An earlier or later time period can be chosen by swiping across the graph, or by using the date pickers above the graph.
|
|
|
|
|
Main screen. The application opens on the Consumption tab, displaying data from the current date in daily view. |
Viewing consumption by device. By checking the boxes next to each device, the data relevant to that device is shown in the graph, in addition to the total. |
Viewing stored power by device. The Reserves tab is analogous to the Consumption tab, but shows the amount of power being generated rather than consumed. |
Viewing monthly stored power. The selection of a monthly time interval will persist even if the top tabs are changed. |
Scheduling a transaction. The split-pane view allows price data to be viewed in the top pane while a transaction is being scheduled in the bottom pane. |
Design Decisions
Our earliest and most significant design decision was to present the user with parallel data views, controlled by sets of tabs, as opposed to one consolidated data view with many options. We had hoped that the parallelism between views would increase learnability, and that keeping different types of data on different screens would help minimize visual complexity. These choices were endorsed by user feedback. Based on the tab labels and the type of data being shown, users were largely successful in determining the types of actions available from a particular tab. They commented that, while the application appeared complex at first glance, clear labeling of tabs and data made it less intimidating and easy to understand upon closer inspection.
The feedback we received during paper prototyping was influential in guiding a number of our design decisions:
Paper Prototyping Feedback |
Original Design |
Change |
|---|---|---|
The original labels of some interface elements, such as the "device list" view, were unclear to users. We reconsidered the names of these elements, trying to improve their information scent. The new names we chose, such as "sorted device list" view, proved easier for users in later testing rounds to understand. |
|
|
While we had originally thought of power sales as an action belonging to the "grid" (now "pricing") tab, most users of the paper prototype looked for this feature under the "storage" (now "reserves") tab. We added a "sell power" button under the "storage" tab to increase the flexibility and learnability of the application. |
|
|
Many users were initially confused about what each graph represented. This emphasized the importance of having clearer and more prominent labels and legends for graph data, which we focused on including in our final implementation. |
|
|
Similarly, users either ignored the data snippets in each top tab, or were confused about what they represented. We added the word "currently" to each tab, which drew more attention to the snippets and clarified their meaning. |
No photo available |
|
We also took into account the feedback we received from computer prototyping:
Computer Prototyping Feedback |
Original Design |
Change |
|---|---|---|
Many users complained that when one set of tabs was changed, the settings of the other tabs did not persist. For example, if viewing monthly price data, switching to the "consumption" tab would change back to the daily view. While we originally intended to have tab settings persist, the Android Activity paradigm made this difficult to implement. Because of the frequency of these complaints, however, we refactored the entire application to use Fragments instead of Activities, which allowed us to make the tab settings persistent. (See the Implementation section for more details.) |
No screenshot available |
No screenshot available |
We also received multiple complaints about readability and alignment issues, particularly with respect to tab text. We made an effort to align text correctly, and to adjust font sizes to allow readability and to convey relative importance. |
|
|
Our prototype included mocked-up date pickers, which were sized-down versions of a default Android widget. While users appreciated the external consistency afforded by using this widget, they felt that the size was too small to be usable. We addressed this concern by creating a custom widget which was styled to look and feel like the default one, but which was rotated horizontally so that it could be made larger. |
|
|
Overall, many comments indicated that users did not have as much understanding of the problem domain as we had assumed. We tried to further adjust the labels in our application to convey more information about the intended functions of the application. For example, we renamed the "grid" tab to the "pricing" tab, which proved more understandable to users who did not have existing knowledge of the smart grid. |
|
|
Implementation
The figure below shows the software architecture of the application.
The tablet screen is partitioned into multiple fragments. Some fragments provide inputs. For example, the MainTabFragment reports which function tab that user has selected: consumption devices, reserved power, or pricing information. TimeframeTabFragment reports which timeframe that user has selected: daily, monthly, or yearly.
The SmartGridActivity class serves as the controller of the application. It receives inputs from the input fragments, and drives the outputs. One output is the Chart, which occupies the top half of the split-pane interface. Another output is the Operation Area, shown in the bottom pane. The SmartGridActivity class loads DeviceTree, SortedDeviceList, DeviceSettingsPage, TransactionTable, and TransactionFragment into the Operation Area dynamically based on user inputs.
The Device, DeviceManager, and PriceManager classes serve as the abstraction of the back-end, providing data to the application.
Using the Fragment paradigm was our most important implementation decision. Android prior to 3.0 uses Activities to manage TabHosts, or sets of tabs. For GR4, we used this paradigm, which resulted in nested TabHosts of three levels deep. This exposed a few bugs of Android itself, and they were difficult to fix. It also made it difficult to persist timeframe and device selections over different tabs. Using Fragments solved these problems, allowing tab settings to persist across different selections, and thus providing greater consistency.
Evaluation
Due to logistical reasons, we had only one team member present in each user test, who worked as both facilitator and observer.
User 1
Our first user was our original User B in GR1. His requests were part of the requirements of the project, but we still presented the GR3 debriefing to him. His tests included his original request to find energy consumption broken down by the hours, and he felt the user interface intuitive enough to quickly find out the information. He was also given some other tasks, for example, schedule a transaction. His overall feedback is that the interface is easy to learn, and information is presented well.
A few observations on where we can improve:
- When he tried to adjust the Air Conditioner setting, the soft-keyboard blocked the screen. He couldn't see where the cursor was or whether the backspace was actually deleting the old value. To solve this, we will need to move the widget up, above the soft-keyboard.
- After schedule a transaction from the Reserves tab, the screen returned to the device tree view. It's not obvious how to view the just scheduled transaction. To solve this, we can add more information in the Toast dialog.
- He was pressing on the device name itself, while trying to bring up the device settings page. Currently using the Edit Setting button is the only way to get to the page. We should consider supporting context menus as well, which will pop up when user presses a device name.
User 2
The second user is a female home owner. She is a typical user among the targeted user population of the application. She had no prior knowledge of the application before the test. She was verbally introduced the purpose of the application first, and then given about ten minutes to play around it. After that we asked her to do the following specific tasks:
- Find today's total energy consumption
- Find which device used most for the day
- Compare today's usage with the past 30 days
- Adjust the setpoint of the air conditioner
- Sell power from a specific device at a given future time
The test went well in general, but did expose following problems:
- Data shown for the Daily tab actually contains hourly data. Today's total consumption, for example, can't be found in the Daily tab. To fix this, we can make today's total data shown on the chart as text. We should also consider to add help at the bottom of the screen, similar to status bar of Windows.
- Total is mistakenly considered the sum of all selected devices. Adding a separate line for the sum in the chart should solve the problem, and it has value in its own behalf.
- Back button doesn't work, and Undo is not supported. This is a missing function that we will add in the future.
- There is no obvious indication that user can swipe the chart to scroll. This is another missing function that we will add in the future.
- Besides the issues above, the problems found in the first user test also found in this test.
User 3
Our third user is a male apartment resident with a roommate, also part of our targeted population. He had no existing knowledge of smart grid or smart meter technology. He was given the GR3 debriefing before the test, and was then asked to perform the same tasks as User 2, above.
The user commented that overall, our application seemed "solid" and "simple." The test elicited the following observations and comments:
- At first, the user thought that the green line in the graph represented a particular device. It took a while for him to realize that it actually represented the sum of all devices. Despite having realized this, he was momentarily confused about it again later in the test. It would be useful to have some kind of visual indicator (e.g. a bolder line) to show that this line is conceptually different from the ones which represent individual devices.
- After scheduling a transaction using the "sell power" button in the Reserves tab, the user was not sure how to view or change that transaction. While we had initially intended to switch to the Pricing tab when the "sell power" button was pressed, we currently pop up a transaction scheduler within the Reserves tab. This creates a visibility/feedback problem when the user schedules a transaction in this way, precisely because the results cannot immediately be seen or modified. Implementing our original idea to switch tabs would help with this problem.
- As with User 2, the user had difficulty discovering the graph's ability to be scrolled, commenting specifically on the lack of affordances for scrolling.
Reflection
Risk Assessment
From the start of our project, we operated with a primary focus on learnability, because of the complexity of our application. This decision proved to be a good one: users did, in fact, find our application complicated and intimidating at first. We made further choices and changes with the intent of increasing learnability, and later user tests showed that these changes did help make the application easier to learn and use.
While we consistently focused on "learnability" in the sense of making the application easy to learn, we initially underestimated the extent to which our application would also have to teach users about the problem domain. Most users did not fully understand the concept of a "smart grid" or "smart meters." In later iterations, we had to find ways to compensate for this lack of background information by trying to convey those concepts through our user interface.
Prototyping
In choosing which features to prototype, we focused mainly on presenting device data and scheduling transactions. We spent little or no time prototyping features like the device or application settings. The features we chose to prototype were the ones we felt were more complex and specific to our application. Ultimately, this proved to be a good decision. The features we focused on were the ones that users found more difficult to understand--and were also the ones that were more challenging for us to implement.
We created our computer prototype by writing actual Android code. This choice was beneficial to us for three reasons. First, it prevented hassle and frustration: there are few prototyping tools that exist for Android, and those that do exist are buggy or have few features. Second, we were able to reuse some code in later iterations of the project. Third, we were not hesitant to throw away what we had written (as evidenced by the fact that we substantially refactored the code between iterations). This method of prototyping saved us time, but didn't prevent us from making changes later.
Evaluating Observations
We listened to and appreciated the user feedback we got during all testing phases. Time constraints kept us from implementing all the suggested changes, but we tried to get those that were the most severe. We especially focused on problems that affected users' understanding of the graphs and data, because effectively presenting complex data was the primary goal of our application.
We found the iterative design process extremely helpful. Repeated user testing helped confirm that the changes we made were effective, and helped prevent us from making changes that worsened the interface. Barring time constraints, we would have liked to perform even more rounds of testing and improvement.