...
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.
...
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.) | N/A | No screenshot available | No screenshot available N/A |
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. | | |
...
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.
...
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
...