LoFi-Group:GeoPhoto
From CS160 User Interfaces Fa06
Contents |
Introduction and Mission Statement (6 pts)
Introduction to the GeoPhoto Tagging System
The GeoPhoto tagging system allows a user to attach geographical metadata to their photos for upload to the Flickr photo sharing site (where the geographic information places the photo on a site-wide map of all "geotagged" photos). The general process for accomplishing the task is the have the user print out a paper map of the location they wish to photograph over and mark each location on the map after every photo, effectively correlating the photo and its coordinate. The software system will coordinate the upload of photo and geographic metadata to Flickr.
Purpose
The purpose of this project is to design a paper prototype interface and test it with a representative sample of users. By observing users via the process of low-fidelity prototyping, we will quickly and easily gain insights into the design flaws of our prototype. Iteratively, we will refine our design based on the feedback given to us by users.
Mission Statement
As programmers, our goal is to make people’s life just a little easier. With the modern technology today, information travels at amazing speed on the super highway of World Wide Web. We should have all the information we need within our grasps. But due to bad designs and complexity of the technology, we see ourselves troubled, overwhelmed by all things that are available to us. Ironically, all this mordern tech is not making our life simpler, we are not doing our daily tasks fasters, but rather get distracted. This is why, for this project, we make it our goal to brings the convenience of technology to people. We want to solve a real life problem that people are facing, some practical application the people will use. That's why we choose GeoPhoto, a plug-in application for Flickr that completes Flickr and make it easier to use.
Roles
- Andrew Hao: facilitator (2 trials), computer (1 trial), introduction, design & creation of lo-fi paper mockups, consent form, demo script, participant descriptions
- David Wallace: observer, Photoshop mockups, test procedure, test measures, compilation of process data, results
- Yang Wang: contacting subjects and arranage interviews, being the computer, being the observer, mission statement, participant descriptions, written part of the discussion
- Jack Yeh: N/A
Prototype (12 pts)
We made a paper prototype from pen drawings on sheets of paper. We printed out sections of Google maps and pasted them into the interface in a few places so the user could interact more authentically with the system.
Because these were difficult to read once scanned, we also made a mockup in Photoshop for this web page.
(1. Printing)
(2. The Map)
(3. Authentication)
(4. Collection of Pen Data and Images)
(5. Preview and Upload)
Method (12 pts)
Description of Participants
Howard
Howard takes pictures regularly for his outing with his friend. He is very competent with computer and consider himself a regular user of flickr. But he doesn't like to use flickr because he consider it very troublesome and hard to navigate. Since he doesn't really have any alternative, he is willing to settle for that. He have about 12GB of photos and is still increasing his collection every month. He knows his camera very well, and keep his pictures very organized on his computer. But he also uploaded his picture to the Flickr webpage to share them with his friends. He do going on hiking trips a lot, and something that automatically tag the geographical location of his pictures will help him. We found Howard through references from people we knew. We called him and arranged a meeting with him.
Jonathan
Jonathan doesn't consider himself a loyal user of flickr, but he use it often enough, 1-2 times a month, to call himeself a flickr user. His main reason for not using flickr is the interface it has. He feel that he need something a little easier to use. Flickr is very flashy and cool, as he described, but he will much rather have something done in a couple clicks. He has a large collection of photo since he travels a lot. He just came back from a trip around Europe and want to share it with his friends. But the idea of taging all of them annoys him. He knew about the geo-tag feature of flickr and tried it. But he didn't like it and prefer something more simple. When I describe to him what we are doing, he feel that will be really helpful on his trip. Chris was a friend of Howard's (we interviewed them both in the same Unit 3 lounge).
Jenny
Jenny is a computer science major who considers herself an avid technology user. She loves the idea of being able to track and keep locational metadata with her photos. Her usual photos are usually of her and her friends in various outings (say, San Francisco). She believes that the GeoPhoto system could help her better share her photos with her friends by making them easier to discover and locate, particularly with the geotagging feature (she feels that it could be a good way to keep a photo trail of her adventures in San Francisco). We leveraged friend connections to find Jenny and invited her to test with us at the Free Speech Movement cafe.
Testing Environment
Location
The three tests took place in two locations: A lounge in the Unit 3 dormitory and a table at the Free Speech Cafe. In all cases the participant sat across a large table from the "computer", with the facilitator and observer sitting by his/her side. The Unit 3 lounge had a couple of other noninterfering studiers (not involved with this experiment) sitting at other tables in the room periphery. Overall, the lounge had a quiet ambience and we were able to talk without any distractions. The Free Speech Movement cafe, however, was a tougher place to test because of the ambient noise of lunchgoers. We generally did not notice any communication issues with our subject, but one of our members did note it was harder to hear and record the subject responses.
Roles
Each of our tests had between two and three people present (having the full group would have been optimal but scheduling constraints prevented us from all being present). The tests at Unit 3 were facilitated by Andrew and Yang (Andrew played the Facilitator and Observer, Yang was the Computer). Andrew did not find it hard to play two roles, but he found it harder to take notes while speaking as the Facilitator as well (we realize that in the future a video camera would provide a better way to review the session and could possibly substitute for the Observer). The test at the FSM cafe had David, Yang and Andrew (David played the Facilitator, Andrew was the Computer and Yang was the Observer).
Tasks
The tasks to be performed were given to the user part by part, with verbal explanation from the facilitator:
- Print out a custom map using the wizard. (Assume you already have the correct map URL in the computer clipboard.) Before you print, be sure to add the six tags "Bancroft", "Durant", "Channing", "Shattuck", "Dana", "Oxford"
- Take three photos:
- Photo 1: at the intersection of Fulton and Bancroft. Tag this photo "Bancroft".
- Photo 2: at the track/field on campus. Tag this photo "Bancroft" and "Oxford"
- Photo 3: at the Campanile. Do not tag this photo.
- Follow these steps to download your photo data and upload to Flickr
- Sign into Flickr, assuming you have an account already. Click on "OK, I'll allow it" on the Flickr authorization screen.
- Follow on-screen instructions to download pen data.
- Assume the pictures you took were IMG_0001.JPG to IMG_0007.JPG. Select them for opening.
- On the photo-map visualization screen, deselect the fourth image.
- Upload the resulting photo.
Test Procedure
- First, the user signed a consent form.
- We described the concepts behind our application and some situations in which it might be useful.
- We then set up an imaginary scenario for the user to follow: that he/she was going to take photos of the Berkeley campus and geotag them.
- For each of the three tasks (above), the user was read the task and then left on their own to explore the interface with the computer. As they did so, they talked about what they were doing and we took notes.
- Finally, the user was given a chance to ask any further questions about the interface. We also took this time to discuss any critical incidents with them to further understand their thought process.
Test Measures
For a perfectly successful test, we expected the following checkpoints to occur:
Big-picture requirements:
- The user understands the concept of geotagging well enough to use our application.
- The user experiences no confusion or doubt about our interface.
- The user is able to complete the upload process in less than five minutes.
Bottom-level requirements:
- The user can successfully use our Print interface to print a map with the tags they want.
- The user marks locations and tags on the map in the correct order and with the correct kinds of pen marks.
- The user can authenticate our application with Flickr.
- During upload, the user can toggle whether certain photos will be uploaded.
Results (12 pts)
Overall, the users were able to figure out how accomplish the tasks we gave them. However, all three had difficulty in understanding our interface.
On the positive side, all of the users were able to complete the upload task in less than five minutes.
Printing Task
One user did not fully understand the idea of tagging. Our interface does not explain that the tags you enter in this step are for future use. She thought she couldn't enter tags to print because she hadn't taken any photos for them to apply to yet. This user also seemed unhappy about having to get a Google Maps URL in order to print a map. The workflow for that step is awkard in that it requires the user to perform a complex subtask while remembering their place in the more general task.
Photo Taking Task
Here all three users had tag-related difficulties. One user forgot to include all the tags he needed when printing a map; by the time he was out in the field, there was nothing he could do about that.
Another user didn't understand that tags are different from geotags, so she didn't know that the tagging feature existed.
The third user became distracted by the tagging feature and forgot to circle his location on the map. In this case our example tags were names of places on the map; therefore he thought he should check those boxes instead of circling spots on the map.
Uploading Task
This is the most complex part of our interface and accrued the most critical incidents. Unlike the other tasks, there were no problems here were with major misconceptions about the use of our tags and geotags; instead, they were smaller usability hiccups.
One user waited for the pen to be detected automatically instead of clicking "Get Pen Data". Another wanted to continue using Flickr instead of returning to our app after authentication. Our app was lacking in a strong sense of process and "what comes next".
One user was intimidated by the image selection screen. They wanted a clearer way of selecting multiple files since they were unsure how to use the operating system's built-in methods of multiple selection. Our user was a Mac person; our interface was modeled after Windows.
A user revealed that we did not have a clear idea what should happen when certain Cancel buttons were pushed.
In the last phase, users figured out how to toggle the upload status of certain images, but it was not immediatly intuitive to them due to lack of explanatory text.
Discussion (12 pts)
General
We discovered that we had made several assumptions regarding the user's preexisting knowledge of the Flickr system that we could not necessarily assume. We also realized that the digital pen-paper-computer paradigm was so new to people that they needed more thorough explanations as to how this system worked and why it would benefit them.
Task 1: Printing a Map
We learned here from Jenny that the concept of "tagging" was foreign to her. She completely skipped adding any tags because she didn't understand what they were. Howard seemed confused as to why he was adding tags, until we explained that they were for future markup on the field. Thus, we can do a better job of explaining why the user is here and what each field is for. This will mean a reevaluation of semantics and a reformulation of our wording. Additional tooltips and "(why?)" or "(help)" links would better guide the user to an understanding of the system. We will need to make it more clear that these tooltips / help popups are useful -- but even then users may ignore them, choosing to plunge ahead into the interface as Jenny did (making errors in the process).
Another possibility is to devote a page before the printing map page to explain the reasoning behind printing a map. In that page we will tell the user to go to google map, find the map of their desire, and copy the link into clip board. There will be next button on the bottom for them to proceed to the step of printing the map. This will be a better solution, since it took some of the users awhile to find out the help with "how".
Task 2: Using the Map & Pen
Here we encountered the most variations in user responses. Howard completely misunderstood how to use the paper interface, he tagged photos but neglected to mark each photo with its location. We need clear instructions on the paper interface alerting the user to proper procedure for geotagging and tagging. Perhaps numerical instructions, step-by-step would be appropriate, forcing the user to follow a certain order of action.
We learned from Jonathan that users desired control over their tagging -- when Jonathan forgot to tag a photo, he expressed disappointment that he could not go back and edit that photo's tag. While this may more be the limitations of the pen and paper system, it is an interesting problem that could perhaps be solved with certain actions coded onto the paper interface (say, a "clear" or "undo" field). Here we realized certain drawbacks to the pen-and-paper interface -- there was no feedback mechanism to alert the user whether their action was successful. Here we would hope that future Anoto-enabled pens would include some sort of visual or auditory cue to indicate certain actions had been performed successfully.
For Jenny, we notice that she chose to circle the location on the map rather than putting a dot to it, as the other two subjects demonstrated (who chose to put a dot on the map). This reminds us that there are many way that users may choose to interpret an instruction, and we have to be extra careful in giving the instructions. Rather than "mark the location of the photo" on the map, the instruction should be "Mark with a dot the location where the photo is take" or "circle the area where the photo is taken".
Task 3: Downloading & Uploading
Jonathan attempted to cancel certain instructions and in doing so, we realized that we had not fully thought out the flow of the interface. Where did a cancel action lead to? The previous page? What data should persist after a cancel action? What state should the program be in? We will take these into thought.
Howard expected the pen to automatically download data once it was in the cradle. If possible, that would be a good idea to implement, but until then we should reword the task description of pen download procedure to be clearer.
Most users were able to discover, after a few moments of hesitation, that clicking on a photo in the visualization map hid it from view. However, they all expressed wishes that it would be more clear. We will look into implementing certain hints or tooltips that would make it clearer to the user. But we confirmed our belief that clicking on a photo to disable is a good way to implement the interface because that is always everyone's first guess at how it should work.
Overall, our program interface follow the traditional tutorial style. It definitely makes users more comfortable and are more assured that they are doing that right thing. People walked through our program with not much of a problem, but they have expressed that adding more help and hints will speed up the process.
Unanswerables
Our test process was unable to account for intermediate processes that were assumed to be performed prior to the usage of the software (that is, the user in the first task was assumed to already have used the existing Google Maps site to find their map URL, and for the third task, the user was assumed to have already downloaded their camera photos to their computer). These actions may not be intuitive to many computer users and could perhaps be streamlined and integrated into our software workflow.
Appendix (6 pts)
Process Data: Critical Incidents
Printing Task:
- User C said "I haven't taken any pictures yet; how can I tag them?". She didn't know that she should be writing tags she will be using in the future.
- User C didn't see the "(how?)" help link on the URL field.
Map Task:
- User A marked tags on the map, but did not mark a location on the map. He did not notice the written instructions.
- User B realized that he had forgotten to include a tag on his map; there was nothing he could do about it now.
- User C conflated the terms "tag" and "geotag", leading to some confusion.
Upload Task:
- During authentication, User B expected to complete the rest of his tasks on Flickr instead of returning to our app.
- User A expected the pen to automatically download when in was placed in its cradle. He sat and waited for that to happen.
- User A had trouble selecting image files; he wanted to use checkboxes instead.
- User B clicked "Cancel" during image selection and revealed an incompleteness in our workflow.
- When re-enabling a disabled photo, all 3 users had a moment of hesitation, but correctly guessed that clicking again would toggle the photo. They wanted clearer text or tooltips indicating that you can re-enable photos by clicking on them again.
