FinalPrototype-Group:GeoPhoto
From CS160 User Interfaces Fa06
Team Contribution
Yang Wang: Writing the Batch Handler, writing Target User Group, Writing Design Evolution
Andrew Hao: Further development of Swing UI, building backend stroke-to-photo matching, worked on document [Final Interface, Problem/Solution, UnimplementedFeatures]
David Wallace: Paper coordinate to Google Maps lat&lon coordinate conversion, poster.
Jack Yeh: Did not participate
Problem and Solution Overview
Photo journalists, wedding photographers, avid bloggers and web geeks alike all tend to share large online presences and tend to post photos often to share with professional peers, friends, family or simply into the aggregate online community. With the advent of mapping software (e.g. Google Maps or Yahoo Maps, people have discovered new ways to build mashups, mixing any sort of data with geo-locational data to create useful visualizations, summaries, and the like.
Problems
Now Flickr has built an online interface to drag-and-drop images onto an existing map, thus pairing the image with the latitude and longitudinal coordinates. This is actually a very intuitive interface to browse photographs with, but the actual process of creating coordinate-photo matches has two identifiable problems:
- It requires that locations be determined after the photographer has returned from his or her photoshoot. By this time, the photographer may have forgotten the exact location of each photo and will tend to guess and/or not geotag the photo at all.
- It is largely still a very clunky interface, being built in AJAX in the browser. Load speeds are dependent on client bandwidth connections. JavaScript must run within the client browser and has relatively slow performance (thus, the interface is noticeably unresponsive at times).
The GeoPhoto Solution
GeoPhoto, touted as a "Portable Photo Tagging System" aims to help end users overcome these two hurdles by working in tandem with Flickr's map interface.
- GeoPhoto allows the user to "bring the map into the wild" and allow the user to mark his or her location on the spot of the picture. This reduces the load on the photographer who would previously have to recall the locations of his or her shots.
- GeoPhoto provides a local Java interface to the Flickr web service, whose byte-compiled code runs much faster than a browser's JavaScript runtime modules. It additionally provides a quick and easy parsing and matching of pen data to uploaded photographs.
In summary: GeoPhoto lets users overcome the clunky Flickr geotagging interface hurdle via portable, pen-based tagging and easy uploading.
Target User Group
GeoPhoto is targeted at people who love to share photos on Flickr with other people, but who are frustrated with the slow and rather cumbersome geotagging interface the service provides. Our target user group will be Flickr users who tend to take large quantities of photos, who upload very often, and who would like to utilize the geotagging feature but looking for a solution that is quick and easy. People who potentially fit this category are bloggers, photo journalists, hikers, explorers, scientists for nature studies, or simply college students who travel a lot.
These people make up a small minority of all photographers, but we believe that there is a niche for software that focuses on specific needs of specific people (as opposed to software that attempts to do everything in a mediocre fashion). This puts our application far into the "long tail" of software applications. We will design our software to best meet the needs of this small group of Flickr-savvy, web-literate photographers, hoping to gain their approval, devotion, and deserved buzz.
Design Evolution
There are much migration between each stage of our prototype. It is great that we went through so many design stages. This really filtered out a lot of our problems. There is actually not that much difference between initial sketch and our LoFi Prototpye. We have listed below our Lofi Prototype on the left and our initial sketch on the right:
Comparison of Initial Sketch and Lofi Prototype
 |  |
 |  |
 |  |
 |  |
 |  |
As you can see from above, there are not many differences between the interface, this results from the fact that there are relatively shorter time period between our initial sketch and output of our LoFi Design, and there are no real user testing involved in the process.
Now, let's get to the exciting part. The first huge evolution comes from the change from our LoFi Design to our Interactive Prototype:
LoFi Design to Interactive Prototype
1. We added a main menu in the front, so that users are not confused with what they are suppose to do with our program. In here, the task is very clear, there are two things user can do: print a map or sync their pictures. This is due to the fact that our software is relatively new to all the user, and most people are overwhelmed with the idea of Anoto Pen, this gives a clear guide and help them build confidence in using the software:
2. We added an instruction menu before the printing process. Although there is a help link on our original design, but since our software is so foreign to even the frequent flickr users that they are just overwhelmed by the interface and ignored the help. We made our new help into a step of the process so user have to see it. However, they have the option of "Do Not Show Again" availabe. We also kept the "help" link, but changed it to "What is this" to give more understanding.
| |   |
3. We changed our map interface as well. First, we realized that to design an user-friendly interface, there are three important things. The first is clear instructions, the second is clear instructions, and the third is still clear instructions. Throughout our LoFi Testing stage, the users chose to ignore the instructions. Thus, we made the instruction much bigger in our new design. Also, we decide to provide multiple check-boxes for the user to check next to each tag, so that users won't be confused when they are tagging multiple times.
 |
4. We also added some clearer instruction for the authentication page. Not much is changed on that part.
5. Here is the next part that changed drastically: we decided to change the format of our preview panel. Since that we have learned from class that unless we come out with unique and great individual designs, we should try to copy the traditional designs. Thus, for the picture preview panel, we decided to copy the format the windows has previewing pictures. We also added check boxes at the corner of each picture to indicate uploading status. This is copied from other picture uploading tools.
| |  |
Interactive to Final Design through Pilot Testing
1. Although we thought that our main menu is fairly clear to users regarding what they should do. But during our Pilot Testing, extra instruction were needed to give users a clear understanding. Thus we added instruction on our main menu. (See Below Figure 1)
2. At the menu for user to print and save map. We also relaize from our Pilot testing that user have no strict preferance of saving the map into pdf and print it or directly printing the map from our software. Thus along with timing issue, we decided not to implement the printing feature. (See Below Figure 4)
3. Also, for the map interface, our effort in trying to provide multiple check boxes did not receive the desired feedback. We decided to go back to our original design. (See Below Figure 7)
Conclusion (Which Stage is Most Import)
As you probably can tell by now, the most important test is actually the LoFi user test. This early test really ironed out a lot of the user problems that we have. Since our project is not a very complex software with a great variety of functionalities. Even a simple paper UI design can provide the a large amount of feedbacks. Although an interactive prototype also revealed a lot of problems that cannot be revealed by a Lofi test (ex: how feature can be implemented). But we caught most of our problems early on, with the LoFi test, which saved us a great amount of time developign the interactive prototype, since it steered us toward the right direction. As a result, we have large clean up but minimal structural changes toward the later stages of development.
Final Interface
Final UI Design
After listening to our users, we went back to the drawing board and implemented the following changes:
Redesigned Home Panel
The home panel sometimes confused users as to what to do, so we added text to explain to users which "path" (print/sync) they were to take depending on where they had started.
Figure 1: The modified home panel.
Guided Tips
Users gave us feedback that the pop up dialog tips were extremely helpful in finding a Google Map and determining what tags were. We did manage to change the wording in the Google Map tip (Figure 2), helping users look at the "upper right corner" for the "Link to" link after a few users had trouble finding it.
Figure 2: Google Map Dialog Tip
Figure 3: "What are Tags?" Dialog Tip
Additionally, the tip no longer appeared as a separate frame apart from the print-map panel. They are now implemented as JDialogPanels, or better recognized as a simple dialog box whose connection to the parent frame (the print-map panel) lets users keep context of where they are in the application.
Simplified Print Panel
We realized that we would not be able to directly print the map from our Java Swing application (not without purchasing a commercial license to third-party software) so we decided to rid ourselves of the feature, instead guiding the user through the process of saving and printing a PDF. This has the benefit of cleaning up the clutter from our previous interface (there were a bit too many options and users would not know whether they wanted to print or save). Funneling users through the process of saving a PDF made it easier to understand that they would continue by clicking the "Save Generated Map" button (via the double right angle arrows).
Figure 4: Generate Map Panel
PDF File Filter
We added a PDF file filter to the save box after users complained that they did not know what format to save the file in. The software backend detects whether the ".pdf" extension was entered and if not, automatically appends it.
Figure 5: The PDF File Filter
Smooth Closing and Guided PDF Open
We now smoothly instruct the user to close the application and automatically open the PDF handling application on their desktop with instructions to print the map from there.
Figure 6: Guided instructions after saving.
Figure 7: The application has called Adobe Acrobat to open the newly-saved document.
Reworded Map Instructions
See Figure 7.
We decided to not go with our multiple-checkboxes configuration that we proposed in the HiFiPrototype. We modified our wording on the map to "tap" the tag boxes and chose to only provide one tagging region (box) for users to mark. We felt this was the most straightforward solution to implement (making our job on the back end easier) and additionally, we determined that once a user learned that all that was required was a tap in the tag checkbox region, the learning curve would be so low so as they would correct their behavior (should they have drawn lines or circles or filled in the box) instantly. Regardless, the functionality of the software is still maintained regardless of the user's behavior.
Additional Detail on Upload Preview
The upload preview displays images, but based on user feedback requesting more information relating to the image, we added panels that display the file name and associated image tags to that image. Additionally we added labels to every panel to identify to new users their functions and effects (see the bottom-left thumbnail panel for an example):
 |
Figure 8: The upload preview panel with additional data.
Color-Coded Upload Hints
We added color-coded hints (green and red) to indicate to users that a certain image was selected or deselected. We are aware of the cultural biases that red and green carry and that may not translate to other cultures, but we felt that red and green were universal enough (to the majority of Flickr-users, who happen to be North Americans) to use as color codes. It is subtle, but we also made the red a little darker than the green to help our color-blind friends.
Figure 9: A deselected thumbnail is red.
Threaded Upload + Progress Bar
Upload is now running in its separate thread with a progress monitor bar indicating progress. Previously the application would freeze when the upload began because the process would run in the event manager thread. Now the application gives accurate, clear, quick feedback.
Figure 10: How snappy.
Saved Flickr Authentication
The application stores the previous login attempt to Flickr, and gives the user the application to use the preexisting login or to authenticate as a new user.
Figure 11: The saved authentication panel.
Interface Conclusion
Functionality
The GeoPhoto interface allows users to easily add geolocational information to their photos and upload them to the Flickr photo sharing site (with locational information intact).
UI Design
The GeoPhoto software will facilitate the generation of a user-specified paper map with optional buttons to add folksonomical data (e.g. tags) to the photo. Users will take this map and, as they take photos, will simultaneously mark locations on the paper map with a digital Anoto pen (adding tags by tapping on their regions as desired). As they return to their computers after taking photos, they will choose the images they wish to sync to the pen data (which is automatically parsed by the GeoPhoto software as the pen is inserted into the cradle). They will give their login credentials to Flickr and then the GeoPhoto software will upload the photos along with their longitudinal/latitudinal information.
Implementation
We implemented GeoPhoto in Java Swing, hooking into the Google Maps API, the Flickr API (via the FlickrJ java wrapper) and used a third-party EXIF scanner to parse image dates. The toughest part of the assignment was working with the limitations of Swing and the event-driven model, which is powerful but is cumbersome to use and at times, unintuitive (we faced many challenges of program organization, as none of us had developed event-driven programs prior to this project).
Unimplemented Features
Was Anything Left Out?
Nothing was left out; we have implemented everything we set out to implement.
Wizard of Oz
We need to lighten the map manually via Photoshop because the dot pattern will not be recognizable otherwise.
Oral Presentation
Image:GeoPhotoFinal-FinalPresentation.zip
Source Code
Image:GeoPhotoFinal-FinalCode.zip
Poster
Image:GeoPhotoFinal-Poster.zip
