TRANSS-UM
Transportation Resource Alternatives for Students/Staff
Interface Design Report
- Augustine Adedeji
- Gabriel Mankovich
- John Brodrick
- Jorge Murillo
aadeadedeji@yahoo.com
parad0x@umd.edu
jbrodric@umd.edu
toti@umd.edu
November 27, 2006
1
Abstract
This semester, students taking CMSC434 – Introduction to Human Computer Interaction,
were asked to design and create an interface that would result in lowering traffic
congestions in and around College Park. The ultimate goal is to lower the number of cars
that travel to and from the University, thereby reducing the traffic congestion as well as
reducing the problems that occur as a side effect of traffic, such as pollution from
emissions. TRANSS-UM is a system that seeks to increase the use of public transit by
students, faculty and staff of the University of Maryland. It integrates the functionality
provided by the transportation systems that service College Park as well as the
transportation services provided by the University (Shuttle-UM). TRANSS-UM provides
an interface which users can use to plan trips to and from school using public
transportation, view a bus/ rail timetable as well as current GPS location, compare costs
of public transit versus driving, and locate a bus-stop/station closest to a particular
location.
2
Credits
Augustine Adedeji
 User needs: Provided concrete tasks examples and description
 References: Provided three references
 First Design: Completely designed one low-fidelity prototype
 Task List and Questionnaire: Provided list of task and description
 Usability test: On one subject
 Redesign: edited parts of final interface design
 Design Report: Responsible for conclusion, acknowledgement, references,
reading and compilation of design report
 Coordinated team activities.
John Brodrick
 User needs: Provided concrete tasks examples and description
 References: Three references
 First Design: Designed second low-fidelity prototype
 Task List and Questionnaire: Came up with questionnaire
 Usability test: On one subject
 Redesign: initial design of commuter parking and find a stop in high-fidelity
prototype
 Design Report: Wrote presentation of design section
Gabriel Mankovich
 User needs: Locate a Bus, Cost Comparison
 References: 2 references
 First Design: Created transition diagram and flow chart for
input/output for individual mockup. Then translated low-fidelity mockups (in
combination) into hi-fidelity-ready flash interface.
 Usability test: performed usability test on three subjects.
 Redesign: interface aesthetics from prototype.
 Design Report: Development Process
Jorge Murillo:
 User needs: Introduction and system requirements
 References: locate 3 references of related work
 First Design: find images that may be used for final interface. Compose the
transition diagram.
 Task List and Questionnaire: Compose two tasks scenarios. Compose posttest questionnaire
 Usability test: perform usability test on one subject
 Redesign: responsible for the major part of the final interface design
(functionality and aesthetics).
 Design Report: Abstract and Introduction.
