InteractivePrototype-Group:KMAT
From CS160 User Interfaces Fa06
Contents |
Group Members and Roles
Kang Chen: Image manipulation with Photoshop, wiki editing, help setup MySQL for storing street coordinates, and making slides, script and brainstorming for presentation.
Melissa Jiang: IO (sending user input data to corresponding websites and parsing the output), setup MySQL for storing street coordinates, wiki editing.
Andrew Tran: Swing, MapPanel, paper UI, assisted in image manipulation, wiki editing, help making slides for presentation.
Tak Wong: Swing, paper UI, converting/populating existing coordinates in excel to MySQL, help writing schema and queries for MySQL, wiki editing.
Problems and Solution Overview
Problem
For many users out there, sometimes finding the nearest ATM of their desired bank or finding the closest and cheapest gas station may not be an easy task if they are already on the road. Without a laptop and wireless connection, it is even harder to find their desired locations. Also, many users will have to visit multiple sites in order to obtain current traffic information as well as driving directions. Not to mention, if they are already on the streets, then if they decide to be spontaneous, they will not have the appropriate directions. If users want a system that can tell them all these information, a GPS system will be ideal. However, a GPS system is typically mounted in a car and can be rather pricey. Thus, the lack of mobility provided by the GPS system may not be the best solution.
Solution
Our solution is to provide users an interactive map. The map of San Francisco will be broken into 12 different sections with each section occupying their own page to simulate a Thomas Brothers Guide. Each section will be blown up to fit an 8.5 x 11 inch page as well as a whole map of San Francisco as the cover. With the cover, users can trace along a freeway of their choice and receive real time traffic information sent to their cell phones. With each of the smaller maps, users can have a choice of finding the closest ATM (Bank of America, Washington Mutual or Wells Fargon), cheapest gas stations or trip planning information. With Gas Station and ATM information, users can simply circle where they are currently located and check the appropriate boxes to receive the information they want. With trip planning information, users can pinpoint and dot/circle the intersection where they are starting their journey, then circle the end of their journey and retrieve a choice of driving directions or transit directions (including when the next bus is). Furthermore, each page of a blown up section will have coordinates dividing the page into 9 more sections. With the text message that we end the users, we will also send a coordinate point (A3, B4, etc) so the user will have an easy time pinpointing the desired location. Also, the pen and paper presents a much more mobile than GPS system which are generally mounted in a car.
Tasks
Easy Task
Given a map of downtown San Francisco, circle an area and try to locate the closest Washington Mutual ATMS. We felt this task was the easiest because the user does not need to be very precise when pinpointing exactly where they are on the map. Therefore, all they need to do is circle a general area and tap the box for Washington Mutual Atm.
Medium Task
Circling or dotting a source intersection and then circling or dotting an ending destination, then check the get driving directions and retrieve the driving directions from the source to the destination. This task was labeled medium because the user has to locate the starting intersection as well as the ending intersection.
Hard Task
Circling one area in downtown San Francisco and another area in downtown San Francisco, then check the check box for directions by transit and retrieve the transit directions from the source to destination. This task was labeled hard because not only does the user need to locate where the starting intersection and ending intersections are, the use will have to locate and find out where the South East or North West Corner of X street in order to board the desired bus.
Revised Interface Design
All of the prior test subjects expressed dissatisfaction with the prior map. They felt that even if they knew what street the gas stations are on and what the directions are, that they will not be able to find the street on the map. Many users recieved the text message with the location of the gas stations printed. Unfortunately, as the user proceeded to look on the map for where the location was stated, they either could not find the location or had a horribly difficult time. Therefore, they felt that the map was actually rather useless when they want to search for the street. In response to their dissatisfaction, we decided to split the map into different sections. We decided to split the map into twelve different sections and blow each of the sections up to a full page. We also made the maps as high resolution as possible in order to provide the most visibility. Each street on the map has been labeled and each street can be found. The map's division is not evenly divided. With more dense street areas (such as downtown San Francisco), a smaller section is blown up as opposed to a bigger section (such as the very gridlike street of Sunset district of San Francisco). The rationale behind this choice was because we felt that with more dense streets, even more visibility should be provided.
Not only have we made the maps bigger, we had created a type of map coordinate system. A typical map coordinate system will require the user to turn the map to the back side and look up the street name. Once they find the street name, they will flip the map back over and look for the labeled coordinates to pinpoint their destination. We figured such a system is useful for helping users search for their destination. However, we felt that labeling of all the streets in the back of the map will not be efficient. The flipping back and forth of the map may be rather annoying and not very time efficient. Therefore, instead of labeling all the streets on the back of the map, we decided to send the coordinate of the user’s destination to their cell phone as well in the same text message (or at least as much as we can fit in the least amount of space). The user can then simply look at their cell phone while simulataneously looking at the map directly. With the properly labeled coorindates (The X coordinates labeled either A-C, D-F, or G-I and the Y coordinates labeled 1-3, 4-6, 7-9, 10-12).
Further explanation will be given in the next section.
The Flow Chart of how the new prototype system works:
Prototype Overview
Overview of the UI implemented
Our current user interface is one sheet of paper that includes a map of downtown San Francisco, bordered approximately by The Embarcadero, Van Ness Avenue and the Interstate 80 freeway. There are three buttons that corresponds to the three functions that the user can perform: finding the ATM locations of Washington Mutual, planning a trip by public transportation, and planning a trip by private vehicle. There is also a “reset” button that will clear all the information that is collected. The letters G, H, I and the numbers 1, 2, 3 on the map are used to let the user find their location easier. This feature is to be implemented in the future.
There is also a Java swing component that mirrors the paper interface to give the user feedback on their actions. There will be red ink marks that will correspond to what the user draws on his or her paper. The buttons will flash when the user clicks on them. When the message is ready, there will be cell phone display that will show the text message.
As for the details of the implementation, the process starts with the user circling a location or two on the map then tap on one of the boxes, depending on the desired information. The details of each task are described in the task section. This information is parsed to the swing component, which will find the location of the center of the circle. The coordinates will be converted to the compatible units in the database. The new coordinates will be passed to the database, which will provide the closest zip code or the intersections, depending on the task. Then the zip code or intersections will be passed to a HTML parser, which will retrieve the closest ATM or driving directions from the web. This includes the five closest Washington Mutual ATMs in the area if the desired information is ATM locations, or driving/transit directions if the desired information is trip planning. These information will be stored in the database, which will be queried and displayed on a HTML/PHP website with a simulated cell phone. The user can click on the cell phone to read a message, scroll down, etc. If the user makes a mistake in any of the process, the “reset” button can be used to clear any information that was written on the sheet of paper, and then start over.
Things that are left out
There are many things that we left out of our original interface. In terms of the interface design, we originally want to include the whole San Francisco for people get information on. We later find out that it is impossible to read most of the street names if we include a map of San Francisco in an 8.5 by 11 inches sheet. Therefore, we plan to break up the map of San Francisco into 12 regions and put each region in a separate sheet, plus a cover page with the whole San Francisco. We later think that these 13 sheets will have the same dot pattern, so we’ll need to distinguish them somehow. We planned and tried to implement this by having 13 distinct regions and inkwells and such, but it gets really complicated. We decide to drop this into only providing one sheet with only one region (downtown San Francisco). However, Ron Yeh informs us a few days before this assignment is due that the dot patterns will be distinct if we render all 13 sheets at once. But it is too late for us to change our implementation before the deadline, so we decide to implement the 13 sheets for the next phase. We feel that what we have right now is enough to test our whole interface in terms of using the system and reading the output information.
In our original design, we plan to let the user perform their tasks anywhere through a cell phone’s Bluetooth, then the information will be sent to our server, which will process the data, then sends the information through text messages to the cell phone. We asked Ron Yeh about collecting pen strokes through a cell phone’s Bluetooth and he says it will be too complicated to do. Therefore, we simplified the process by using Java swing to give feedback and set up a webpage where the user can see a cell phone and the display that we would give. So instead of requiring a Bluetooth enabled cell phone, we now require a laptop with java swing capability, Anoto streaming, and internet connection.
We originally have three additional functions, making our interface to have seven functions total. These functions are: find the ATM locations of Bank of America and Wells Fargo, finding the closest gas station, and finding real time freeway information of a section of San Francisco’s freeways. We decided to take out the functionality of finding the closest ATM locations of Bank of America and Wells Fargo because we had difficulty parsing information to their ATM locator websites to find their ATM locations in the area. These sites block us when we try to grab their information through Java’s URL functions. Our only successful one is Washington Mutual, which we included as one of the three functionalities that we can support in this implementation. We had difficulty with the gas station parsing as well because they site has code that only let searches through their website, so we were unable to do it through Java. One possible solution is to store all the ATM location information in our database and update them periodically. Then when the user tries to search for them, we’ll query our database to find the closest location. For the gas station information, we may need to get around their JavaScript code to make it seem like we are searching through their website. Both potential solutions need further research and trail and error, which we are unable to do with only two weeks.
The real time freeway traffic information functionality is taken out because as I mentioned above, we are now supporting downtown San Francisco instead of the whole San Francisco. As a result, our map only shows one exit length of interstate 80. We figure it will not be very useful to get information for only that one segment, so decide to support this functionality in a later phase.
We also plan attach each intersection or address we output to the user with a more refined region on the map. For example, if our display includes “turn left on Bay St”, we will append “G1” with it so the user can find the intersection on the map easier. We decided not to implement this because there is a lot of work with making sure the parsed information fits a certain format and we have to find the cut off coordinates for each region and store them in the database. Also, this feature is less useful if there is only 9 regions to choose from, compared to 108 regions if we include the whole San Francisco.
Wizard of Oz
The wizard of oz technique used in this phase was using a laptop instead of a cell phone. As mentioned earlier, we feel it is too hard to use only a cell phone at this stage. The user will need to run our Java code and see their text message on a webpage that simulates a cell phone. Other than that, all other functions will work automatically. This includes recognition, querying the database, getting data from the web, and automatically generated output.
Prototype Implementation
Source code
PDF of the map
Readme
Prototype Screenshots and Scripts
Prototype Screenshots
This is the first page the user will see (cover page):
The paper interface the user will interact with:
The swing component of the interface that the user can get feedback on their actions (in the case, the user is trying to get driving directions):
The cell phone the user will see before getting his or her message:
The cell phone displaying the information shown:
Script
1) Kang begin by introducing members of KMAT and the SSS application.
2) Next, Kang will talk about the overview of the presentation.
3) Following the overview, he will discuss the overall problem SSS attempts to solve.
4) Kang will then elaborate on SSS and some of the features it supports.
5) Afterwards, Kang will present a list of representative tasks to be demonstrated in the demo.
6) While Kang explains the story behind the demo and elaborate on how to use the SSS to complete the various representative tasks, Andrew will be performing the demo.
7) After the demo, Andrew will discuss some of the problems found in the early Lo-Fi prototype and KMAT's solution to the problems.
8) Kang will wrap up the presentation with the summary.
Interactive Prototype Presentation Slides Keynote (recommended)
Interactive Prototype Presentation Slides PowerPoint (See this if you do not have keynote)
