Presentation of Web Design
Overview of Approach
When approaching the web interface for the ScalePlus, it seemed logical to draw from other devices that have extremely limited physical interfaces but provide significant functionality through web interfaces. Such devices typically include network routers, bridges, print servers and other small devices which are usually connected to a network. The easiest to use of these devices tend to be simple with a few categories down the left side making up the core of the menu system while the actual content is presented in the right frame.
Taking that general concept, the first ScalePlus web interface screens were static html pages which presented some idea of the eventual functionality and appearance, but lacked the proper organizational hierarchy to make navigation simple. Where each specific functional part of the interface belonged was not clear at this point and exactly how the system would provide the proper functionality was yet to be determined.
The basic functions that we thought the web interface should provide were as follows. In order to facilitate the user-based design of the scale a user management system was required. The user management system needed to support the addition, removal and modification of user accounts. Each user essentially constituted a list of personal information including name, age, height, gender, and some limited personal settings. The second major goal was to allow for the review and modification of recorded weights and body fat measurements. Further goals included easy exporting of data and management of the various networking and other options which the scale would provide.
With these goals in mind, the first design offered a glimpse as to how this functionality would be implemented. The user management system consisted of a simple table of current users where the last row was left blank to allow for a new user to be added. In addition, each userís name was a hyperlink that linked to more detailed information about the user. On that page every piece of user information but the name could be changed. Mainly this enabled users to enter or change their age, gender, height, and sound settings.
The core of the interface itself was the ability to view and modify recorded information. The two obvious ways to view data like weights and body fat are as a chart and as a graph. The chart was very simple to implement and also provided an easy way to modify past data. In order to view a chart, a user would specify a user and a date range, followed by all relevant data being displayed. If no data was available then a proper message was displayed. In the table, each field was a text box and a modify button was provided so that changes could easily be made by simply typing over the old data. Emulating the user management system, the last row was left blank so that new data could be added. Finally, a comments field was provided for each record so that people could annotate their progress or put some kind of flag for a measurement that is possibly erroneous.
Slightly more difficult was the graphing of data. With some searching we found a php library that allowed for the relatively simple creation of acceptable graphs. The graphs were very simple and showed weight versus time for arbitrary date ranges for one user at a time. Mostly because of limited time, the graph does not have meaningful labels on the x-axis and comments are not displayed on the graph. Future versions would want to get x-axis labels working properly and provide the option to include comments on the graph. Also graphs are currently a fixed size in pixels, and we would probably want to allow for user controlled graph sizes in future versions.
To keep the various pages consistent we stuck to one design that was general enough to suit each page. A banner ran across the top of all of the pages providing a reassurance that the user was still inside the web interface and provide a sense of unity throughout all of the pages. Below the banner, down the left side was as menu providing access to a welcome screen with descriptions of each menu item along with all of the other portions of the interface. Finally, the majority of the screen, to the right of the menu and below the banner, was devoted to the actual content of the page. In order to set the content pane apart from the background, the content pane was made slightly grey while the background of the whole page was white.
One of the main decisions made at this point was the color scheme. After experimenting with many different colors, we liked a slightly purple blue the best because it balanced contrast and a slightly soothing interface. Other colors tended to be too harsh and made for a strained look, or lacked enough contrast to make reading text easy. Both black and white text showed up well on the off-blue color making it easy to demonstrate which menu item you were currently under with reverse coloring. We decided to stick to grays alone within the content pane to provide consistency and keep color clashes from occurring.
In order to emphasize changing rows in tabular displays the background color of each row alternated between being white and a grey that was slightly darker than the grey used as the background of the content pane. The graph had a grey background with a dark green line to help distinguish it from the rest of the content.
Presentation of Screens
From the low-fidelity designs we created a set of functional php scripts which generated the dynamic content demanded by the web interface. In essence the medium-fidelity prototype simply implemented the functionality which the low-fidelity prototype implied. Then the high-fidelity prototype fixed problems that were brought to our attention by usability testing.
The following is a list of each screen in the ScalePlus web interface along with some commentary about each screen.
Figure 1: The welcome screen
When a user first goes to the ScalePlus web interface, they are greeted by the welcome screen which serves a variety of purposes mainly oriented toward new or infrequent users. First, there is a description of what is located under each of the menu items that run down the left. Second there is a brief statement explaining what a new user should do first. Additionally to the right of the banner and this and all other pages, there is a link which points users in the right direction to create a new account for themselves.
Figure 2: †The user management screen
The second menu item is the user management screen. This screen displays a tabular list of all of the users in alphabetical order and permits users to be added or removed. By clicking on a userís name, it is possible to view more detailed information about each user. Finally there are three quick bullet points which cover the main actions a user might perform on this screen. In general, help is provided at the bottom of the screen so that if confused, users do not have to stray far to find help. In the future, it would be necessary to password protect userís individual accounts in addition to creating an administrator password. Then, users would need to log into the web interface before they would be able to see any data or make any changes.
Figure 3: The user detail screen
The user detail screen can be reached by clicking on any userís name in the user settings screen. This contains all of the information that defines who a user is. All of this information is easily changed except for the name which is assumed to remain constant throughout use. Once changes are made and the modify button is pressed a confirmation window will appear, and the fields are updated in the database. Currently the age is stored as an integer and would need to be updated if the userís age changed. A better, but slightly more complicated, way to do this would be to simply store the date of birth.
Figure 4: The view/modify weights screen when first loaded
The view/modify weights screen is really the core of this interface. It is what the users actually want out of using the device. It is, as a consequence, also the most complex screen in the entire interface. When first brought up the screen presents a simple form which can be filled out with a user and date range in order to generate either a chart or a graph at the userís request. Additionally, a mechanism to add a new record is provided at the bottom along with some help to explain the process of adding a record. If a record is added from this state, the page will automatically display a chart of the weights entered for the user and date of the new entry. If an entry is added later on, the chart or graph currently being viewed is left alone so that the user is not surprised by sudden changes in the data they are viewing.
Figure 5: The view/modify weights †screen in chart mode
The view/modify weights screen has two modes. The first is the chart mode. In this mode the weights for the specified user and date range is displayed in a table so that it can be easily changed or removed. Individual fields can be changed by simply typing over the old values and pressing modify, while removing entries is accomplished using a checkbox. In order to give users feedback, a confirmation window is displayed whenever changes are applied. In future versions, this would be easily exportable as a comma separated values file which could be easily opened in spreadsheet applications such as Excel.
Figure 6: The view/modify weights screen in graph mode
The second mode of the view/modify weights screen allows the user to view weights visually using a graph. This allows for a quick overview of a sequence of data points without having to strain short term memory looking for patterns in the data. It also makes anomalous entries stand out. In future versions this graph could be exported as a jpeg or png for the user to send to a doctor or anyone else.
Figure 7: The network settings screen
Figure 8: The other settings screen
The network settings and other settings screens are simply provided as stubs for screens that would be required in a complete interface.
Figure 9: Transition diagram
In the interface, each screen has a link to each menu item represented by the first row of the transition diagram. Further detail is provided for the user settings and view/modify data screens. The extra pages and their relevant transitions are on the second row of the transition diagram.