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 options for interaction shown 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.
Design Decisions
- Major initial design decision: parallel data views vs. one consolidated data view
- Paper prototyping feedback: "sell power" button in storage tab for learnability, clearer labels for graphs, naming for device tree and list, draw attention to existing cues such as checkboxes and data snippets
- Computer prototyping feedback: consistency of tabs, meaning of labels (top tabs and device vs. tree view), date pickers, organization/emphasis of important data to make interface less intimidating, legibility and alignments
- Overall tradeoff: amount of information vs. complexity of display; reduced the visual complexity of data by eliminating certain features, e.g. graph aggregation and usage/cost switch
Implementation
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, and TimeframeTagFragment reports which timeframe that user has selected: daily, monthly, or yearly. 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. Another output is the Operation Area. SmartGridActivity class loads DeviceTree, SortedDeviceList, DeviceSettingsPage, TransactionTable, and TransactionFragment into the Operation Area dynamically based on user inputs. Device, DeviceManager, and PriceManager serves as the abstraction of the back-end, providing data to the application.
Using the Fragment paradigm is the most important implementation decision. Android prior to 3.0 uses Activities to manage TabHosts. 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.
Evaluation
Due to logistical reasons, we had only one team member present in each user test, who worked as both facilitator and observer.
One 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 include his original request to find energy consumption broken 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 the places where we can improve:
- When he tried to adjust the Air Conditioner setting, the soft-keyboard blocked the screen. He can't see where the cursor was or whether the backspace was actually deleting the old value
- After schedule a transaction from the Reserves tab, the screen returns to the device tree view. It's not obvious how to view the just scheduled transaction
- 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.
Reflection
- Risk assessment and design choices: should have given more focus to learnability problems from the start--not necessarily learnability problems of the application, but of the problem domain. Assumed too much background knowledge on the part of the user, and later had to find ways to compensate for the lack of background information by trying to convey that data in our application.
- Features to prototype: focused more on data views and transactions than on device settings (and gave no focus at all to application settings). Assumed that data views were more complex, specific to our application, and difficult to solve than settings pages/forms. Good decision.
- Method of prototyping: wrote actual Android code for prototype. Good choice because: we were able to reuse some code; we were not afraid to throw away a substantial amount of code to replace Activities with Fragments; and there are no mature, full-featured prototyping tools currently in existence for Android.
- Evaluation of observations: heard and appreciated user feedback at all testing phases. Not able to implement all feature requests or fixes, but tried to get the most major ones, and especially tried to solve ones that were relevant to the data views. Found iterative process extremely helpful; barring time constraints, would have liked to do even more rounds of iteration.