Design history
The paper prototype
The design of our paper prototype looked like the figure below. We had File and Edit menus where all the functions could be found. In the Search/Edit field the user could search for first name, last name and e-mail. If the user filled in the search fields and clicked the "Search" button performed a search for first name or e-mail address. The first name found when searching for first name would be marked in the address book. Then the user had to click search again to find the next person with the wanted first name. Since the address book was sorted by last name, letter to letter matching will be performed for last name when searching. This means that when the users typed for example "M" as the first letter in the last name the application "jumped" to mark the first name with last name beginning with "M". When the user then typed an "a" the application "jumped" to the first last name beginning with "Ma" and so on.
When searching on e-mail within the university the user had the option to download the rest of the person’s information from a database server at the university. Filling in the e-mail address and selecting the search option made the search. If there was a match in the address book that person got marked and if there wasn’t the user got the option to add that person by downloading info from the Campus server. In the Search/Edit field there were also buttons to add, modify or remove a person in the address book.
There were functions to send mail or make a call to one or multiple people. Sending mail or making a call to a group of users was done by first adding them to a contact list by using "Add to contact list" button, which was located above the tabs, and then choosing the "Send Mail" or "Make a Call" option. The button will trigger the mail or phone applications integrated with the notebook. The "Clear" button was used to clear the "send list".
The address field where the people in the book are shown was ordered by last name and there were tabs for navigating a normal sized address book. Each tab consisted of three to four letters and each letter responded to the first letter in the last name. In the address-, telephone- and e-mail fields there were a triangle to the left of the information if that person had more than one address, telephone number or e-mail address. If the user clicked on the triangle a pull down menu showed the multiple information.
At the bottom of the address book there was a status bar that showed the user some messages that could be useful.
There were pop up windows to write with the stylus. Some buttons were shaded when they can’t be used; for example the user wasn't able to remove a person from the address book if that person wasn't marked. When the user clicked "Open" or "Save As" in the file menu a pop up window appeared. These windows looked like ordinary "Open" and "Save As" windows in other applications. There were also shortcuts when using the optional keyboard. For example the user may open an address book by using ALT + O.
Summary of our heuristic evaluations
The first problem found in the heuristic evaluation was interpretation of the stylus input. This was not done in a useful way. It should have been an extra field for interpretation so the user could see how the written text was interpreted before it was added to the address book.
Another problem found was that that the user could type directly in the fields under the register tabs. Everything that was written there would be saved automatically. This could be a problem if the user didn't understand the saving function. We think it would be better to have a pop up window where changes and adding to the address book could be performed. The user then would have to select a person to change or add and a pop up window would appear for editing the person attributes.
The contact list had a few problems. First there was no error message if the user wanted to e-mail or call one or more persons that didn't have an e-mail address or a telephone number. This must be provided since a person didn't have to have an e-mail address or a telephone number. The second problem was a related one. If a call or mail was sent to a person with more than one e-mail address or telephone number there had to be some sort of selection. As it was in the paper prototype, the user had to click that person’s name to select and then click "Add to contact list" button. Letting the user click the wanted e-mail address or telephone number instead of the name could solve this problem.
Under Preferences in the Edit menu the user had the opportunity to write the IP address. This was a bad design since most users didn't know what an IP address was. Maybe it had been better to ask for a URL address that the users recognize but the best thing would be to have the IP address installed automatically. Another problem with the server connection was that when the user wanted to download information about a person the server might be out of order. There was no error message taking care of that. This must of course be implemented.
When searching the address book on first name or e-mail address the result could be that no person was found. Then it would be useful to get a message that no person was found. This was not provided in the paper prototype. Another thing was that the user might click the search button before any first name or e-mail address was written in the fields. The result would be that nothing happened. Therefore it had been better to keep the search button shaded until a first name or an e-mail address was provided.
Since the address book was sorted by last name the last name search box should probably been placed above the first name search box. It was perhaps more logical that the letter by letter match was placed above the other search functions.
When downloading information from the server there was no feedback to the user. The user would then find it difficult to understand whether the downloading failed or was successfully done.
If the user selected a person to remove from the contact list there should have been a pop up window asking if the person really should be removed. The user might had selected the person by mistake and wanted the ability to cancel the remove function. This was also the case when removing a group from the address book.
Finally there was no help function available in our low fidelity prototype.
How the problems affected the final design
The problems found in the heuristic evaluation affected the final design quite drastically. The error messages that were missed in the paper prototype had to be implemented. We have tried to implement as few pop up messages as possible since they can be rather irritating to the user. This can be done using shaded buttons, when the operation can't be performed.
We have provided a better stylus-input window that includes an interpreter. This is because it can be rather difficult to write with a stylus in a small box and the interpreter might not understand the written text.
The information about a person can in the final version be found by clicking on the "Info" button. Then a pop up window appears that consists of tabs where all the information can be found and changed. We find this solution easier to use than the one in the paper prototype. There the user had to change the information directly under the register tabs.
The search results are now displayed in a search result field. When the user searched on first name in the paper prototype, the first hit was marked under the tabs. Then the user had to click search again to find the next hit. It was the same when searching on an e-mail address. We found that it was not a good solution. Instead a search result list will display all search results were it is easy to select the wanted person. We also discovered that it would be good if the user has the opportunity to search on address, nickname, telephone number and misc., therefore we added those features to the final design.
When we made the paper prototype we worried too much about the implementation. This affected our design in a bad way. As we worked on the final design we tried to think less about implementation and more about the design principles and what functions the user would like to have.
You might now want to go to the next page, go back or go to the first page.