; A Ubiquitous System for Booking Taxis.pdf
Learning Center
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

A Ubiquitous System for Booking Taxis.pdf


  • pg 1

A Ubiquitous System for
    Booking Taxis
EECE 418: Assignment 4b – Pass 2 Portfolio
           Team 1: Mega Death Squad
             Yun-Yi Chen 24887051
          Addison (Ace) Marzo 27087055
             Mike Neufeld 43529007
            Russell Kramer 29685054

                                           Table of Contents
1.0 Redesigned Prototype………………………….........……........................................                                                   3
       1.1 Redesign Rationale…..…...…......................………………………….……….                                                             3-4
       1.2 Prototype Illustrations…..…...…......................………………………………..                                                         5-6
2.0 Evaluation Protocol.....................................................................................................            7
3.0 Evaluation Results................................................................................ .....................            8
       3.1 Subjects..................................................................................... .......... ..............     8-9
       3.2 Final Design Rationale and Discussion.............................................................                           9
       3.3 Reflection..................................................................................... .....................     9-10
4.0 Resource Management………………...………………….........……..........                                                                         11-12
APPENDIX A: Study Instruments
APPENDIX C: Consent Forms
APPENDIX D: Pass 1 document

1.0 Redesigned Prototype

1.1 Redesign Rationale

     We have learned a substantial amount about our design through our Pass 1
submission and design review.       Overall, we believe that our concept is realistic
and applicable to the real world, however, simultanously there are various flaws.
The most important feature in our design is the real-time GPS status of a Taxi Driver.
A source of one of our main flaws is the method of accessibility, kiosks. After some
discussion, we decided to shift our design to one of our previous ideas, wireless touch
screen devices, namely the iPhone.     The iPhone has many features that are
symbiotic with our plans for a Taxi Booking interface.

      One of the main issues with a kiosk system is queues. At an airport, there will
be a large influx of people that need a Taxi, and with our previous design, a kiosk
system would be difficult to support a large user base. With an iPhone, the whole
issue of queues is entirely negated, but results it in being dependant on users to have
access to an iPhone. Many users will prefer to book a taxi at a sheltered location, as
opposed to an openly visible kiosk, something an iPhone offers by being a wireless
device. Similarly,due to the nature of an iPhone’s wirelesss capabilities, the taxi
service will be accessible everywhere with a wireless network.        With respect to
building the hardware and developing the software, the iPhone will naturally reduce
costs. The built in touch screen and GPS correspond to our Taxi system, while the
iPhone software tools means minimal software costs. As with our low fidelity
prototype, a strong emphasis will be placed on the real-time GPS updating of the taxi
driver. It is critical that the user maintains a necessary level of trust and can rely on
the taxi booking service at times of need.

     Our current design focuses on an easily understandable touch screen interface
that offers real time GPS Taxi status. Although our focus is now on the iPhone, the
overall portability of our design is widespread. After completing an iPhone design,
extending the design to any touch screen wireless devices such as PDA’s and
Blackberrys is simply a matter of coding it for the respective hardware. Furthermore,
we can also adopt our system to be accessible by the worldwide web, further
expanding the methods of accessibility. By broadening the number of interface
mediums, our design will have a stronger and more accessible user base.

       Originally in our kiosk system, we intended to implement a form of “login”

for more experienced and frequent users. We are going to transfer that over to the
iPhone application, but we are going to rely on the standard username/password
convention. Because of the large possibility for expanding the interface mediums,
we want users to be able to access their accounts regardless of their wireless device
and not create multiple accounts for different devices.

     Our plan for the “dispatcher” interface is for there to be none. We feel that with
the evolution of GPS tracking, we can create an automated dispatcher. When a
customer books a Taxi with our interface, the dispatcher will get the GPS location of
the customer and find the closest available Taxi in the vicinity and send it to the
customer. Our automated dispatcher will also take into account many variables such
as bridges, average traffic speed, and taxi driver density. An automated dispatcher in
some cases will be more reliable than a manual dispatcher, because an automated
dispatcher can easily sit idle in low-peak times, while a manual dispatcher will
naturally get impatient without doing anything. Also, the automated dispatcher can
be in service nonstop, while manual dispatchers may refrain from working late hours.
Overall, we feel that an automated dispatcher is coherent with our technology and
syncs well with our wireless based system.

     We intend to have an extremely simple taxi driver interface.   It will comprise of
