The prototype

After the analysis phase we moved to prototyping. Here I present the prototype of our application.

Information about the application:

• it will be run on a single computer (PC)
• it should be in Finnish
• the layout should be similar to the paper based calendar
• it should be easy to understand, intuitive

Below there is proposed layout of the main window. We were aiming at the interface similar to the paper-based schedule's interface.

After clicking the bar on the left, the short week's schedule will fold out, the same as the one placed on the cover of paper file.

Adding new clients is being done by entering their names into the upper text input and clicking "Add", instead of putting them directly into the list. We thought this solution will be easier, as if there is no places on the main list, the person will be automatically put into the waiting list and the application will prompt for the client's phone number. The user can see if there are free places, because of the green "tick" next to the input. If there's no places the "tick" will disappear.

It is possible to delete a person from the lists by clicking the small red cross next to their name. The application will ask for confirmation in this case.

It is also possible to mark the people on the list who come and ask for the pass. Then it is enough to click the circle next to the person's name, and it will turn green.

Switching between the classes is done by clicking on the above tabs. Also the user can go to the previous/next week by clicking the blue arrows next to the class information (the first line of text). There is always a possibility to go just one week forward and then go back - as there is no need for archiving the data, and there's possibility to sign up only for the upcoming classes.

On the right, there are two buttons: "Schedule settings", which will be described later, and "Print", which allows to print the current list. There's also panel with current date and time, which we thought will be useful to the user.

After clicking the button "Schedule settings", a new window will appear for adjusting the classes information. The user is given a possibility to edit the classes' time, day of week, instructor's name, level, room, ... All the changes made in this window, after clicking "Done!" button, will affect both thetabs and the short fold-out schedule. Below is the picture of this window:

Each class is represented as a row in the table. To add a new row, the user needs to press the "New class" button, to delete existing one, there's a cross in each row for deleting. To edit the information in each cell it is enough to double click on the cell and edit the information. To move the class up/down, the user can use the little arrows in each row.

The user can navigate away from this window by clicking "back", then no changes will be made to the schedule.

This prototype we were going to show the user, and in process of pluralistic walkthrough evaluate our prototype.

Affinity diagram

Yesterday we have also created the affinity diagram for our project. We began with identifing the main problem:

How to create an easy-to-use electronic booking management system for ISLO?

We came up with several questions that should help us to generate ideas during the brainstorming. These questions are:
1. How to provide an easy access to various lists?
2. Network system or stand-alone?
3. How to create an easy interface for managing booking lists?
4. How the list should look like?
5. How to modify the bookings?
6. How to mark who has come to aerobic session?
7. What to do with obsolete list?
8. How to make attendance list available for the teacher?
9. How to manage waiting list?
10. How to see multiple lists at the same time?
11. What electronic platform should we use?
12. How to design user-friendly interface?
13. How to make the calendar available if there is no electricity?
14. How to input hew schedule? What to do with old one?
15. How to get the new list for the next week?

Then we proceeded with brainstorming. Each of us individually wrote down our ideas on post-it notes. Then we placed the notes on the wall in the random order:


After that we rearranged them in the groups based on similarities:


We named the groups as follow: Managing lists, List's outlook, Functionality of the system, Interface design, System design.


We discussed our division and made small adjustments:


And the affinity diagram was ready:


The next steps will include creating the personas and first draft of the prototype.

Work flow models

Yesterday our group spent productive evening on creating work models and affinity diagram. After analysing the interview transcript and videos we decided to go with three kinds of work models: flow model, sequence model and artifact model.

We began with the flow model.

The flow model describes the actions and tasks performed by the office worker concerning bookings. The office worker is the main person who is responsible for managing booking. She has to interact with customers and aerobic instructors.

Then we created 4 sequence models that represent the following actions:
New booking


Cancel booking


Change booking


Give out the pass


After creating the sequence models, we created the artifact model as well. The picture is shown below:
The original paper file:

All the models are first drafts and they may require some changes.

Project plan and Project focus