3
Introduction
Public transport is currently under utilized whereas the number of trips made via
automobile continues to increase. Statistics show that “around 10% of journeys are made
by public transport, and almost 7 times as many are made by car” (www.chi2007.org).
The same is true of public transit systems that service the University of Maryland,
College Park campus and surrounding areas such as Metrobus/Metrorail, Ride On, The
Bus, and Shuttle-UM. A greater portion of the commuters associated with the University
of Maryland (students, faculty, and staff) elect to travel to and from campus via personal
vehicle. The University provides these commuters with over 21,000 parking spaces
(www.dots.umd.edu), meaning that there exists the possibility of having over 21,000 cars
within University boundaries at any given time. Both the under utilization of public
transport and excessive reliance on personal transportation by students, faculty, and staff
of the University of Maryland result in dreadful traffic congestions in College Park.
There are other residual problems that arise because of this high traffic volume. Such
problems include: higher level of chemical emission and pollution, delay in public
transportation arrival time, as well as unnecessary public transportation system financial
spending. For example, a bus will run its schedule route even if a total number of zero
passengers board the bus, thus the transportation system is faced with expenses such as
gasoline costs for an “unnecessary” trip. Traffic congestions also present similar
unnecessary expenses. “Nationwide, traffic delays in 2002 wasted 5.6 billion gallons of
fuel. These delays are estimated to have cost employers $63 billion in lost productivity”
(Indiana University News Release 2004).
The convenience of driving causes students, faculty and staff to continue to rely on
personal transportation. Additionally, there is no current system that integrates the
services provided by the public transportation systems which service the College Park
area with the University’s shuttle system; thereby providing a complete, comprehensive
public transit informational system. Currently commuters must access multiple systems
in order to find a potential itinerary that includes use of public transit and the University’s
shuttle system. TRANSS-UM looks to fill that vacancy. TRANSS-UM is the only
system that student, faculty, and staff commuters would need to access in order to plan
any trip to and from the University via public transport. It is a system that integrates the
services of all transit system, both public and school related, into one. It also provides
many features that improve the convenience of riding public transportation alternatives
such as comprehensive trip itinerary planners, current GPS bus and rail position locator,
information about outlying parking lots around the University campus, look up any
transit systems route map and timetable, as well as comparing the cost of public transit
versus the cost of driving. With this added convenience, commuting students, faculty and
staff members of the University are encourage to seek public transportation alternatives
to driving which they might not have previously been aware of. When a greater number
of students, faculty and staff use public transit to access campus, it results in less cars
being driven in the campus, thus helping to alleviate numerous traffic congestion
problems in College Park.
4
In the Washington Metropolitan Area there are a number of public transportation
resources available. These include Washington Metropolitan Area Transit Authority
(WMATA) which provide buses and metro trains, country bus systems, and numerous
web resources. Washington Metropolitan Area Transit Authority – WMATA currently
provides a similar system to TRANSS-UM but is limited to only metrobuses and
metrorails. Similarly, the Department of Transportation systems of the University of
Maryland school system, Shuttle-UM, as well as the Department of Transportation
system of both: Montgomery County, and Prince George’s County – Ride On and The
Bus respectively – provide analogous features to TRANSS-UM, however these systems
too are segregated and are limited to providing information exclusive to their system.
Aside from TRANSS-UM, there is no other system which integrates the functionality of
all public transportation systems that services the College Park area as well as the
University’s shuttle bus system.
Transitweb (http://www.its.dot.gov/transit_dev/introduction.asp) is a website that is
designed to bring together a variety of resources to help transit agencies better
communicate with their customers through websites and ITS-related technologies. The
website provides several case studies and reports of the optimal public transit integration
strategies and thus providing a potential blueprint from which to build the most optimal
TRANSS-UM interface. Transitweb also describes the basic necessary features that
customers come to expect from transit interfaces such as trip-planner, and route
map/timetables. It also provides information about optimal aesthetics and the minimal
spacing between text and images which most case studies reported as optimal for
displaying text and images.
TRANSS-UM makes use of GPS software equipped on buses and rails to provide users
with real-time global positioning of these buses and rails. Therefore, at any given time,
students, faculty and staff can access the TRANSS-UM system to determine the current
location of any bus, shuttle, or rail. NextBus (www.NextBus.com) is a company that
specializes in public transit global positioning. It is the company currently contracted to
service the GPS needs of the several public transportation system around College Park.
The company has contracts with Prince George’s County’s The Bus as well as
WMATA’s metrobus/metrorail systems.
By increasing the convenience of accessing multiple public transit information systems,
students, faculty and staff are expected to seek public transportation alternatives to
driving. As a result, the number of personal cars driven by the commuting University’s
population will decrease thereby reducing traffic congestion that occurs in and around the
campus, as well as the associated residual problems of such congestion.
5
Presentation of Design
Overview of Approach and Solution
When designing our interface, our group had several goals in mind. We all wanted to
create an interface which followed the eight golden rules of design that we learned in
class. Some of the rules that we paid particular attention to when creating our designs
were: strive for consistency, universal usability, reduce short term memory load, easy
reversal of actions, and internal locus of control. Following these rules would ensure us
that we would end up with a very easy to use and user friendly design. We wanted a
prototype that would allow users to complete tasks in a speedy and orderly manner. In
designing our interface kept in mind the vast pool of different types of users and tried to
accommodate each of them as best as possible. Overall, we wanted our interface to
improve upon current interfaces out available which are already set up to complete
similar tasks, and to integrate features of these interfaces in order to provide a one-stop
for commuters of all transit systems around College Park.
In order to accomplish these goals, we first worked on designing our interface. The first
step in designing our interface was to brainstorm some design ideas. In order to do this,
all four members of the group split up and drew their ideas for the interface on paper.
We created our initial designs separately because we felt as though we would be most
creative if we did not allow our designs to be influenced by the ideas of others. Once we
all had our initial designs created, we shared our ideas with one another. We found that
we liked things from each of the designs that we brought and because of this we did not
decide to use just one of the designs, but to combine different pieces of all of them. From
our rough initial designs we had enough ideas and enough variety of ideas to create two
low fidelity prototypes. We coded these up into flash so that the interfaces were
interactive. This way we could get a good feel for how well our interface works and be
able to determine which one we liked better. After testing out the two very different low
fidelity designs, we determined that one of them was sufficiently better and incorporated
some special features of the second interface into it. Once we agreed on the actual design
for the TRANSS-UM interface, we proceeded in creating a high fidelity prototype.
Transition Diagram
The solution that we came up with has a main menu located on the left hand side of the
interface. This menu remains constant regardless of what screen you are currently on in
the application. For the most part, the menu is use to navigate our program. The
transition diagram (Figure 1 – page 8) depicts the basic transitions to different pages on
our information system. As shown, all pages are directly accessible from the main menu.
This menu allows the user to get to any page in our interface from any page in our
interface. This allows for simplicity in that the user can spend most of their time
undergoing productivity rather than figuring out where to go. Access to all of the pages
is just sitting there in front of them at any point in our interface.
6
Some pages have direct links to other pages. An example is that from the “Commuter
Parking” page you are able to get to the “Plan a Trip” page. This is so that when the user
finds a commuter lot that they want to park in, they are then able to get directions to that
lot from wherever they are at the moment, and this information is displayed in the “Plan a
Trip” page. Even with these kinds of transitions which may become confusing to the user
as to their current location within the interface, the user cannot get lost because, as stated
before, the main menu bar is always displayed. With the menu bar always in sight, if
they do take a link somewhere and are unable to figure out where they went, all they have
to do is use the main menu to just jump back to where they were before.
You will also notice that each page has a link to a help page that lists specific help
information on that page. We created an environment so that no matter where you are in
our application, you always have access to a specific help page that has detailed
instructions on how to complete the task associated with the page you are currently
viewing. The help button is always available and is located just below the main menu.
Due to this fact, users will quickly remember its location and know where to go if they
are in trouble. This makes our interface very user friendly in that they can get instant
help information for problems that they are having. There is also no searching through
help files, like in many Microsoft applications which can be tedious and annoying if you
have trouble finding the help page that you need. This problem is eliminated with our
interface since each help page directly corresponds to the page currently accessed.
7
Homepage
Help
Help
Main
Menu
Trip
Planner
Results
Trip Planner
Map
Timetable
Results
Map/Timetable
Closest Stop
To Location
Bus/Train Locator
Commuter Parking
Cost Comparison
Help
Help
Results for
Commuter
Parking
Figure 1 – Transition Diagram for Interface
8
Design of Screens
Main Page
The transition diagram discussed in the previous section shows a lot of the intricacies of
our interface. However, there is a lot more to our interface than just what screens link to
where. In order to get a better understanding of how we designed our interface and all of
the features that we included in it, it is necessary to actually see the interface. Figure 2
shown below is a screen shot of the homepage of our interface. From the homepage, the
main menu is apparent and is located to the left. It is important to take note of this, as its
position will not change. The homepage is fairly simple, with an image of a metro bus at
the top left, and below is a quick blurb on the purpose of the TRANSS-UM interface.
The only actual functionality on this page is the “Trip Planner”. This is a highly
condensed version of the form that is located on the “Plan a Trip” page. When you fill in
the fields in this form and then click the “Plan Trip” button, it takes you to the “Plan a
Trip” results screen. Performing this action is exactly the same as going to the “Plan a
Trip” screen, inputting your query, and then clicking the submit button there. The reason
why we added this functionality to the homepage was because we felt that this would be
the most highly used part of our interface. We wanted advanced users to be able to plan
their trips quickly without having to jump to an extra screen. Instead, they can just open
up our interface, immediately input their query, and get results. This is one of the
features that produce an internal locus of control for advanced users. Another thing to
note on the homepage as with every page is the help button. This is the small yellow
question mark located just below the main menu. You should also take note of this
button as it is also visible from every page in our interface. Clicking this button from the
homepage will provide the user with some information on what the overall program does
as well as with some help on how to use the trip planner form on the homepage.
Figure 2 - Homepage of our Interface (See Appendix for Bigger Screen Shot)
9
Plan a Trip
The next page in our interface, proceeding down the items in the main menu, is the “Plan
a Trip” page (Figure 3 – next page). On this page, the user enters in a start location and
an end location and then clicks the button “Plan Trip”, taking them to a results page
which gives them directions on how to get between the two locations using various
means of public transportation (WMTA, Shuttle UM, P.G. County Bus System, etc.).
This is basically an extended version of the form found on the homepage. The only
difference here is that there are a few more options available to the user. These options
include the ability to select specific modes of travel and also the ability to navigate by
means of landmarks instead of solely using street addresses.
We designed this screen to have three separate sections to keep things organized for the
user. This also satisfies the golden rule of designing dialogs to yield closure. This
provides the user with an easy, step by step process to fill out this form. It is clear that
they should begin in the top section and then work their way down. In the top most
section, the user enters in the starting and destination address fields. Below these fields
are examples of how the fields should be completed. This satisfies two golden rules,
namely the prevention of errors and catering to universal usability. Inexperienced users
may need help in getting the correct syntax for the fields. Instead of having to go all the
way to the help section, an example is there right in front of them. This will prevent a lot
of first time users from having syntax errors when using our interface. For advanced
users, this is not in their way and they can still quickly enter in the information
unobstructed. We felt that something like a pop up message with the correct syntax
might slow down the advanced users.
The next section on this screen is the travel mode selection dropdown. With this
dropdown you can filter your results so that only the travel modes the user specifies are
used. This gives users a greater feel of control over the interface since they do not have
to filter through the results themselves. Finally, the third section is the date/time section.
This is where the user can specify exactly when they want to arrive at a destination, or
what time they plan on leaving. Depending on what time they enter in, the interface will
output different results due to factors such as rush hour, delays, or closings. The interface
will direct them to use the quickest routes available for the given time and day. Also on
this section of the screen, they have the ability to filter results so that a certain factor is
minimized. The options are cost, transfers, travel time, or walking distance. This feature
accommodates our different users. For example, the elderly may not want to walk very
far and thus can minimize walking distance, whereas a young businessman who is late
may want to minimize travel time.
From the “Plan a Trip” screen, once users fill out the form correctly, they then hit the
“Plan Trip” button. This takes them to the “Plan a Trip” results screen where their travel
directions are displayed (Figure 4 – next page). On this screen is a map with your travel
route highlighted. Below the map is a tabbed itinerary. This itinerary gives you three
different sets of directions in order to reach your destination. To switch back and forth
between the three different sets of directions you just click on the different tabs.
10
On this page we had a lot of information to display, and this affected our design greatly.
In regards to the itineraries, we felt that using a tabbed system would be the most
efficient way to display the different directions since that it saves a lot more space than
just listing them all out together. This also keeps the information neat and organized
instead of having the three different itineraries all over the screen. As for the map, we
felt it was better to keep the map zoomed in rather than having it zoomed out. So since
we had limited space to work with on this screen, we provided the user with scrolling
features for the map, so that the user could view other locations on the map easily. One
reason we kept the map at a high zoom level was because otherwise it would be hard to
see the highlighted route in our interface. In doing so, we accommodate all users such as
the elderly, who may have trouble seeing small objects. The design for this screen was
the best way we could come up with to display the massive amount of information on the
same page and in a neat and organized fashion. We feel very satisfied with the final
results.
Figure 3 - Plan a Trip Screen (See Appendix for Bigger Screen Shot)
Figure 4 - Plan a Trip Results (See Appendix for Bigger Screen Shot)
11
Map/Timetable
The next screen in the main menu is the “Map/Timetable” screen (Figure 5 – next page).
On this screen the user is able to retrieve route maps and timetables for particular stops.
In order to do this, the user just needs to enter in a route. On this screen there are two
ways to do this. The first way to do this is if the user does not know exactly what the
route is called that they are looking for. If the user falls into this category, then they use
the dropdowns in the topmost section of the screen to narrow down their choices. The
user would first select the system that they are interested in from the top most dropdown.
Examples of choices for the system are: Shuttle UM, Metrobus/Metrorail, Ride On, or
TheBus. Once the user has selected the system they want, then this will narrow the list of
available locations and routes in their respective dropdowns. Next, the user selects a
location for which they are interested in viewing a map and timetables. Selecting a
location in the location dropdown box will further narrow the list of routes that belong to
the system selected and that go through the selected location. From this set of routes, the
user is then able to select the route they desire and then can press “Submit”. This will
take them to the map/timetable results screen where they can view the map and list of
times for that route/location. The other option available to the user is if the user knows
the exact name of the route that they want, then they can enter that name into the “search
for:” field down in the second section of the page. This is for advanced users who know
exactly what they are looking for and do not want to bother with the dropdowns at the
top. After entering in their route, they then click on the “Find Timetable” button and
proceed to the same map/timetable results screen as with using the other method.
We designed this screen of our interface with two different methods to get the route maps
and timetables in order to accommodate both novice and advanced users. Novice users
may not have as much knowledge about the public transportation system as do advanced
users, and thus may not exactly know the names of the routes and their locations. All
they know is where they want to go and what system they want to take. This is why we
provided them with a quick and easy way to search the database of systems, locations,
and routes in order to find the route that they want. On the other hand, advanced users do
not want to deal with these extra steps since they already know which route they want to
view. This is why we provided them with a direct link to the results page. All they have
to do is enter in the route and go. Designing the screen this way makes it easiest for all
different types of users.
Once the user has entered in their results into the “Map/Timetable” screen, then they
proceed to the “Route Map and Timetable” screen which displays their results (Figure 6 –
next page). On this page the route map is displayed at the top and the time table for the
selected stop is displayed below. The map displays the highlighted route and also all of
the stops on that route. The timetable shows the times that the buses will arrive at the
specified stop going in each direction. The dropdown in the middle of the screen allows
you to select which stop on the route you are currently viewing, and making a new
selection will update both the map and the list of arrival times down at the bottom. We
decided to design this screen so that the viewable information is based off of a particular
stop for simplicity. The only thing the user needs to know is what stop they are interested
12
in and then they can find out exactly when the bus will arrive at that stop. There is no
looking at extensive charts or tables, as with the Shuttle UM’s current interface, which
creates an unpleasant user experience.
The way that we have this screen implemented reduces the short term memory load on
the user, which is another golden rule. Also, the back button allows the user to go back
and change the route they selected quickly, which satisfies yet another golden rule
allowing easy reversal of actions. Finally, just as we did with the “Plan a Trip” results
page, we kept the map at a high level of zoom in order to accommodate those who have
trouble seeing. The scroll bars provided allow the user to get to every part of the map
while it is zoomed in. This makes this screen universally usable by everyone and is why
we chose such an implementation over others.
Figure 5 - Route Map/Timetable screen (See Appendix for Bigger Screen Shot)
Figure 6 - Route Map and Timetable screen (See Appendix for Bigger Screen Shot)
13
Locate a Bus
The next screen on the main menu is the “Locate a Bus” screen (Figure 7 – next page).
All of the buses in our system are equipped with a GPS tracker so that we can instantly
find their location and current heading. Users can use this screen to find the locations of
the buses in real time. This allows the users to plan accordingly in order to catch the bus.
For example, if a bus is running late they will be able to notice this and thus take an
alternate mode of transportation to get to their destination.
There are two ways to search for a bus: by stop or by route. Searching for buses by stop
will display all of the buses on route to the specified stop. To do this, all the user has to
do is select “Bus Stop” in the “Search By:” dropdown box. Once the user does this, the
“System:” and “Filter by Route:” dropdown boxes disappear and the “Stop” dropdown
appears (Figure 8 – next page). The user can then select a stop of their choice and when
they hit the “Find Bus” button, their results will be displayed. The second method of
finding buses, searching by route, will display all of the buses on a specified route. This
task is accomplished by first selecting “Bus Route” from the “Search By:” dropdown.
Then they select the system they desire from the “System:” dropdown. This will update
the route dropdown box with the appropriate routes. Then the user selects the route that
they want and then hits the “Find Bus” button to get their results. When the “Find Bus”
button is clicked results are displayed in a map below the combo boxes. Buses are
displayed as red dots on the map (Figure 9 – page 16) and their locations are their current
location as determined by the GPS locators on them. You can also click on the buses and
this will take you to the map/timetable results screen which shows the route map for the
bus as well as the timetables for it.
In designing this page we wanted to make it as simple as possible for the user. That’s
why we incorporated two different ways to search for the buses: by stop or by route. If a
user just wants to see buses en route to a certain stop, or if they want to see all of the
buses on a route, then they can do so. We also felt that the next task the user might want
to do after getting the results from this page was to lookup the timetable for the bus route.
This is why we included the functionality that when the user clicks on a bus, it takes them
to the map/timetable page so that they can get the timetable for the bus. This will not
only save them time, but also prevent frustration.
14
Figure 7 - Locate a bus: Search by Route
Figure 8 - Locate a Bus: Search by Stop
15
Figure 9 - Locate a Bus Results
Cost Comparator
The next screen on the main menu is the “Cost Comparator” screen (Figure 10 – next
page). This is a fairly simple screen. On this screen the user simply fills out the form
with the required information and when they press submit, their transportation savings
are displayed in red text to the left of the distance and location dropdown boxes (Figure
11 – next page). These savings are the amount of money saved using public
transportation over driving. On this form we provided the user with a way to easily undo
their actions by providing them with the “Clear” button, which resets all of the fields to
their default values and erases any results. We also designed this dialog to yield closure
by labeling the order in which they need to fill out this form with step numbers. Step 1 is
the public transportation commute section and in this section the user enters information
on how they use public transportation and how often. Once the user has entered this
information, they then proceed to step 2 and enter in their driving information. This
provides an easy step by step process for the user to complete this task and prevents some
confusion that might occur as well as some errors.
16
Figure 10 - Cost Comparator Screen
Figure 11 - Cost Comparator Results
17
Commuter Parking
Continuing down the main menu, the next screen to discuss is the “Commuter Parking”
screen (Figure 12 – next page). On this screen, the user is able to access information
about the different commuter parking lots on campus. The user should notice that a
limited amount of information is available by scrolling over the lot icons (Figure 13 –
next page). The information that is displayed is the total number of spots in the lot, the
number of spaces that are still open, and also a notification that tells you whether you
need a permit or not to park in the specified lot at the current time. To get more detailed
information, the user can click on the specific lot icon that they want to find information
about. We designed this screen with a graphical interface so that it was easy for the users
see which parking lots were close to which areas of campus. Also, we felt that this is
more aesthetically pleasing than just having a list of lots.
Upon clicking on a lot icon, you are taken to the “Commuter Parking Results” screen
(Figure 14 – page 20), where detailed information about the lot chosen by the user is
displayed. On this screen, the title tells you the name of the lot and gives a notification
on whether or not you need a permit to park in the lot at the current time. Below that is a
diagram of the parking lot that has open spaces shaded in green. Our system will
automatically detect which parking spaces are open. This comes in handy for users who
have wireless access on mobile devices to our interface and can use this to find parking
spaces in the lot while they are in their car. Below the diagram of the lot is an indicator
that shows the total number of open spaces. Below that is a form that the user can fill out
to get directions to the commuter lot from wherever they want. Clicking the “Submit”
button after filing out the form will take you to the trip planner results screen where your
directions will be displayed.
The graphical diagram of the parking lot was the best way to show the user exactly where
the open spots are. The user will easily be able to find exactly where the open spots are
because the diagram exactly models the parking lot, space for space. In designing this
screen we wanted to save the user some time and hassle and provided them with the
ability to get directions to the lot. We figured that this would be the next logical step
after visiting this page so we stuck in a form for getting directions down at the bottom.
Aside from these features, we also provided the user with a back button to go back to the
lot selection screen so that they have the ability to change the lot they are looking at.
18
Figure 12 - Commuter Parking Screen
Figure 13 - Scrolling Over Lots in Commuter Parking
19
Figure 14 - Commuter Parking Results
Find a Stop
The final screen accessible from the main menu is the “Find a Stop” screen (Figure 15 –
next page). This screen allows the user to find the closest stop to an address, and also
the current position of the buses near that location. This is useful functionality in order to
figure out what stops are near your home, malls, bars, classes, etc. The user only needs to
enter an address into the fields and then click “Submit”. The design of this screen is
fairly simple, with only the necessary address fields shown in a logical order. Upon
clicking the “Submit” button, a map is displayed below the address fields (Figure 16 –
next page). On this map, the address entered is shown as a gray pentagon, buses are
shown as red circles, and bus stops are shown as red squares. Hovering over any of these
objects with the mouse reveals information about each such as distance from your
location (for stops only), or the arrival time to the stop nearest your location (for buses).
One design element that we added to this screen was the ability to just hover over objects
to reveal information as we did in the commuter parking screen. This is advantageous
because the user does not have to go to a separate screen in order to get the information.
This will save the user time and also is neater than having separate screens.
20
Figure 15 - Find a Stop
Figure 16 - Find A Stop Results
21
Help Screens
As stated earlier, the help screens are available from any page in the interface. An
example of a help screen is found in Figure 17 below. The help screen displays
information specific to the page that you were just on. To get to the help screen, all you
need to press is the question mark button located in the lower left section of the interface
just below the main menu. The button is always there, which makes things simple for the
users. On the help screen we provided a back button for the users so that they are able to
return to the screen that they were just working on.
Figure 17 - Help Screen
22
Development Process
The development of TRANSS-UM involved a series of developmental stages that
translated the initial rough proposal into a fully functional interface. Once the proposal
was established the designers came together to construct a low-fidelity prototype. Initially
it was decided that the designers would individually generate initial interface mockups
and then come together as a group to compare and contrast the behavior of an interface
that would be extrapolated from them.
Low-Fidelity Prototypes:
To generate these mockups, the designers first analyzed and documented the absolute
needs of the interface. This was accomplished by a careful analysis of the expected users,
mostly via the development of task examples. It was determined that the greatest
potential users would be regular commuters to the University of Maryland campus. This
could be a faculty member, a student, a staff member, or any other regular visitor to the
campus.
The designers then used these base needs and tasks to develop their own individual
mockups. The result was two screen-by-screen paper prototypes that essentially
accomplished the same functionality as one another in an abstract level. In addition the
designers generated a transition diagram suggesting the general behavior of the interface.
These mockups were, in reality, ‘very low’-fidelity prototypes. The following image is a
computerized version of one of the original paper prototypes.
(Fig. 1: Low Fidelity prototype #1)
23
The next stage of development involved a close comparison of the low-fidelity paper
prototypes. The designers held a meeting to examine each of them together. Working
with the two screen mockups and the transition diagram they were able to come to a
consensus on the exact behavior of the interface. Primarily, the agreed upon behaviors
were the menu system of one of the mockups, the input requirements and assumptions of
the other, and some of the information flow dictated in the transition diagram as well as
images and other media for incorporation into the interface.
(Fig. 2: Low Fidelity prototype #2)
High-Fidelity Prototype:
Based on these behaviors from the multiple low fidelity prototypes, the designers started
work on a high-fidelity prototype that would act as a combination of the benefits of each
different mockup. The designers used Macromedia Flash MX to create the menu and
input systems. Although there are a lot of graphics present, initially this prototype was
very rough and very simple. Navigation through the menu was functional, but there were
also numerous graphic errors involving the menu that made navigation difficult. In
addition the input systems were not functional. Many of them were merely represented by
graphics or non-functioning text areas. An example can be seen in Figure 3 on the next
page which shows the Plan a Trip screen of the interface for the initial hi-fi prototype
(#1).
24
(Fig. 3: hi-fi prototype #1)
Eventually the input system was implemented successfully and the high fidelity prototype
was fully functional. Additionally, the designers implemented some key informative
functions to the interface. Namely, the addition of a clock and date that is visible at all
times while using the interface, as well as a help button on every screen. You can see in
Figure 4 on the next page that the “Plan a Trip” screen has expanded in order to keep the
user informed and in control. Analogous changes were made to the other screens of the
interface resulting in our high-fidelity prototype.
25
(Fig. 4: hi-fi prototype #2)
The ending hi-fi prototype was developed over a significant portion of time. It was based
heavily on the hi-fi prototype #1 that was drawn up from the low fidelity mockups. The
menu system remained intact, preserving the functional relationships between different
parts of the interface while allowing for careful additions of information and organization
to facilitate use by the expected users. Essentially this prototype had everything it needed
for successful use in the real world. The only developmental stage left was usability
testing to gauge the interfaces performance in a real world situation.
Usability Test:
The usability tests used to test the hi-fi prototype were fairly straightforward. The
participants were given a list of eight tasks to accomplish using the interface. The eight
tasks have the primary functions of the interface at their core, but they are focused on
exposing the tester to a wide range of inside the interface’s menu and input systems.
Once the users have attempted all the tasks, they then fill out a short post-test
questionnaire. This provided the designers with feedback that could be significant enough
to elicit a change in the interface design.
26
Subjects:
All of our subjects were University of Maryland students. This is the main expected user
since they regularly travel to or from campus. All of the subjects were between the ages
of 18 and 22. The age group seems fairly narrow, but is in fact fairly representative of the
population of drivers on campus. The subjects were assumed to have good working
knowledge of computers.
The Tasks:
Please answer the following questions to help us determine how effective our interface is
in helping user’s perform a task. The purpose of this exercise is to help the designers of
this interface determine the effectiveness of its design, you are not being tested, it is the
interface is what is being tested. For question 5 through 9 (below) we ask you answer the
question from viewpoint of the fictional user we created.
1. Find the current location of the Shuttle Bus leaving the Stamp Student Union and
going to College Park Metro Station.
2. Find the bus schedule for the bus leaving the Stamp Student Union and going to
Spring Hill Lake
3. Plan a trip from Hagerstown Hall to Silver Spring Metro Station?
4. Plan a return trip from Silver Spring Metro Station to Hagerstown Hall?
5. Suppose you live in Easton Hall, find the closest Shuttle UM bus stop?
6. Suppose you live in 6400 block of 57th avenue in Riverdale, Maryland, 20737.
Find the closest Bus Stop to your residence.
7. Suppose you are driving from Virginia, find the closest outlying parking lot to the
University?
8. Suppose you currently commute (driving alone in you gas guzzling 98 Ford
Explorer which consumes 20 miles per gallon) from 6000 block in Franconia Rd.,
Alexandria, VA. 22310. Calculate how much money you would save by taking
public transportation to school?
27
The Post-Test:
Name:
Age:
Gender:
Please indicate your answer based on a scale from 1 – 9; one being the best possible
answer and that you completely agree, while 9 is the worst possible answer indicating
that you completely disagree. Please circle one answer.
1. Was the information presented well spaced and organized?
1 2 3 4 5 6 7 8 9
2. Did visual images provide a clear indication of actions?
1 2 3 4 5 6 7 8 9
3. Were you able to complete your task with ease?
1 2 3 4 5 6 7 8 9
4. Did the system respond correctly to your actions?
1 2 3 4 5 6 7 8 9
5. Were you able to easily reverse an action?
1 2 3 4 5 6 7 8 9
6. Did the system prevent you from erroneous input?
1 2 3 4 5 6 7 8 9
Please provide comments:
Usability Test Descriptions:
Joel is a 20 year old male student who commutes a short distance (<5 miles) to school
Monday – Friday.
Joel executed all tasks, except Task 2, successfully. Task 2 was the only task he had
issue with. In his execution of Task 2 Joel attempted to find the bus schedule through
the Locate A Bus as in Task 1. This was counter-productive as it required an
additional step to select the bus through the bus locator map. He admitted he should
have noticed that the Map/Timetable would be more effective for this task.
Joel commented on Tasks 1, 5, 6, and 8. He said that for Tasks 1, 5, and 6 were very
simple to execute and the functions responsible have great potential for mobile use.
Specifically he said that if the inputs for Find A Stop were simplified to use your
current GPS location instead of entering plain text he could use it, in combination
with Locate A Bus to catch any bus as he walked around on or off campus. For Task
8, Joel said that the From/To and Distance/Location fields were unnecessary together.
He mentioned that a From/To field by itself that calculated distance would be more
functional and simpler to input.
28
Ben is an 18 year old male student who lives in an on-campus apartment. For the classes
close to his apartment he normally walks, but for classes across campus he prefers to
drive, parking at either metered spots or parking lots that charge hourly fees.
Ben executed all tasks successfully. He had minor trouble on Tasks 1 and 2 as he was
not sure which line the target bus was on, so he had to guess until he found it.
Ben commented on Task 8. For Task 8 he noticed the Cost Comparator provided no
useful functionality for on-campus residents. He suggested an alternative Time/Cost
Comparator that would calculate the time saved when using the Shuttle-UM system
to go to class compared to driving. He said it would be useful to see the amount he
pays for parking side-by-side with the amount of extra time the bus could take. He
commented that mobile use of Locate A Bus would greatly encourage his use of the
bus system as the main discouraging factor for him was waiting at the bus stop, not
knowing exactly when the next bus was coming.
Alex is a 21 year old male student who commutes a long distance (>20 miles) to campus
Monday – Friday.
Alex executed Tasks 1-7 successfully. For Task 8 he didn’t know the rate of gas
consumption of his car and was unable to fill out the form with correct information.
He commented that a list of average gas consumption rates of standard vehicle types
would be more useful, as most people are unaware of their exact rate.
Alex commented on Task 7. For Task 7 he claimed it was essentially useless to him.
Instead he would prefer to locate the parking lot that lies on his current commute
route. He wanted the parking lot that he could reach the quickest: the lot closest to his
starting location, not his destination.
Jade is a 21 year old female student who commutes a short distance (<5 miles) to campus
Monday – Friday.
Jade executed Tasks 1-5 and Task 7 successfully. For Tasks 6 and 8, she was put off
by the inability of the interface to catch errors in the input fields of the Commuter
Parking and Find A Stop pages. She fixed her input and successfully completed the
tasks, but it seemed to make her less confident in the interface.
Jade commented on Task 8. She said that the Commuter Parking page seemed very
useful for mobile use, but it wouldn’t work for that purpose in its current form.
Instead of having a map of campus with the lots linking to individual pages showing
open spaces, she would prefer a simple table or map that indicated the number of free
spaces plus the permit required to park there. The current way does indicate these
through a mouse-over popup, but she thought this would not be as helpful for mobile
use as a simpler map or table.
29
KC is a 22 year old male, a senior neurobiology major commutes to campus from a
nearby apartment in College Park. His preferred and primary means of getting to campus
is via a personal car. He has not ridden on the Shuttle-UM this semester. He almost
always drives to school from a nearby apartment in College Park.
In completing the first task (locate a bus), this user found the task to be “straight
forward and easy to locate”. As soon as he read the task description he immediately
choose the Locate a Bus button. He recommended that in addition to the graphical
display of results, a textual description of results be added. For the second task of
finding a bus schedule the user paused a couple a seconds to examine the menu items.
It turned out that because the task list used the term “bus schedule” he scanned the
interface menu items for “schedule”, but when he did not find it he read the
description one more time and located Map/Timetable. He easily filled out the entries
but selected the wrong button Find Timetable instead of the Submit button to get the
results of his entry. It turns out that because he was filling out a Map/Timetable
section he thought Find Timetable button was the correct button to press. He caught
this mistake and even admitted that he should have realized that Find Timetable
button was for a different textbox entry. For the third and fourth task of planning a
trip he exclaimed “Shuttle UM could benefit from some of the ideas presented in this
project”, he loved this two tasks. For the fifth and sixth tasks he breezed through it
and he found them to be both “easy”. In performing the seventh task of finding
Commuter Parking, he thought it would have been great if it had real data and a user
was able to zoom in and out. Lastly to determine the amount saved from commuting
(Cost Comparator) this user made a great suggestion that in addition to typing in
one’s start and destination address, this section should also have a shortcut for users
who already knew the distance between their start and destination commuting address
to enter in the distance instead of having to type in addresses.
He liked the interface overall and was impressed with its design and layout. He noted
that the testing process would have been more enjoyable with real data.
On a scale of 1-10 (1 being not easy and uninteresting, 10 being easy and enjoyable)
he gave task 1 and task 4 through 8 a rating of 10. He gave task 2 and 3 a rating of 8
and 9 respectively.
Paula is a 22 year old female student who commutes to school Monday – Thursday.
Paula was impressed by the overall appearance of the interface. She appreciated the
consistency in colors, fonts, and spacing. Paula had the greatest issues understanding
the concept of our assignment in that our interfaces need not be completely functional
and that data was not completely real. At first the lack of “correct” responses for say
a trip from College Park Metro Station to Shady Grove Metro Station cause Paula to
feel negative towards the interface and became discouraged of even completing the
usability test tasks. Upon further explanation of the assignment, Paula agreed to
continue. Her attitude towards the interface changed completely knowing that data
need to be real and thus her attitude became more favorable. She really liked the
30
dynamic clock that is displayed towards the top of the interface, especially if the
interface is used on cell phones since most of the time while you are engaged in a
conversation, or are transmitting data, the phone only displays the current call timer,
and does not provide a visible clock. Paula felt that, although only a few, there were
some input fields that weren’t intuitive as far as what the desired input was
concerned. This information was later used on the final interface to have predefined
text on the input fields sort of as guides for the input necessary. Paula also mentioned
that there was little or no error checking of her input. The final interface took input
error checking into consideration. Paula’s last remark regarding the interface
involved the map characteristics of the interface. She felt as though the maps should
present the availability to zoom in/out, and to change position by clicking and
dragging on the map. This can definitely be incorporated into the final interface with
more time.
Results:
The usability tests went very well. It seems that our interface is fairly intuitive to use for
our expected user, which is exactly what we set out to accomplish. Here are the results
from six tests run on six subjects, broken down into bar graphs. Q1-6 represents the six
post-test questions and S1-6 represents the six subjects.
9
8
7
6
5
4
3
2
1
0
Sub1
Sub2
Sub3
Sub4
Sub5
Sub6
Q1
Q2
Q3
Q4
Q5
Q6
As you can see, it looks as though the only problem that is relevant from this simple
analysis of the post-test results is that our interface is not preventing user input errors.
This is a problem, but it is a very easy problem to fix.
The usability testing revealed additional problems that were not apparent by reviewing
the post-test results. Subjects have had trouble on certain parts of the test where, for
example, the form requires a piece of information about a bus line that the tester does not
know. Another example of this was when a test subject was unable to complete the first
task because she was unaware of the buses that stop at Union Station. This particular
example was an easy fix since all that had to be done was allow users to search by bus
stop, not just by bus. However, other similar problems could easily exist.
31
Overall this interface seems to have scored very well. From the test subjects’ responses
the interface seems quite dependable aside from the fact that it does not detect input
errors. It would be interesting to see if the results would remain the same with a larger
number of test subjects.
32
Conclusions
The TRANSS-UM project has been a great experience for its developers. Ideas and
proposals to encourage the University of Maryland’s use of public transportation started
out as paper prototypes and were translated into a Flash interface using input from users
as a guide. This project is an approach to provide students/staff at the University of
Maryland a system with readily available resources to encourage the use of public
transportation for commuting to and from campus. This is accomplished by providing six
critical resources for users of the system: plan a trip – which provides an itinerary for
using public transportation from one destination to another; map/timetable – provides a
map of an area serviced by a bus (the user chooses) and an operating schedule for the
bus; locate a bus – provides graphical and textual representation of the current location of
a bus operating in an area (which the user can use); cost comparator – uses user input to
determine how much money will be saved by using public transportation as opposed to
driving; commuter parking – provides a graphical representation of locations users can
park off campus; while find a stop – provides users with a view of bus stops within
walking distance of their current location.
Final Status
The current interface provides functionality for all six tasks described above, though the
database component of the system that will have resulted in it being deployable is largely
unimplemented. For each task the following was implemented:
The task to plan a trip provides users an ability to provide start/end address, an option to
choose the transportation system to use, date/time of trip, in addition to an ability to
choose a constraint on the resulting itinerary (for example a cost constraint to return the
cheapest itinerary). In addition a graphical representation of an itinerary is provided.
To find a map/timetable a user is provided two options, one for a new user the other for
an expert user. A new user unfamiliar with the bus systems is provided with a three step
procedure to choose find a map/timetable, while a frequent expert user is provided with a
one step procedure to obtain the same information. The three step procedure for new
users provides an ability to choose the bus system, the state the route is in, and the route
name itself; while a frequent user simply types in the bus name to obtain results.
Locating a Bus provides users an ability to locate a bus by bus route (default), select the
bus system the bus is in, and choose the bus route the bus operates. The result is a textual
and graphical representations of location of the bus.
The task (cost comparator) to determine cost savings for a user choosing public
transportation over driving is represented by a two step process. In the first step, a user
enters information identifying the start and end location of commute, the frequency of the
commute (that is, whether the commute is done daily, weekly or monthly. In the second
33
step, user provides information for driving distance and location, gas consumption of
vehicle and car type, result determines how much money a user saves by commuting.
To find commuter parking the system provides a map showing the user parking lots
relative to the University of Maryland, where users can park and walk/bike to their final
destination. For each parking lot is provides an ability to determine how many spaces are
present, the number of spaces available and current restrictions on the lots. The map
shows roads/paths to encourage walking/biking. Finding a bus stop from which users can
take public transportation is represented by Find a Stop, users enter information (address,
city, state and zip code) about current location, the system returns a map with icons
showing the bus stops which are close by and the current location of the buses.
In addition to the functionality provided for each task, a help screen is available for each
page to provide new / inexperienced users with information to help them use the system.
Also to minimize chances of system being put in an in-deterministic state some
mechanisms are in place to prevent incorrect user input.
Future Improvements
As it stands the ‘front end’ of the system was well design and implemented, there is
always room for improvement. The system’s ‘backend’ – can be greatly improved.
Specifically the front end can be implemented to restrict invalid user input in fields that
take input from a restrictive domain. In addition provide an ability to zoom in and out of
maps will enhance a user’s ability to comprehend map content for those considering
walking or biking. The ability of the ‘front-end’ of the system to display
comprehensive/correct information to user is restricted by the current system’s access to
real data. This system will be data driven, to be deployable this system’s ‘backend’ will
require a great deal of investment in manpower and tools.
For every transportation systems route and for each route provide a timetable/map for
that route, provide a map of all areas in which all-pertinent transportation systems operate
and number of spaces in parking lots will be needed. Provide a means to search map/bus
schedule in addition to map of areas transportation systems operate in. A means to
associate address entered by user to routes being serviced by buses is also needed. Live
feed of the following data is needed: GPS location of buses equipped with said
technology, number of open parking spaces, parking lots parking restrictions.
A minimal ‘backend’ improvement is to provide logic manipulations such that correct
results about amount saved will be returned when a user enters information about the
distance the covered and amount of gas used.
The front-end interface is a great starting point, but before this system can be deployed a
‘backend’ component has to be developed. Using live data with this system will pose a
major technological challenge, especially for the novice developer.
Future developers of this system should create a plan/design to build the backend
component, and obtain the necessary resources (manpower and tools) before embarking
34
on build. A test plan must be put in place to ensure that the system (which will grow in
size) functions as expected.
35
Appendix - Diagrams and Screen Shots
36
Homepage
Help
Help
Main
Menu
Trip
Planner
Results
Trip Planner
Map
Timetable
Results
Map/Timetable
Closest Stop
To Location
Bus/Train Locator
Commuter Parking
Cost Comparison
Help
Help
Results for
Commuter
Parking
Figure 1 – Transition Diagram for Interface
37
Figure 2 - Homepage of our Interface
Figure 3 - Plan a Trip Screen
38
Figure 4 - Plan a Trip Results
Figure 5 - Route Map/Timetable screen
39
Figure 6 - Route Map and Timetable screen
Figure 7 - Locate a bus: Search by Route
40
Figure 8 - Locate a Bus: Search by Stop
Figure 9 - Locate a Bus Results
41
Figure 10 - Cost Comparator Screen
Figure 11 - Cost Comparator Results
42
Figure 12 - Commuter Parking Screen
Figure 13 - Scrolling Over Lots in Commuter Parking
43
Figure 14 - Commuter Parking Results
Figure 15 - Find a Stop
44
Figure 26 - Find A Stop Results
Figure 17 - Help Screen
45
46
Acknowledgements
The creating of this semester long project has been a very challenging but fulfilling
endeavor. We were guided to this project by the encouraging and understanding
Dr. Shneiderman. Also we want to thank Mr. Khoo Yit Phang, and all our users who
helped us evaluate this system.
We also want to thank each other for a job well done and the sacrifice made through out
the semester, in creating the flash interface and writing this report.
47
References
1) Finkel, Ed. “New index Tracks Housing and Transportation Costs”. Planning. 72.
(2006). October 3rd, 2006. <http://search.ebscohost.com.proxyum.researchport.umd.edu/login.aspx?direct=true&db=aph&AN=21924982&site=eho
st-live>
2) Jesper Kjeldskov, Stever Howard, John Murphy, Jennie Carroll, Frank Vetere, Connor
Graham, Designing TramMatena Context-aware mobile system supporting use of
public transportation, Proceedings of DUX’03: Designing for User Experiences, n.12
p.1-4, 2003.
3) Jorg Baus, Antonio Kruger, Wolfgang Wahlster, A Resource-Adaptive Mobile
Navigation System, Proceedings of the 2002 International Conference on Intelligent
User Interfaces ‘02, p.15-22, 2002.
4) Liu, Chao-Lin. “Best-path planning for public transportation systems.” Intelligent
Transportation Systems 365-369 (2002) IEEE October 3, 2006
<http://ieeexplore.ieee.org/iel5/8061/22289/01041328.pdf?tp=&arnumber=1041328&
isnumber=22289>
5) PB Farradyne Inc . ITS Deployment Guidance for Transit SystemsExecutive Edition.
April 1997. October 3, 2006
<http://citeseer.ist.psu.edu/cache/papers/cs/15229/http:zSzzSzwww.itsdocs.fhwa.dot.
govzSzjpodocszSzrepts_tezSz3tw01!.pdf/its-deployment-guidance-for.pdf>
6) Verma, Ashish, & Dhingra. “S. L. Developing Integrated Schedules for Urban Rail
and Feeder Bus Operation.” Journal of Urban Planning & Development. 132. (2006).
October 2, 2006. <http://search.ebscohost.com.proxyum.researchport.umd.edu/login.aspx?direct=true&db=aph&AN=21970632&site=eho
st-live>.
7) Department of Transportation Services, University of Maryland.
<www.dots.umd.edu>
8) Economic Analysis Division, John A. Volpe National Transportation Systems Center,
United States Department of Transportation, Trip Planning State of the Practice,
Cambridge, Massachusetts, June 2002
9) Google Transit Website http://www.google.com/transit
10) National Wildlife Foundation. Campus Ecology. October 3, 2006.
< http://www.nwf.org/campusecology/dspGreeningProjects.cfm?iID=10>
48
11) Transitweb Website <http://www.its.dot.gov/transit_dev/introduction.asp>
12) Washington Metropolitan Area Transit Authority Website
<http://www.wmata.com>
49