...
- 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
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
...
.