Here we present our project plan and project focus:

Project Plan

1. Client information

ISLO is an Eastern Finland Sports Institute based in Joensuu. The institute promotes participation in sporting and fitness activities for all ages in the region of eastern Finland. It offers educational programs and services in a variety of sports and fitness areas as well as training courses in fitness. ISLO is part of the Finnish sports and fitness networks. It is one of three regional sports institutes in Finland and it is maintained by the Eastern Finland Sports Institute Incorporated, which belongs to City of Joensuu.

Apart from sport and fitness trainings ISLO offers additional services such as: aerobic, accommodation, dining and solarium. Aerobic is offered every day in the late afternoons and evenings. Anyone can participate in the classes. There are 16 different classes to choose from. A customer can buy a single entry ticket, monthly ticket or season ticket. Three classes Body Pump (Pumppi), Step Pump (Pumppi Step) and GymCircut (Kuntosalicircuit) require pre registration due to limited amount of equipment (free weights-plates, barbells and an aerobic steps). The booking can be done one week before the class by phone or by visiting ISLO office. The list of registered participants is kept on paper in a file. We will investigate the possibility of designing an electronic system for booking the aerobic class at ISLO.

In this document "user" refers to ISLO and more particularly the term "users" refers to the people working in the club.The term "customer" describes a person willing to participate in a aerobic session at the club.

2. Purpose of the observation

The purpose of the observation is to conduct contextual inquiry. By observing and interviewing the users we will collect the data that will help us to understand the current paper based system and design equally good or better electronic system. We hope to gain an understanding of how the users solve problems encountered while using the current system and what needs they have.

3. Workforce and tasks

Moderator: Monika Zych-Laine
Interviewer: Monika Machunik
Observer/recorder: Paweł Niechoda

The Contextual inquiry script

The first step is the conventional interview. We introduce ourselves and explain in detail the purpose of our inquiry. We promise confidentiality and start to record. We explain to the user that her work is the priority and we want her to guide/teach us through her work and correct our mistakes. Then the interviewer begins with a couple of general questions about the user's work. The interviewer also asks about the opinions on the tools that the user uses. We will try to create a partnership relationship between us and the user. This phase should last for not more than 10-15 minutes.

The second part is explaining to the user the main principles of the contextual interview we want to conduct. We ask the user to do her job as usual, and describe what she is doing. We notify the user we want to ask questions during her job and we point out that she should tell us if the moment is not good for explanation and make us wait. This part should take only about 30 seconds.

After this is the main part of the inquiry - the user does her job and we observe it and try to interpret it. In case of any doubts we ask in order to clarify the problem. If there is not enough customers willing to book an aerobic session, we ask the user to make some fictional booking (or change/remove a booking). The length of this phase depends on our needs, but it should not exceed 30-35 minutes.

The last part is the interpretation of our observations. We describe to the user how we understood her work, and user gives feedback. If there are any misunderstandings, user should explain and clarify them. This phase should last up to 15 minutes.

4. Times and dates

The observation will take place on Thursday, February 5th 2009 at 10 am.

5. Tools needed

Notepad, pen, digital camera, voice recorder

6. Focus questions

The questions will focus on the users' activities connected with bookings and managing the bookings of aerobic classes. We will also try to discover the strengths and weaknesses of the existing system. The planned set of questions we intend to ask is as follow (in no particular order):

• How often do you use computer? Are you familiar with web browsing, using email box, word processor?
• How many bookings (changes/removal) do you do approximately per day/week? How long does it take you to deal with one customer?
  
• What do you find the most annoying while making new (removing/changing) bookings?
• Do you keep the old data? What are the reasons for doing so?
• What do you like about the current system?
  
• What kind of data concerning the client do you need while making (changing/removing) a booking?
• Who is allowed to make/change the booking?
  
• How many people usually do the bookings at the same time? Do you have any other departments where it is possible to book the classes?
  
• During what hours it is possible to book/change/cancel bookings?
  
