FinalPrototype-Group:KMAT
From CS160 User Interfaces Fa06
Contents |
Team member and Role
Kang Chen: Wiki editing, Swing debugging, poster
Melissa Jiang: Wiki editing, parsing, login, presentation, poster
Andrew Tran: Wiki editing, Swing debugging, text message to cellphone, poster
Tak Wong: Wiki editing, DB, presentation, poster
Problem and solution overview
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.
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 each of the smaller maps, users can use them to input the coordinates of the source and destination. 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 cell ID (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.
Target user group
We are targetting commutters. Commutters will include drivers as well as transit takers. The users must have a blue tooth device in order to send and retrieve information. The users also must know how to read a basic map. Generally, users who use our software will be those who need information on the spot, those who want an alternative to looking up information prior to leaving the house and even those without internet access. Also, we are assuming that the users are able to see and draw circles on a map. The target user group does not require the population to be tech savvy.
Tasks
Easy Task
Given a map of San Francisco, circle an area and try to locate the closest gas station. 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 gas stations.
Medium Task
Circling a source intersection and then circling an ending destination in San Francisco, then tip the private vehicle box 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 San Francisco and another area in San Francisco, then tap the 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 user will have to locate each bus stop and find out where the South East or North West Corner of X street in order to board the desired bus.
Design Evolution
UI Changes Timeline
Contextual Inquiry
Our initial prediction for our user interface is shown here from the contextual inquiry assignment. We wanted to fit the entire map of San Francisco onto one 8.5 x 11 piece of paper. Our features that were going to be supported were placed at the bottom of the page. We believed that this design was going to be our final design because we saw from the picture that the quality of the map was great. All major streets were labeled and readable, and we did not think users would care about the smaller streets. The map was going to be printed landscape wise because initially we wanted to support the feature of finding traffic information on freeways by tracing the freeway. If we printed the map on portrait the entire freeways that runs across San Francisco were visible, including parts of the freeway that enters SF. We thought that if we printed the map on landscape, the freeway was going to be cut off at the bottom of the map so the user can not find traffic information around that area.
Low Fidelity Testing
After printing our design on paper for the first time, we saw that major changes to the interface were needed. Instead of printing the map of San Francisco portrait wised, we decided to print in landscape because we tried to print it out on portrait and saw that the map was barely readable. The street names were squished together so much that nobody could read the street names and tell which streets are what. By printing the map on landscape the map became more readable. The major street names were more distinct from each other. Our features that our product would support were now place on the right hand side of the page. This was done because we wanted to have more room for the map, and we thought it was more natural for the user to look to his right for the task because normally we as Americans read things from left to right. Another change was we included a box that said “instructions on back”. Instructions were included to instruct users how to use a feature from our system. It was just not intuitive for the user to know that if he wanted to find gas stations or banks of a certain area he needed to draw a circle and then make a check mark.
Interactive Prototype
Some of the UI changes from the low fidelity prototype to the interactive prototype include zoom-in regions vs one big map, reset button for resetting user's actions, grids for easier location of streets, and transition from black and white map to color map.
We decided to dissect the big map into smaller regions because all the users that tested our prototype commented on how hard it was to locate specific destinations on the map. One particularly troublesome issue that occurred was the absence of many street names on the map. This was due to the zoom level of the map. Consequently, in order to allow users to find most if not all of the streets, we have to first display them on the map. However, if we were to display every single street name, the map quickly became unreadable due to crowdedness. In order to get the best of both worlds, the only option was to split up the map. This resulted in much better and faster location of streets as reflected in the interviews.
Due to human nature of committing errors both intentionally and unintentionally, we thought it would be helpful to provide some sort of reset mechanism. This resulted in the addition of a reset button on the interactive prototype. The button let's users reset their source, or source and destination, or simply resetting to make sure it's reseted properly and ready to be used for another query. The last one is very crucial due to the lack of immediate feedback with our system.
Another UI change we made during the iteration from lo-fi to interactive prototype was the addition of grids. As shown by the screenshots. We manually divided the map into smaller grided regions similar to a matrix. We then label each one of these cells with letters A ~ I and numbers 1 ~ 12. This is the front-end to the inclusion of cell ids in the returned directions which we implementated in a later stage of development. With this, the user sees the appended cell id for each street intersection and can quickly go to the corresponding cell printed on the map. This effectively narrowed down the scope of the street intersection and allowed the users to find the location much more quickly than before.
Finally, we changed the base map used for our system. This step incorporated several changes. There is of course the change from black and white to color map. Not only is the color map more pleasing to look at, but it also provided some useful color codes and text effects that aid in locating intersections. For instance, the color map used white for streets but yellow for the major streets. Secondly, major streets were bolded and hence much easier to locate than before.
In the interactive prototype, there is a grid system which is labeled with letters A ~ I and numbers 1 ~ 12, a reset button for canceling user actions, a more zoomed in but dissected map with every street intersection labeled, and a color map. These highlighted features were mostly based on feedbacks received from the low fidelity interview.
Pilot Usability Testing
There are still more changes to be made to the interactive prototype. During the development cycle between interactive prototype and the pilot usability study, we brought back the big map, moved all function buttons and reset button to the front page, added map region to page number reference on the front page, and clear buttons on each of the dissected map region pages.
The reason for reintroducing the big map was due to visualization. It's relatively hard to visualize the entire map, in our case San Francisco, after putting each map region on their own page. We imagined that users who are familiar with using maps are much more used to seeing the entire city or county on one big sheet of paper as opposed to dissected regions. The big map by itself serves little purpose in helping users directly locating the street intersection in our system due to the highly crowded nature of streets. However, if users know roughly where their source or location is located in the city, they can quickly look at the front page as a reference or more technically, a lookup table between regions in the city and the page where the region is printed on.
In addition to having the big map on the front page, we also decided to move all functions buttons and the reset button to the front page. This decision was because we wanted to avoid confusion of having function buttons appear on pages before users are done providing the coordinates required to perform the task. Obviously, we cannot "update" the paper to only show the function buttons only when user have provided enough information due to the nature of the Anoto system. Instead, forcing users to return to the front page in order to complete a task should alleviate this problem. The only potential issue with this implementation is that it brings additional work to users since there is more flipping pages to do but expert users of our system would be able to do this automatically.
Also on the front page are page numbers for each regions of the map. Users of our system can quickly use this lookup convention to find which page they should flip to in order to circle the source or destination on the corresponding regions. This addition was very helpful in allowing users who know roughly where the source or destination are in the city.
One final change we made to the UI was the relocation of the reset button and introduction of clear buttons on each region page. As mentioned before, we wanted our users to be able to easily reset the system so they could restart inputting data for their query in case they unintentionally messed up. Since we have dissected the map into individual region pages, each can potentially be used to input the source or destination, why not extend the feature of the concept of canceling actions by adding clear strokes for each map region. This feature allows users to clear only the destination in case they messed up while drawing the destination. It would be troublesome for the users if they have to start from the very beginning every time they made a little bit of mistake. In the case where they have both the source and the destination on the same page, the clear would be equivalent of reset.
Most Valuable Evaluation Technique
We believe that the most valuable evaluation technique was the low fidelity testing. This technique was very valuable because it exposed many of our design mistakes. The interviewees pointed out many faults with our user interface, and gave many great suggestions on how to improve it. The faults that were pointed out were that the map was too small to read, too blurry to read, not all the street names were labeled, the text message with requested information was in a complicated format, the text message was not informative enough, and there was no way of knowing which direction was north south east or west. The interviewee’s suggestions include having a bigger, colored map, a compass on the page to tell directions, and the text message should include more helpful information on where the locations are. Because of the low fidelity testing, we were able to improve our interface dramatically by implementing our interviewee’s suggestions to exclude previous faults and implement more features that would help the user in finding a location. The maps were now dissected into 12 pages so that each page is a zoomed in region of San Francisco for better readability and visibility of street names. The text messages not only shows where the location but also what region on the map it is in. Not only did the low fidelity pointed out design errors but the low fidelity testing also pointed out some usability errors as well, such as mistaking a destination location and redrawing another one before checking the task. We were able to implement some guard for our system to account for these errors, such as implemented clear and reset buttons and stating directions to clear the page if the user ever makes a mistake for a task. Also supporting the scenario where the user draws the mistakenly draws his destination location at the wrong place and redraws before he makes his check mark.
Final Implementation
Functionalities
The final interface supports our original functionality goals. First, a user can draw one circle anywhere on any of the 12 map regions, tap on the appropriate ATM location or gas station icons. Then, the user will receive a text message with the closest location of what they selected to their cell phone. Secondly, uses can draw two circles anywhere on any of of the 12 map regions, tap on the appropriate trip planning mode and then they will receive the appropriate directions sent to their cell phone.
We also have a cellphone input page located at http://inegai.net/kmatlogin/login.php. A user will be asked to input a cellphone number then download a text file into a specific location. Downloading the text file allows for our program to attach a cell phone number to the computer a user is using and thus, the messages will be sent to the correct cell phone.
Regarding the ATM locations, a user has a choice of selecting one of three major Banks. The three banks are: Bank of America, Wells Fargo, and Washington Mutual. The rationale behind why we selected these main banks are the biggest banks in San Francisco and we believe that most users use one of the three as their bank and hence, will need one of the three's ATMs. Attached to each location of ATM, the cross street of the address and a grid cell (A5, or G7, etc), will be included.
Similar to the ATM locations, we assume that the user will want the closest gas station and thus, we will return any gas stations that are closest to their location because we will not assume that users only use top tier gas stations such as Chevron, Shell, and 76. Attached to each location of the gas station, the cross street of the address and a grid cell (A5, or G7, etc), will be included.
Regarding the trip planning modes, the user can select between driving directions and transit directions. With the transit directions, when the next bus will arrive is also included into the text message. Attached to each bus stop for transit directions, a grid cell (A5, or G7, etc) will be included.
User Interface Design
ATM Locations/Gas Stations:
First, a user can look on the cover page, decide on the area for which they want ATM or Gas Station location and make note of the corresponding page for which their desire area is on. The user can then flip to the page for a bigger view of the area. The user can then circle an area within that page and then flip back onto the cover page and tap on the ATM they want or the Gas station icon. The appropriate information will then be sent to their cell phone.
Trip Planning:
The user can look on the cover page and decide where they want to start their trip at. Then, the user can make note of which page corresponds to their starting location. The user turns to the appropriate page and circles their starting location. After circling their starting location, the user can look back on the cover page and decide where they want their destination to be. The user makes note of the corresponding page for their destination and flips to that page. The user can circle the ending destination, flip back onto the cover page and tap on their mode of trip planning. If the user selects driving directions, then driving directions will be sent to their cellphone. If the user selects transit directions, then transit directions including which bus to get on, which bus stop to get off, and when the next bus will arrive will be sent to their cellphone.
Implementation Details
Map and pen:
When a user circles a location, we will find the center point of that circle in SwingUI.java. After finding the center point(s), the user then taps on their desired task. Depending on which task the user taps on, SwingUI will call interact with the database (see below for more database details) to find the closest intersection corresponding to the center point(s) which translates to either a zip code or two intersections. This information is then passed into getURL (see below for more web parsing details) which connects to the appropriate website, parses the information from the source code, then return a string containing the desired information back to SwingUI. SwingUI will then send the information in the form of a text message to a cell phone through the Phone.java file and using google stmp.
Database:
The database includes five tables that store the coordinates, the street segments, street intersections, the coordinates of each region in the grid, and the scale factor for each page. The coordinates table includes the coordinate of each street segment and intersection and a unique ID (CNN) that maps to the street segment and intersection tables. The street segments table contains the unique CNN, the street segment name (the street it is on, which streets it’s between), the block numbers in the segment, and the zip code associated with that segment. In the street intersection table, it contains the unique CNN, the street it is on and the cross street. The region table contains the x and y coordinates of each grid cell to provide the grid cell number given a CNN. The scale factor table is used to convert from the paper interface’s coordinates to coordinates in the database.
DBParser is the class that interacts with the database. When the user circles an area on a map, the coordinates and page number of that circle will be passed to the closestCNN method. It will convert the coordinates compatible with the database’s cooridinates, then finds the closest intersection associated with the coordinates. This is done by finding the closest out of the four sides that are near the coordinates.
If the user wants to find ATM or gas stations, the CNN given in closestCNN will be used to find the zip code of that intersection, which will be parsed to getURL to find the closest desired locations. After that, the addresses of each location will be parsed to the database through the method regionOfAddr to give the intersection and grid cell of the addresses. We find these by looking at the street segments table, which provides the block addresses, and the regions table, which provides the end points of each grid cell.
If the user wants to find driving or transit directions, the CNN given in closestCNN will be used to find the street names of the intersection through the method getIntersection. These intersections will be parsed to the get URL to get the directions. After that, if the desired mode is public transit, each bus stop will be sent to regionOfIntersection, which will provide the grid cell of each bus stop by referencing the region table.
Web:
If the user selects ATM or Gas Station, the swing will call upon getURL by passing in a zip code. The zip code is retrieved from the database and sent to one of four methods in getURL (findWamuATM(String zipcode, DBParser dbp), findWellsATM(String zipcode, DBParser dbp), findBOAATM(String zipcode, DBParser dbp), and findGasStations(String zipcode, DBParser dbp)). In findWamuATM(Sting zipcode, DBParser dbp), the method will connect to the URL with the zipcode placed within the URL in the appropriate spot and then parse each line in the source code of that page (for wamu, we use www.wamu.com). Using regular expression, the pattern matches the lines that contain the locations and appends all the address of the ATM into a string (final output). Some manipulation of removing tags, placing newlines, cross streets and grid cells (A5, G7, etc) into the code and returns the final output as a long string of all locations. In order to retrieve the cross street and grid cells, the method calls upon a function in DBParser. Hence, a DBParser object is passed into the method along with the zipcode. The same method is used for findWellsATM(String zipcode, DBParser dbp) and findBOAATM(String zipcode, DBParser dbp) with one difference. For Wells Fargo and Bank of America ATMs, we use yahoo.com as the website to parse. Inputting the zipcode and the bank name into the appropriate place in the URL for yahoo, we are able to complete a search with the locations listed in the search results. The same parsing, using of regular expression and manipulations occur (adding cross streets, grid cells, newlines, and removing tags). findGasStations(String zipcode, DBParser dbp) undergoes the same process but uses www.automotive.com.
If the user taps on transit direction, swing will call upon getURL’s findTransitDirs(String street1, String cross1, String street2, String cross2, DBParser dbp) by passing in 2 intersections in the form of 4 strings (first street, cross street of the first street, second street, cross street of the second street). The intersections are retrieved from the database and the same process as above occurs. We utilize www.511.org’s trip planning portion and pass in the intersections in the appropriate sections of the URL. The same processing and manipulation as mentioned above happens. Since grid cells are returned with transit directions, DBParser must be called and hence we pass in a DBParser object. With Driving directions, the method getDrivingDirs(String street1, String cross1, String street2, String cross2), we utilize www.mapquest.com and pass in the intersections in the appropriate sections of the URL and undergoes the same process as transit directions minus returning the grid cells (hence no need to pass in a DBParser object).
SwingUI
In SwingUI, we created 13 JPanels, 13 MapPanels, 13 MapFrames, 13 InkWells, 12 Clear Buttons, 1 Reset button. The 13 JPanels and MapPanels are used to implement the 13 GUIs displaying the map and the InkStrokes. While the user does not need to see the GUI itself, we implemented the GUIs for testing purposes.
We created an array called Centers which keeps track of the source and destination that the user drew. The 0th index being is the source and the 1st index being is the destination.
For every InkStroke, we calculate the min and max of the x y coordinates and average it out. Everytime MapPanel gets a sample stroke, we through the sample with a loop, retrieve the min and max x and y, then divide that by 2. After calculating the center, we store that center
Each time a user draws on a map, on penRelease, we check what the index of that array is. If the index is larger than 1, then we know there are already a source and a destination and we do not save any additional circle the user draws.
We also have an array of LinkedLists called points. Each Linkedlist corresponds to a separate map page with the 0th index being the coverpage and the following pages are maps 1-12. The LinkedList keeps track of all the points that are drawn on that page. Each page, there is a clear button and we want to clear only the points of that page, we will clear the linkedlist corresponding to that page.
For example, if a user draws a circle on page 1, then the center is calculated and stored into centers and into the linkedlist at index 1 of the points array. Then you pass the center point of that circle along with the page number which they drew on into the DBParser method that returns a zipcode. The page number of the center point in the centers' array is stored in the pageForCenters array. The zipcode is then passed into getURL to retrieve an ATM/Gas Station which will return a string of all the information. After getting the information, we delete all the points in the array points and reset index to 0 for centers array.
Login and Sending to Cell Phone
Using php, we created a login webpage hosted on Kang's website on http://inegai.net/kmatlogin/login.php. A user will type in a login page and then php calls on a hash function that will generate a hash key attached to the phone number. The phone number and hash key is then stored in a table called Login in the database. Then user is then redirected to another page where they are asked to download a text file (named hashkey.txt) containing the hash key into their C:. The text file is generated using php file functions.
We then created another file called Phone.java. Phone.java will read the text file and retrieve the hash key. It will then connect to the database and find the phone number attached to that hash key which will then provide the correct phone number given that the user has downloaded and stored the file in the proper place. The phone number is then passed into a class in SwingUI which sends the text messages to the proper cell phone. Sending the text messages uses Google's stmp package.
Most Difficult Part(s):
Implementing the interaction with the database probably represents most difficult part to implement. First of all, converting from the paper coordinates to the database coordinates posed a difficult challenge. The first problem we encountered regarding conversion was the fact that we had to find the cut off points for each map on a sheet and each grid cell (in order to support the grid cell system). Sometimes, the conversions can be off due to various reasons (one main culprit could simply be the way different people hold the anoto pen). Secondly, and more importantly, finding the intersection using the center points was more difficult. It required we having to figure out a correct set of queries that will look at the intersections near the center point(s) and finding the minimum distance between those intersections and the center point(s). The problem arose when attempting to find the minimum x and minimum y. The minimum x and minimum y should map to the same intersection. However, because the coordinates were off at times, the minimum x will map to one intersection while the minimum y will map to a completely different intersection which then require more complicated queries that will find an actual intersection that exists in San Francisco.
Unimplemented Item(s)
We did not implement freeway and traffic information. Finding the optimal website to parse was difficult. Originally, we thought about using www.sigalert.com because it let us input where we wanted to enter and exit the freeway. Then it provided us a approximate speed of the route based on the current traffic information and any disruptions along the route, such as traffic accidents and road constructions. We were able to use this website because we were unfamiliar with parsing input through javescript. We were unable to find an alternative website that will give as accurate and complete information as sigalert. Therefore, we decided to drop this functionality since there are six other tasks the user can perform already.
Wizard of Oz
Our original idea was that a user can be in the middle of the streets and would still be able to use our system. However, doing that would require passing the information from the pen to a cellphone's bluetooth and then sending that information to our server to complete the process. However, because we do not have access to the firmware of the cellphone and thus, cannot send directly without a bluetooth enabled computer nearby.
Miscellaneous
Code
Readme
Presentation
Final Prototype Presentation Slides
SSS Pages
