Interactive Prototype
CSE 440 Autumn 2008 | Assignment 6
Online URL | http://www.cs.washington.edu/education/courses/440/08au/project_files/parking/
Group Manager | Jonathan McKay
Design | Linda Hong Le
Usability Test | Alireza Bagheri Garakani
Documentation | Nuo Yan
1. Overview
Finding parking in a congested area is difficult. A recent study by the University of California found that 30 percent of traffic congestion in major business cities arises from difficulties in parking, and this wasted effort burns 47,000 gallons of gasoline and produces 730 tons of carbon dioxide per year. [Simon] To help resolve this issue, we propose an application that will allow an iPhone to help drivers find parking spaces by retrieving information from an online database. The application would provide drivers with information about areas such as parking garages and park and rides. In these parking lots, a gate or sensor would be placed at the entrances to count the number of cars in the lot. This information would then be uploaded to a database that the application would access in order to determine the number of vacancies. Drivers would be able to input their destination to find suitable parking nearby or use GPS to cross-reference their location with a database to highlight available areas. Our mission is to provide drivers with an efficient means to find parking so we can relieve stress, reduce CO2 emissions, while saving time and money. As part of this goal, we created an interactive prototype to demonstrate the important ideas and interface choices of our program.
2. Tasks
1. Medium Check System wide availability: The first task that we have for a user is to be able to determine the system wide availability for a given parking location. This is where the customer should be able to see all the available parking within a useable radius of his destination. While this task is not based on finding a specific parking spot, customers will often want to check and make sure that parking is available to decide upon embarking or to estimate how much time their trip will take.
2. Hard- Getting directions to a parking location: Once a customer finds a place that they want to park often times they will not know how to get there. So they will need directions to help them reach their destination without difficulty.
3. Easy- Saving a parking spot: Once customers do park, they will often want to be able to use the successful parking spot they found for future use so they can come back to it on a later day, or simply to find their cars in a large car parks.
3. Revised Interface Design
Changes and Rationale
There are many aspects of the interface design that we modified in response to our low-fi testing results and our subsequent discussions with our industry mentor, Amy Karlson. Among these modifications, there were three major changes:
- Inserting a ‘Back’ navigation button within the garage details screen – As the majority of our participants during our low-fi testing suggested, it was previously unclear how to navigate back to map view after having selected a particular garage to view garage-specific details. Recognizing the importance of this functionality, we included buttons in these screens, as the figure to the right demonstrates.
- Creating a naviagtion bar that is more intuitive and flexible in performing main program functionality – Having originally planned to build ParkSmart on top of the existing iPhone maps application, our previous design had two lower naviation bars. As Amy Karlson suggested and the low-fi testing supported, it is more intuitive to have one naviagation bar that supported ParkSmart’s own main functionalities (changing map display modes, saving parked locations, etc.). We made this changed to our user interface and included the follow functions from left to right (buttons are seen in the figure to the right): go to current location, go to searched location, get directions, save parked location, and map options / miscellaneous functionalities.
- Adding better garage representation as map icons – many times throughout our design process we struggled to determine the best way to represent garage icons on the map view. After evaluating the low-fi test results and hearing the suggestions of Amy as well as classmates, we decided that garage icons should display the number of availability parking spots and that these icons should have some color that correlates with the number of availability (i.e. bright blue indicating high availability, dark blue indicating low availability). By this method of representation, we expect customers to be able to quickly view availability and eventually draw this correlation between availability and color brightness. The image to the right shows the resulting icon representations.
Scenarios for Three Tasks
The scenarios and their corresponding storyboards below demonstrate our design emphasis on ensuring that our primary three tasks are intuitive and simple for the customer to execute. Each task is shown below in order of possible sequential execution:
- Determining System-Wide Availability (Medium) – Stacy, a ParkSmart customer, intends to make a trip to the ‘Woodland Park Zoo’ and is interested in parking availability at her destination. She executes the application on her iPhone, selects the address bar at the top of the screen, and enters her destination address (Figure 1.1). ParkSmart displays a list of garages in the area (Figure 1.2), and more precisely shows available spots for a particular garage upon zooming in (Figure 1.3).
Figure 1.1 /
Figure 1.2 /
Figure 1.3
2. Getting Directions to a Particular Parking Spot (Hard) – Having determined a preferred parking garage, Stacy proceeds to select a particular garage icon and is shown greater details regarding the garage (Figure 2.1). After deciding that this garage is suitable for her in terms of available spots, business hours, location, and so forth, Stacy selects the ‘Get Directions’ button. ParkSmart operates similar to a GPS device at this point; the system changes screens to a map of Stacy current location and displays a route that she can take (Figure 2.2).
Figure 2.1 /
Figure 2.2
- Saving a Parking Spot – After parking at her destination (or having chosen to park at some alternative location, such as street-side or a parking lot), Stacy wants to be able to remember this location for future visits. She uses the save button on the bottom navigation bar and receives notification that her spot is saved (Figure 3.1). She can then easily view her saved locations on her map anytime in the future (Figure 3.2).
Figure 3.1 /
Figure 3.2
4. Prototype Overview
Tools
The main tools that we used for creating the interactive prototype were Adobe Photoshop and Adobe Dreamweaver with Image Mapping. The tools were helpful in the flexibility that they offered for making prototypes and the ability to quickly replicate repetitive parts of the project. Luckily two of our group members already had spent time with Adobe products and were therefore able to use them effectively. However the for the two novices in the group, interface was sometimes frustrating when attempting to use more complicated functions. We were tempted to use Adobe Flex, but nobody in the group had any experience with the product so we decided against it.
Overview of the UI
The user interface was based around the three tasks that we set up, and attempts to make these tasks the easiest things to do in the application. While there were other options for the user to change such as the viewing settings, we relegated these to pathways which were not primary in the interactive prototype. The figure below shows the state diagram of the interactive prototype, and the link that a customer would press to go from screen to screen. In this figure, the starting screen is where the customer is currently located (See A1). From there, the most likely thing they will do is enter in an address, which will bring them to their destination, which in this case is the Woodland park Zoo. This would bring them through B1 and then to C1. At this point they cannot go directly to the parking garages, so they have to zoom down through C3 and once they get directions they will be brought to the directions screen G1. For the easy task, the only thing they have to do is hit ‘save’ which will bring them to H2 and then return them to their previous screen.
Things Left Out/Wizard of Oz Techniques
The main thing that we did not implement for this interactive prototype was the panning and zooming features that are usually found on interactive maps applications. We first wanted to do this, and it meant we had two options. First, we could try to use the API of a third party maps software, like Google or Live Search. Or, we could try and create a flash interface and encode our own ‘pan and zoom’ features. Unfortunately, neither system worked. For third party applications, we were limited by restrictions that the API’s gave us, namely that it was impossible to link directly from the map to another screen without going through a dialogue box. We chose not to accept this sacrifice because it would have completely changed the way our interface functioned. For creating our own flash system, we found out that pan and zoom would require the use of Adobe Flex, which none of us had any experience, meaning that we could have wasted many hours for little result.
Because of this, we ended up using the Wizard of Oz technique of simply linking a series of images and leaving out the pan and zoom feature. While this was regrettable, it was the best choice to preserve the interface we have been developing for our prototype. This means that the locations for the customer and destination are set and cannot be changed within the prototype. The other main Wizard of Oz technique is that we do not use actual data from parking garages. All of the parking availability and pricing information is made up.