a main GPS screen that will display the customer’s pick up location and the taxi
drivers location. Additionally, there will be a confirmation button that a taxi driver
will have to touch when the dispatcher selects their vehicle for a pick up. Upon
confirmation, the iPhone will then tell the customer their taxi is coming and their
location with estimated time remaining.

     Our main prototype, the taxi booking interface for the customers will be made in
Adobe Flash, allowing for a great deal of interactivity with users in our evaluations.
The main consideration we will need to be aware of is if we do not have access to a
touch screen computer, that some of our test results could be skewed because of the
usage of a mouse. The taxi driver interface will be relatively straightforward, but to
keep it consistant, we will be presenting it in Flash as well. For the purposes of a
demonstration and stakeholders, the automated dispatcher will have some screenshots
of how it operates, or if time permits, a Flash demo.

1.2 Prototype Illustrations

Screen 1: The iTaxi application is         Screen 2: If the user has not yet signed   Screen 3: If the user chose to simply
available to the iPhone user from the      in or has not chosen to automatically      get a taxi, the system will indicate that
main screen.                               sign in, they see a map showing their      it is arranging the cab ride.
                                           current location and the proximity of
                                           any cabs in the area. They may choose
                                           to simply get a taxi, or sign in.

Screen 4: Once the system has arranged     Screen 5: Once the cab has arrived at      Screen 6: If the user chooses to sign in,
the ride, the nearby cabs are hidden and   the requested location, the system         the signin screen is displayed.
the user’s cab is highlighted and shown    indicates this to the user.
moving towards the user’s location.

Screen 7: After choosing to sign in, the   Screen 8: If the user entered an invalid   Screen 9: If the sign-in was successful,
screen indicates that sign-in is in        username or password, they can either      personalized options are displayed to
progress.                                  try again or cancel the sign-in process.   the user. By default, the Get A Taxi
                                                                                      button will still simply request a taxi to
                                                                                      the current location ASAP.

Screen 10: If the user chose to change
any of the booking options, a list of
likely options is presented.

2.0 Evaluation Protocol

We will be performing an experiment that would allow us to evaluate the
effectiveness and preference of our proposed Taxi Booking Interface. Our user
evaluation size will be roughly five users or more given time allowance. We will be
asking the user to perform two sets of tasks, each one phoning a Taxi company and
doing a similar task with our interface. Our hypothesis are as follows

Null Hypothesis #1 – The basic operation of our new interface will , on average, take
the same amount of time as the basic request of a Taxi by phone

Null Hypothesis #2 – The advanced operation of our new interface will, on average,
take less time than an advanced request of a Taxi by phone.

Null Hypothesis #3 – Users will prefer our interface

The independant variables of our test will be the taxi request specifics, such that it
will be the same both by phone and interface.
The dependant variables of our test will be the time it takes a user to perform a task.
It should be noted that we are not concerned with learning curve for this experiment.
The apparatus we will need to prepare includes a computer with only a mouse
peripheral, our taxi interface in a flash file, a cell phone, a task list, questionnaire, and
consent form. We will also need one of us to supervise and be there to observe and
take notes.

The process we will undergo is as follows:
   1. Inform the user about the experiment and the information on the consent form
   2. Let the subject know what he/she will be doing
   3. Give the user the first task list and time until completion
   4. After a short ~2 minute break, give the user the second task list and time until
   5. After the last task, a short questionnaire will be issued
   6. Review and analyze performance and record all information

Task Sets and questionnaire will be described in the appendices

3.0 Evaluation Results

3.1 Subjects

     Our user base was a small subset of users who casually use Taxi’s at their
own discretion. Our system was designed to be used by all taxi enthusiasts,
however, it would probably be more applicable to daily/weekly Taxi users, a
part our user base did not cover. One of our initial users in Pass 1 was used in
our user evaluation for Pass 2. Naturally, this could cause some implications
if they have been part of the design multiple times. However, our design
shifted from a kiosk system into a handheld/iPhone based system. This leads
us to believe that a repeat user in this circumstance will not be entirely
detrimental to the project.

3.2 Final Design Rationale and Discussion

The quality of the interface design is fair. Our experiment shows that it is faster for
the users using our system to order taxis than using the traditional telephone booking
system. It also shows that the users find our system easier to use than telephone
bookings. However, there are several places in our interface which are not
user-friendly. Also, our system will need more functions in order to meet some
special request and to have all the functions that the existing telephone booking
system has.