• What kind of needs do you have for the new system?
• Describe what have you been doing today since you entered the work

In addition to contextual inquiry methods we may consider using other methods that will help us to find the real roots of actions. For example, PD methods, the why-why-why method.

7. Areas and tasks to observe

We will focus on the current system, users, their current environment as well as their attitudes towards computerized systems.We will focus on the ways the work is currently being done:

• Booking
  
• Changing of bookings
  
• Removing of bookings
• Communication between customers and interested parties (e.g. aerobic instructors, aerobic participants, etc.)
  
• Customer information
• Maintaing and managing the current data
  
• Weaknesses and strengths of the current tools
  
• Visual appeal of the current system
  
• The layout of existing paper schedule
• The type of customers' data stored in the file (e.g. names, telephone numbers, if this is the first visit, etc.)
• The order of filling in columns, as well as possible dependencies between the data in columns
• Possible exceptions in handling particular customers
• The environment in which the users' work is being done (the amount of noise, if the users work in a rush, etc.)
• The way of communication between the user and the client (e.g. if the customers come to the club in person too book a visit or maybe they phone or write an email)
• The level of computer skills of the users
• Possible restrictions resulting from possible disabilities of the users (e.g. color-blindness, poor eyesight, ...)
• Possible need for concurrent access to the data
  
• Any other issues regarding the existing system introduced by the users during the interview

Project Focus

1. Current System

Currently ISLO is using paper based system for booking aerobic classes. There are three classes that require booking: BodyPump (Pumppi in Finnish), StepPump (StepPumppi in Finnish) and GymCircuit (Kuntosalicircuit in Finnish). BodyPump takes place on Wednesdays 7-8pm and Saturdays 4-5pm, StepPump takes place on Mondays 7-8pm and GymCircuit takes place on Tuesdays 5:30-6:45pm. Each class on each day has a separate registration form. A registration form is an A4 paper sheet with information about classes (name, day, time) and two tables. The first table is meant for the bookings and consists of 45 cells (as there are 45 places) where customer information (first and last name) is stored. In case the first table is full and there are still more customers willing to participate in the classes they can put their name and phone number to the second table which is meant as a 'waiting list'. All the registration forms are kept in one folder. The forms in the folder are separated with interleaves. When a person willing to make a booking, opens the folder, he/she is required to choose an interleaf that corresponds to the class that he/she wants to make the booking for. The bookings can be made by a person working in an ISLO office or by a customer visiting the office. The customer can ask for the registration folder and put by herself her name on the list. If the customer is not able to visit ISLO office, she can call and make the reservation by phone. In the same matter changes and cancellations are being done. If the list is full (i.e. all the places are booked) a customer can put their name on the waiting list. In such case, if there is a cancellation from the original list, one of the users will call to the person on the waiting list and inform that there is place available. If the person is still willing to take part in the class, her name is moved to main list and erased from the waiting list. The cancellations can be done the latest three hours before the class starts. Before the class, a registered customer has to come to the office and obtain a pass for the class. The pass for the class is given by the user who also marks on the list (by using colorful highlighter) that the person has picked up the pass on the list. The passes are then collected at the beginning of the class by the aerobic instructor.

2. Presumed Solution

Our goal is to design an electronic system that would replace the existing, paper based one. The solution introduced to the users should be equally good or better than the existing one. By equally good we mean that it should not be more time consuming that the current. In addition, it should be at least as easy to use as the current one. Currently, both the user and customer can make the booking so the new system should also take this into consideration.
The main functionality of the system will be: booking the class, removing the bookings, and changing current bookings. If needed, we will extend the functionality, by adding features supporting users' work. We will also explore new needs for any additional functions that might be needed.

3. Supported Tasks

The new electronic based system should have the same main features that the paper based systems. Users should be allowed to do the same tasks as in the paper based system. The features can be categorized as:

• The main features:
• managing bookings for aerobic classes
  
• The necessary features:
• booking time for aerobic classes
  
