Design
- 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.
...
Due to logistical reasons, we had only one team member present in each user test, who worked as both coordinator 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.
...
- 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.