The parts of the design work well are real-time taxi tracking, centering the taxi tag or
the user’s current locations tag, and the overall time taking for booking a taxi by our
system. The real-time taxi tracking allows users to know exactly where their taxis
are and how far the taxis are away from their current locations. The feature largely
gains the trust from the users. The users do not have to worry about their taxis are
not coming on time and their schedule will be delayed. Also, they do not have to
wait outside of their apartment or standing beside the window of their house to watch
if the taxis are here or not, since they know exactly when the taxis will arrive. On
the other hand, the centering the taxi tag or the user’s current locations tag is
convenient for the users. The users do not need to worry about lose the taxi tag is
they have not watched their cell phones for a few minutes. Furthermore, the overall
time taking for booking a taxi by our system performs well in our experiment.
Almost all the time taken to book a taxi by our system is lesser than the time taken by
the phone.   One of our subjects even spends 69 times more time on booking a taxi on

the phone than booking a taxi by our system.

The parts of the design needs improvement are the username and password input
method, username and password history, and special requests. Currently, our system
does not allow the users to input their usernames and passwords on the computer
keyboard. Instead, the users have to use the keyboard on the screen, which slows
them down by a few seconds. Also, it would be better if the system can remember
the username and password of the user of the cell phone. Our future plan is to
implement the wheelchair option as well as more than five passenger option. It will
allow the all the users to use our system as the traditional system but in a more
efficient and reliable way.

We believe that the system would work well for our identified users and tasks, if the
interface is more user-friendly. Since our identified users for the last iteration is
aiming for users who do not have disabilities and users with less than five passengers
at a time. Our current interface covers almost all the functions needed for our
identified users. In our questionnaire, it also shows that our subjects think our
system is easier to use than the traditional taxi booking system.

3.3 Reflection

This project has been somewhat useful in demonstrating the user-centered
design process. The benefit was limited by the amount of time available and
the nature of the project itself. The project didn’t lend itself well to
quantitative evaluation against existing methods. Possibly the biggest
factor in the utility of our interface is the underlying responsiveness of
the taxi companies, which is a factor no matter what interface is
implemented. Having to telephone cab companies in order to compare the
process against our interface was an awkward experience for test subjects,
and the information collected was marginally useful, especially given the
small sample size.

The most valuable information we collected was qualitative, and it came as a
result of the heuristic evaluation and design reviews. The biggest change
that resulted from this information was our abandoning of the kiosk concept
and focusing instead on an iPhone-based design. As a result of the heuristic
evaluation and the design reviews, we found we could no longer justify the

kiosk idea and that pursuing it would only continue to confuse and de-focus
our efforts.

While much of the information we gathered was useful, quite a bit wasn’t.
For example, there was a lot of focus on details of the low-fidelity
prototype that weren’t material to the product. Another concern was the fact
that we aren’t actually using an iPhone, or a touch screen, to evaluate the
device. In the interest of keeping the amount of hassle to a justifiable
level for purposes of this course, we feel that such a question is beyond
the level of fidelity needed to demonstrate the user-centered design
process. Sure, that might be unacceptable in the real world, but if we were
getting paid for this we’d just go buy an iPhone.

Our design process could have benefitted from more incremental
change-evaluate cycles. It would have been better if we had come up with
more candidate designs and compared them. This would have likely opened the
door to more useful quantitative data, but it still seems like the most
useful information for this kind of project would be qualitative suggestions
and observations by users.

Despite the limitations we ran into while working on this project, this
course has brought to our attention many new possibilities for developing
user interfaces and given enough time and appropriate justification we are
likely to make use of them in the future.

4.0 Resource Management

     Similar to our initial pass, we have continued to meet up to discuss the roles of
individual members of our group. Upon the completion of our discussions, we split
up to do the designated tasks.

Yun-Yi Chen
Redesigned Prototype – Evaluation Protocol – 1 hour
Pass 2 Portfolio – Analysis of Results – 2 hours

Total Individual Time: 3 hours

Addison (Ace) Marzo
Redesigned Prototype – Redesign Rationale – 1 hour
Redone Evaluation Protocol – 1 hours
Pass 2 Portfolio – Editting, Formatting, Subjects, Resource Management – 3 hours

Total Individual Time: 5 hours

Mike Neufeld
Redesigned Prototype – Prototype Illustrations – 2 hours
Pass 2 Portfolio – Evaluation Results, Reflection – 2 hours

Total Individual Time: 4 hours