• editing existing entries:
• changing the time
• changing the place
• canceling the classes
• browsing existing entries
• removing the entries
• searching/filtering the entries by
• class
• date
  
• customer data
• The desirable features:
• editing existing entries:
• changing the aerobic instructor
• changing the client data
  
• searching/filtering the entries by
• place
  
• viewing the entries by day/week/month
• support for concurrent access to the data
  
• automatic notification for the clients (e.g. by email) in case of cancellation or changes of the classes

4. Opportunities and risks

The electronic system can provide a quicker and more convenient way of managing the booking. Furthermore, the storing and archiving the data will be more comfortable and secure. We hope to design the system that will allow concurrent access to the registration.The system may also decrese the amount of work required in managing the bookings. Moreover, if the system will be online, it would allow the users the remote managing of the bookings.

The main risks of the new system is that it will be too difficult to use and the user will not be willing to learn the system. What's more, the user may be too used to the old system and even though the new system will be easier and more efficient to use, he/she will not want to switch. Another risk lays in the fact that due to too many available functions, the GUI might become too complicated and not intuitive. The users may also fear the data breach and loss in the new system. In addition, the new system may be too expensive for the users.

As for the risks of the project there is a great danger of falling into fixed way of thinking about the design of an electronic schedule, as there is a lot of existing solutions for similar purposes (e.g. google calendar). Additionally, we may overlook important aspects of the users' work by regarding it as being predictable. An example of another risk is that the user will not be willing to cooperate as we won't implement the solution and they may not be interested in the results. Furthermore, there might be not enough communication between the client and the interviewer or we may run out of time.

The client finally found

Finally, we have found the client. The manager of the aerobic club replied and he agreed on us doing the project at his club. We have also got a positive answer from Monika's friend, but it turned out that except from paper-based calendar she is also using the electronic calendar in her mobile phone, and that is why we decided on the aerobic club.

The full name of the place is the Eastern Finland Sports Institute (ISLO).

We have also agreed on an observation which will be held on next Thursday, at 10am.

Searching for a customer continues

During past few days we have visited a few potential customers:

- Pizzeria in Länsikatu 18 (they do not really use booking system, not good English)
- StresAway clinic in Science Park (they already use electronic calendar)
- Aerobic club (we need manager's permission. We were giving his email and now we are waiting for reply)

So far not much luck.

Finding the client

Today in the morning we visited Palloilukeidas to find out if we could make the project for them. Unfortunately, the person who we talked with (it was some sort of manager) did not agree to be part of the project. His explanation was they will have soon computer based time management system and they didn't need another one. We tried to explain that we won't implement the system but we will design how it should be like but it didn't help much. It was a big pity because we saw their current paper based system and it looked like a perfect example for this project.

Monika and Pawel also paid a visit to the hairdresser and beauty salon located in Science Park. Unfortunately, the woman at the hairdresser did not speak English well and there could be some serious language barrier when doing the project. At the beauty salon, the owner was concerned about her customer data and wasn't eager to participate in the project.

We are a bit concerned that finding a customer will not be such an easy task. I have contacted today my friend who is a photographer and has her own company. She works mostly with freelancing tasks. Let's see what she answers.

Today we have also distributed the responsibilities in our project. Monika ZL is project manager, Pawel is analyst and Monika M is designer.

Introduction

MMP group consists of Monika Machunik (Monik), Monika Zych-Laine(Monka) and Pawel Niechoda. The name of our group comes from the first letters of our first names. At first we wanted to do the project "Digital Life-stories for Seniors" but due to some language barriers we were forced to switch to the first topic which is designing an electornic time management system for someone who uses paper based calendar.

We have given some thoughts as for the client and decided to try with the Palloilukeidas. It is a place with indoor sport facilities. The facilities can be rented for an hour by individuals and/or companies. Last time I have visited there they used paper based calendar. Hopefully, we will manage to pay them a visit still this week and check the possibility of cooperation.

The posts regarding the project will have a tag "project" and the diary of the course posts will have a tag "diary" and will be signed by the author.