Report on the Development Process

Initial Designs

Before we started programming our application, we split into two independant groups and made images of what we pictured the final product looking like. By staying separate, we ensured different points of view and multiple choices for our initial design.

Design A:

Figure 2.1 - Synchronizing data between meter and PC

Figure 2.2 - Doctor information and database server login

Figure 2.3 - Various fields for searching through database entries

Figure 2.4 - Entries in the database in a linear view

Figure 2.5 - Successful data submission to the database server

Design B:

Figure 3.1 - Selecting information to be viewed on a custom graph

Figure 3.2 - Graph for a single day with various options selected

Initial Programming

After a group meeting, it was decided that the application would be written using C# with a custom library for the graphing functionality. After some initial attempts at writing in the C# language, the group chose to convert to Macromedia Flash once graphing functions were found in it. The first version included very basic data input and separate patient/doctor logins.

Figure 4.1 - Adding a blood glucose reading into the database

Figure 4.2 - Verifying the input for increased usability

Figure 4.3 - Menu system for doctors

Figure 4.4 - Entry of new patient information

Figure 4.5 - Menu system for patients

Figure 4.6 - Graph of a single day of readings

We chose not to have icons for each reading as in the initial design since we felt it looked cluttered and busy. By using points instead of graphics, the graph is easier to read and more intuitive. The next step we wanted to take was to make multiple graphs be displayed at once in order to show more data to the user in a convenient format.

Figure 5.1 - Three graphs displayed linearly

Figure 5.2 - Hovering over a graph enlarges it for better viewing of individual days

Usability Testing

Each test subject was asked to fill out both a pre-test and a post-test questionnaire in order to provide helpful information to our group. The users and their personal information was kept confidential, and no harm was present throughout the testing. The feedback our users provided helped us in many areas. One user suggested that we have multple graphs present on a screen rather than just one, which led us to the idea of having a whole week viewed at once. Multiple users that were tested pointed out various bugs in the patient information section, including wrong variables and mismatching displays.

Below are the two questionnaires that each user was asked to fill out, along with the tasks they were asked to do. Not all tasks were available to early versions of the application, so users were asked to do what they could. Their feedback was critical to the design of DDAS.

Pre-Test Questionnaire:

Age:

Are you diabetic?

If so:

How long have you been diabetic?

Do you wear an insulin pump?

How often do you test your blood sugar?

If not:

Do you know someone with diabetes?

Have you ever had your blood sugar tested?

Do you consider yourself technologically-capable?

Task List:

1. Login as a patient.
2. Enter a new blood sugar reading.
3. View the graph for January 3.
4. Go back to the main screen.
5. Login as a doctor.
6. View the information about a patient.
7. Edit patient information.
8. Close the program

Post-Test Questionnaire:

Getting started was:

Difficult 1 2 3 4 5 6 7 8 9 10 Easy

Choosing information to be viewed was:

Difficult 1 2 3 4 5 6 7 8 9 10 Easy

The resulting graph was:

Difficult 1 2 3 4 5 6 7 8 9 10 Easy

There was [ too much / enough / not enough ] information on the graph.

The graph format was [ not useful / somewhat useful / very useful ] in evaluating blood sugars.

What information did you find useful in the chart?

What information was not available in the chart that would have been useful?

Do you have any comments about the user interface?