Russell Kramer
Redesigned Prototype – New Flash Prototype – 2 hours
Flash Prototype – Optimized prototype for experimental testing – 4 hours

Total Individual Time: 6 hours

Group Meetings

Redesigned Prototype – Discussion of redesign, brainstorming ideas, delegating
work – 3 hours
Professor/TA discussion of design and post meeting discussion – 2 hours
User Evaluations – 1 hour
Demo preparation – 1 hour

Presentation preparation – 1 hour
Pass 2 Portfolio – Planning/Delegating Work – 1 hour


Total Group Time = 9 hours/person * 4 persons = 36 hours
Sum of Individual Times = 18 hours
Total Time Invested = 54 hours
Assuming an individual would earn $72000 annually, with a 2080 hour work year, it
amounts to ~$35/hr

Total Cost of Pass 2 = 54 hours * $35/hr = $1890

Appendix A -- Study Instruments

The two tasks sets the user will perform are:

Task Set 1
   a) Phone the Taxi Company at <Insert Taxi #> and ask the operator how long it
       would take to get a Taxi at <insert location>. Ensure that you are just asking
       how long and not ordering a Taxi
   b) Order a taxi with our user interface without logging in

Task Set 2
   a) Phone the Taxi Company at <Insert Taxi #> and ask the operator how long it
       would take to get a Taxi at <insert location 1> and if there is an approximation
       of how long it will take to get to <insert location 2>. Ensure you are just asking
       for how long and not ordering a Taxi
   b) Login to our Taxi Interface with <insert username/password> and order a taxi
       with the following parameters:
       Starting location: <Insert location>
       Arrival Time: <Insert Time>
       Destination: <Insert Location>


1. How often do you use a Taxi (select most applicable)?
   a) At least once a day
   b) At least once a week
   c) At least once a month
   d) At least once a year
   e) Only on special occasions (eg. Airport departure/arrivals)
   f) Never

2. How long does it usually to book a taxi?
   a) Less than 2 minutes
   b) 2-5 minutes
   c) 5-10 minutes
   d) More than 10 minutes

3. How often does the taxi arrive on time?
   a) 0% of the time
   b) 1-50% of the time
   c) 50-99% of the time
   d) 100% of the time

4. On a scale of 1-10, how would you rate the difficulty of booking a Taxi by phone
1    2   3    4    5    6   7    8    9    10
Easy               Average                 Difficult

5. On a scale of 1-10, how would you rate the difficulty of booking a Taxi by the
1    2    3   4    5    6   7    8    9    10
Easy               Average                 Difficult

6. Please provide any additional comments about the new interface


         Task         1a               1b               2a                             2b

USER 1   Time Taken   0:28             0:09             1:08                           0:57
         Response     "5-10minutes"                     "12 minute travel time"

USER 2   Time Taken   0:24             0:08             1:57                           1:28
         Response     "6 minutes"                       "blah blah blah blah"
USER 3   Time Taken             4:21            0:08                            6:38               1:30
USER 4   Time Taken             8:00          00:07.7                       15:00             01:18.5

                                                                  USER 1   USER 2   USER 3   USER 4

1.   How often do you use a Taxi (select most applicable)?
a)   At least once a day
b)   At least once a week
c)   At least once a month
d)   At least once a year                                         D        D        D        D
e)   Only on special occasions (eg. Airport departure/arrivals)   E
f)   Never

2.   How long does it usually to book a taxi?
a)   Less than 2 minutes                                                   A
b)   2-5 minutes                                                  B                 B
c)   5-10 minutes                                                                            D
d)   More than 10 minutes

3.   How often does the taxi arrive on time?
a)   0% of the time
b)   1-50% of the time                                                     B        B        B
c)   50-99% of the time                                           C
d)   100% of the time

4.   On a scale of 1-10, how would you rate
the difficulty of booking a Taxi by phone             4   4   5   6
5.   On a scale of 1-10, how would you rate
 the difficulty of booking a Taxi by the interface?   2   4   4   6
                                                                  It is difficult to login because the user is
                                                                  unable to use keyboard. In stead of
                                                                  moving around the "pin" on the map, the
                                                                  user has to realize that has to move the
                                                                  map in order to change location. It would
6.   Please provide any additional                                be a lot easier if the user can move the
comments about the new interface                                  tag/pin or type the address instead.
APPENDIX C: Consent Forms

APPENDIX D: Pass 1 Document

To top