1. Problem and
solution overview
In our project
we would like to create UI for software that will help people with different
levels of interest in alcoholic beverages to get relevant information quickly
and easily.
The most
important features we think that user will want to see are:
1.
Extensive cocktail database with such features as missing ingredient
replacement, suggestions based on available components etc…
2.
Library with relevant articles
3.
Shopping tool that help to find label specified by price range etc…
4.
Tool that tracks the amount of alcohol consumed and helps to determine if
person may drive or not.
5.
Notifier that will help to find related events in the user’s area.
To implement the
UI we chose tabbed interface to ease the navigation and separate different
tasks, since we found (see exercise 2, Contextual inquiry interview
descriptions and results) that different users will need part of the features
rather then to use all the purposed features so such segregation seems natural.
2. Tasks
Note: We
selected the tasks out of the updated list, which was accepted after the
comments on the ex2 first draft. See the web page for the details of the
changes.
http://www.cs.huji.ac.il/~nirp/hci/whatsnew.html
Easy:
Find
an alcoholic drink / cocktail for the spaghetti meal.
Medium:
User
interested to mix the “Rob-Roy” cocktail, which includes:
a) 1.5 oz. scotch
b) ¾ oz. sweet Vermont
c) 1 dash orange bitters.
Second
integrant is missing, and the user has to notice the shortage and to find the
replacement. The user only knows that the cocktail's name includes the string
"Rob", and has to use the search option to find the suitable
cocktail.
Hard:
Check
if a specific customer can drive. In order to do that, user has to keep track
on amount of drinks his customer consumed and to know his weight.
3. Revised interface design
Changes as a
result of low-fi testing and rationale behind the changes:
1. As we pointed
out in exercise 3 ”Discussion” , some of our labels in low-fi prototype were
misleading or just wrong as with “Search cocktail”(fixed)
label that was above dialog that was supposed to take as input not only names
of drinks, but also meal types, moods etc…
In Interactive
Prototype we tried as much as we can get rid of such errors. We asked from
people uninvolved in the project to go over various labels and try to deduce
without the help feature what the relevant widgets suppose to do.
2. In low-fi
prototype we had “Tracking”
tab and “Drive Check”
tab. Finally we decided to integrate the “Drive Check” functionality in the
tracking tab; it seems that devoting special tab for one feature is too much.
3. “Manually”
feature in “Drive Check”
remained unimplemented. Users that will not track amount alcohol consumed and
still want to check if person can drive can add new user in the tracking tab,
add drinks he consumed and then to check if
he may drive.
4. “Help”
functionality. User can get help on every part of interface using context menu.
Scenarios for 3
tasks:
1.
First scenario
involves user that wants to find something to drink in a spaghetti meal. In
order to find the appropriate drink, he needs, first of all to get to the
mixing tab.
Here he has to
enter "spaghetti" in the search dialog and "food" in filter
dialog
After clicking the
button "start" he can see the results of the search
Now user can
choose one of the results and ask about its info
2. Now user want
to prepare cocktail he took in bar, but can't remember its full name. He remembers
that there was "Rob" in the name of the cocktail. He goes to mixing
tab and writes "rob" in search dialog and chooses as filter
"cocktail"
He pushes the
start button, search performed and now he gets in the search results the
desired cocktail.
Now he asks
explanation on preparing the cocktail and sees that one of the ingredients is
missing
Now he want to see
if he can replace it with something other, so he choose the missing ingredient,
push the replace button and gets the results.
3. Barmen in a
party want to track how many drinks one
of his customers consumed so he can check if he can drive. He clicks on
tracking tab
Now he wants to
add the user to the list so he clicks on add user, dialog windows popped up and
the barmen writes the person's name(or identification if name unknown) in the
dialog.
Now he can after
every drink customer got to click on appropriate drink and pushes "add drink"
button in order to add this drink to the users list
In each step the
user can check how menu drink his customer drank, either by opening the context
menu on the user and choosing “View drinks list” option.
To check if the
customer can drive he just has to select him from the list and push the
"Can Drive?" button.
5. Prototype
overview
Tools used:
Before starting the exercise we got very
positive feedback about C# language in the Microsoft Visual Studio .Net
environment. It was supposed to be easy-to-learn tool that helps to design
interfaces in the Windows OS. Its main advantage was the fact that it comes
with a form editor that enables the programmer to easily place objects in the
desired location in the form. However, we had some issues during the work.
First of all the widgets are very rigid and even slight changes in their form
can cause non-proportional coding investment, as the language is missing some
of the commands that handle objects behavior. We also had problems with
implementing drag&drop functionality. Another problem, concerning the
users, is that working with .Net applications require installing its framework
(23 mega), it can be a bit too heavy for people with slow connections.
Overview of the
UI implemented:
Most of the UI
implemented is similar to our low-fi prototype. It consists of tabbed interface
where each tab represent main feature of the software. We decided do merge
"Tracking" and "Drive Check" tabs from low-fi prototype for
the reasons stated above.
Major features of
the software, those related to the database of drinks are accessible from this
tab. It includes dialog box for search string and another one for filtering
into various categories. The listbox contains current stock. Buttons on right
used to enter the new receipts.
In this tab
relevant encyclopedic articles can be found. The upper left list-box includes
browsable topics. Below it there is a search dialog and listbox for the
results. In the right side the textbox for reading the data.
Here user can make
shopping. In the left side there are dialogs that take as input name of the
desired product, its price range, availability and closeness of the replacement.
The right the box is for the results of the search.
Here user can
create a database of his customers, track the number of drinks they consumed,
charge the bill (if relevant) and check if they can drive. Left side of the
form includes listbox with user names. Buttons below enable to update the list.
In the right side there are the listbox with common cocktails (short list) and
listbox with all the available cocktails (long one).
Here user can
check for events in his area and sign to them. He can select the search
categories using the country, region and event type comboBoxes.
What was left
out and why
1) Ideally, we would
like to have help button as forth one near maximize/minimize/close buttons on
upper right corner of the window. We didn’t find the way to implement it on
windows OS, so we chose to put help option in context menu.
2) Drag&drop
functionality was replaced with other kind of interactions (such as double
click). The reason here is also implementation problems.
Hardcoded
points
All the scenarios
were hardcoded. We tried to insert some freedom in scenarios inputs and
sequences of operations, but we fast learned that even slight deviation from
scripts require extensive coding. Tracking many users with different drinks or
searching for different receipts require database management between forms and
it seems to be out the scope of the course.
Prototype
screenshots
Help
(Available for every
item in the context menu)
Here is another
help option, integrated in the multiple-choice context menu.
