Human-Computer Interaction Project

STUDENT BUDGET SOFTWARE

Part 3: Prototyping

Authors:

Angela Johnson

Darrell Curry

Website:

www.clarkson.edu/~currydj/HCI

Date:

November 8, 2006


Overview

In Part 3 a design was selected from the three alternative designs of Part 2. The decision was made based on user data and the expert reviews collected in class. The selected interface was then implemented in Visual Basic.

Prototype Selection

Pilot Session

Pilot sessions were conducted with potential users to test the usability of the three alternative designs. Two representatives from the target group, college students, were asked to perform a series of scripted tasks. The time required to complete each task was recorded. The user then answered an evaluation questionnaire. Detailed results from the sessions are available on Part 3 of the Student Budget Software website. Design 2 was the favorite for both respondents.

Expert Review

The evaluations from the class provided valuable insight on the relative strengths and weaknesses of the three alternative designs. The comments and recommendations were not only used during the selection of a design, but also when prototyping an improved version of it. Opinions varied, but there seemed to be a consensus on the second design. Design one was viewed as easy to learn and functional, yet boring. The experts found the wallet to be interesting and unique, but not practical.

Design Selection Criteria

The user data and the suggestions from the class experts were used to create a metric for judging the designs. The following page displays a table of the selection criteria and the rating for each design. Quantitative values were based on a semantic differential 5-point scale, where 1 is poor and 5 is excellent. Though the designs were rated by the team, the results reflect the opinions of the users and the experts.

Design 1
/ Design 2

Design 3

Table of Selection Criteria
Principle / Criteria / Design 1 / Design 2 / Design 3
Affordance / Obvious operation of income and expense entry / 5 / 5 / 1
Aesthetics / Visually appealing / 4 / 4 / 5
Learnability / Efficiency of first time use / 3 / 5 / 3
Simplicity / Clearly understood icons / 5 / 5 / 2
Structure / Appropriate grouping of related features / 3 / 3 / 2
Consistency / Predictable placement of tools / 3 / 4 / 2
Recoverability / Ability to undo deletion of an item or amount / 1 / 1 / 1
Tolerance / Avoidance of incorrect data entry / 1 / 1 / 1
Accessibility / Flexibility of categories to accommodate a wide range of preferences / 4 / 4 / 3
Visibility / Obvious functionality of icons / 3 / 4 / 2
Feedback / Helpfulness of status bar / 4 / 4 / 4

Final Selection

Since the Student Budget Software is a simple program, all of the items on the table were weighted equally. A total of the points for each design are displayed below.

Design 1 / 36
Design 2 / 40
Design 3 / 26

Design 1 and 2 are significantly close according the design criteria. Both users involved in the pilot sessions responded that design 2 was their favorite, which is why design 2 was selected.

System Description

When the design was selected, we did not just make an exact replica of the low-fidelity prototype in Visual Basic. We took into account the comments and recommendations of the users and the experts. The illustrations that follow represent more or less the same design as seen in the previous design alternative with the inclusion of some suggested improvements.

Main Window

The figure to the right shows the main window of the student budget software. The two main categories, income and expenses, are expanded to view the default subcategories. There is a menu bar at the top which includes all of the functions that are available on the toolbar with shortcut keys. The toolbar functions were divided into groups of similar functions and separated by a space for greater visibility. The total balance is calculated and displayed at the bottom of the figure window.

Status Bar

A status bar is located at the bottom left-hand corner of the figure window. The status bar provides information to the user about the function of an item at which the mouse is pointing. In the example to the left, the cursor is pointing to the subcategory food. The user is instructed to double click the item to view or edit.

Editing Budget Tree

The student budget software allows for the addition or deletion of any category or item on the budget tree. A non-modal popup window appears and the user is prompted to enter in the appropriate data. If the user double clicks a category, then the item will be included within that category. A checkbox is available for when the user would like to add a category. The neighboring textbox will then allow the user to enter the name of the category they wish to add. To avoid errors when entering in the amount of the item, the user is only allowed to enter numeric values. This will prevent accidental entry of non-numeric data that so a total could be properly calculated by the system.

Tool Tips

The picture to the right exhibits the implementation of tool tips. When the cursor pauses over an icon, a yellow box pops up with a description of that icon.

Menu Bar

Once again, all the items on the toolbar are also available in the menu bar. The first grouping of tools (‘new’, ‘open’, and ‘save’) fall under the category, ‘File’. The ‘add’, ‘delete’, and ‘undo’ functions are located under ‘Edit’. The picture to the right shows the open ‘Tools’ menu that corresponds to the last group of icons in the toolbar. A brief set of instructions on how to use the software can be found under the ‘Help’ heading.

Checkbook Feature

A metaphorical checkbook allows the user to save time when balancing the checkbook by letting the system do the calculations. The metaphor makes it obvious where to enter information. The check history is available in the format typical of any checkbook register. A date picker is used for entering the date to prevent confusion over format and invalid information entry.

Notes Feature

The user is expected to sometime write down miscellaneous notes or memos. That is why the notes feature was created. The user is able to add, edit, view or close notes.

WebLinks Feature

With the WebLinks feature, a user will have convenient access to a personalized set of online banking and/or loan website. The layout for this feature is consistent with that of the notes feature for predictability.

Dialog Calendar

Often it is necessary to look at a counter when performing budget planning. The calendar used in our design of the budget planning software is the standard calendar available in Visual Basic.


Implementation Challenges

Despite our best efforts, whenever there are time constraints, there will be limitation associated with any design. What follows is a discussion of the implementation challenges encountered when prototyping the student budget software. All of the obstacles we faced were due to problems with coding the software. An interface that is designed around the user is not necessarily the most practical to implement.

There was a recommendation by one of the evaluators from the pilot session to implement a mini-feed option. This would allow for the program to run continuously in a minimized-like state while still being displayed on the desktop.

For the checkbook, we would have like to display lines separating different checks in the register. Mimicking the standard register would make the check history more readable for the user.

The calendar included in the software is the standard function available on Visual Basic. Ideally, we would have liked to include a continuous calendar where the user is not required to “flip” the pages for each month. This would have involved more time than was available.

Lastly, we attempted to make the budget tree more informative at the suggestion of one of the experts. By doing this, we would be able to reap the main benefit of alternative design 1. Currently, we are still brainstorming ways to make this happen.

Conclusion

In Part 3 a design was selected from the three alternative designs of Part 2. The decision was made based on user data and the expert reviews collected in class. The selected interface was then implemented in Visual Basic. We will continue developing the design up until evaluation of the prototype.