...
- 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.)
- 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 purpose of the smart grid.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
Implementation
The figure 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.
The 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, which occupies the top half of the split-pane interface. Another output is the Operation Area, shown in the bottom pane. The SmartGridActivity class loads DeviceTree, SortedDeviceList, DeviceSettingsPage, TransactionTable, and TransactionFragment into the Operation Area dynamically based on user inputs.
The Device, DeviceManager, and PriceManager serves classes serve as the abstraction of the back-end, providing data to the application.
...
Using the Fragment paradigm is the was our most important implementation decision. Android prior to 3.0 uses Activities to manage TabHosts, or sets of tabs. 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, allowing tab settings to persist across different selections, and thus providing greater consistency.
Evaluation
Due to logistical reasons, we had only one team member present in each user test, who worked as both facilitator and observer.
...