...
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. |
...
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. TimeframeTagFragment TimeframeTabFragment reports which timeframe that user has selected: daily, monthly, or yearly.
...
Due to logistical reasons, we had only one team member present in each user test, who worked as both facilitator and observer.
User 1
One 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.
...
- 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 didn't know the details 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:
...
- 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 in as text. We should also consider to add help at the bottom of the screen, similar to status bar of windowsWindows.
- Total is mistakenly considered the sum of all selected devices. This is not intended,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 no undo Undo is not supported. This is a missing function and that we will add this in the future.
- No There is no obvious indication that user can swipe the chart to scroll. We plan to added clickable buttons at the left and right ends of the chart, which user can click to scroll the chart. Swiping is an efficiency feature for users more familiar to the applicationThis 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
...