Alex Pretzlav - Programming: Implemented back button return to user, changed menu system to use Android's built-in Context menu interface, changed how nav-button taps are calculated to be consistent irrespective of zoom, added warning popup if next person to zoom in is more than two miles away, helped enhance meetup feature visually and functionally, including allowing it find real locations via Android's Geocoding features; various bugfixes, refactorings, and tweaks. Writeup: Problem and Solution Overview, Target User Group, Tasks, added screenshots and some writing to Final Interface Section, in Functionality of Main Menu and Implementation.
William Tseng - Created skeleton for the "Settings" item on the menu which is essentially the advanced options page. Extended person.java to include levels of separation and updated main map populate / draw functionality to take separation into account. Small bug fixes. Helped write Final interface section of writeup.
Chris Myers - Programming: Read the phone's contact data to put them as friends on the map. Automatic (best fit) zoom feature. Toggle satellite/map view. Cleanup of AdvancedMenu code. Corrected issues from changing to Context Menus. Various bug fixes. Writeup - various sections, proofreading, screenshots for Final Interface. Working on poster.
Joe Cancillia - I was responsible for most of the Meetup functionality. With Alex's help I programmed the display of multiple location results. I set up the arrows that show up when moving between locations. I figured out how to make sure that locations were cleared when the user pressed the back button and cleared. I created the MeetupTime Activity which allows the user to set up a time for the Meetup.
Problem and solution overview
The problem with current social networking applications is they do not facilitate social contact in the "face-to-face" sense. Users of existing social websites are often left reading about an activity one of their contacts is currently doing in an away message or status box on their computer instead of participating in that activity. Users are often limited to leaving electronic greetings of "hi, hello, how you doing" instead of being able to tell someone face to face.
We want to resolve these problems by using the unique affordances of a mobile application. By going mobile, our users have access to their social network anytime and anywhere they have access to a cellphone. Using GPS, our users will be able to see where their friends currently are relative to their own position and quickly and intuitively communicate and organize with those friends. We hope by getting social networking off the computer, Friend Finder will make real-world socializing easier and more accessible, rather than limited to a computer.
Target user group
Our target users are generally social people of college age to late twenties. They are already users of popular social networking sites, but don't like spending all their time at a computer. We aren't targeting heavy users of current social networking sites—we hope our application will appeal to socially active people who have been so-far turned off by the limitations of current computer-oriented social websites. They are not necessarily tech-savvy, and we don't expect them to either know everything about social networking or their phone. We imagine most people in this age group who would be buying an Android phone are already familiar with popular internet technologies like Google Maps.
- Change visibility from invisible to visible. We expect privacy to be a major concern of users of our program. There are many situations where someone will not want to be interrupted or simply not want friends to know where they are, so we wanted disabling and enabling the ability of friends to see your current location to be a very easy and straightforward task.
- Search for a friend by name who isn't visible on the map. If a user wants to contact someone in their social network they have to look them up somehow. In addition to the default map view of our program where you can see friends displayed geographically, Friend Finder can center the map on a specific person. To do this, the user brings up the main menu, selects search, types in part of the name of the intended friend, then selects from a list of names formed by the auto-complete android widget.
- Organize something to do with a friend. The real point of social networking is not just to have a list of friends and to be able to see what those friends are up to. We want people to organize activities, meetups etc with their friends. To do so you a user picks a friend, selects an activity, finds a location and then sends the information to the friend so that they'll know where to meet.
Changes from low-fi testing through Final Project
Easy Task changes
We have changed the location of the broadcast on/off from menu -> settings -> broadcast to living on the main menu itself. This will reduce the number of clicks necessary to access this feature. This change was implemented after we saw confusion in the third user of our low-fi prototyping. The third user when asked to change broadcast status, completely exited the application and restarted it in order to bring up the default "broadcast on/off" dialog box which comes up when the program is first started. She did not know that a middle button click when she herself was highlighted would bring up an option menu which would allow this option to be changed.
This is what our menu bar looked like in low-fi prototype
This is what our menu bar looks like in the interactive prototype
This is the menu bar (and map) from the pilot study prototype
Or original Lo-Fi prototype's Visibility/Broadcast switcher:
Successive Version storyboards: (Later Versions have different menu - thats all.)
Medium Task changes
In our low-fi prototype we originally had a single screen for entering search criteria (name) and a separate screen with the results. When we went about implementing the functionality we realized by using the android auto-complete widget we would reduce the need for separate screens. The autocomplete field would automatically generate a list with several selections which match. The user would then be able to select from the autocompleted list. This reduces the number of screens the user has to go through and would help to maintain continuity as they would never really be more than 1 screen away from the default map screen.
In addition by using the dialog theme we are able to have the search screen pop up as transparent overlay over the main map instead of a separate black screen. This also helps maintain a feeling that one is always close to the default map screen.
Except for some back end stuff with the Person class, this activity remained unchanged for later versions of the program since users seemed relatively satisfied with it.
Hard Task changes
This is what we had envisioned during low-fi prototyping.
Much like our Lo-Fi prototype, organizing a meetup with a friend is a simple matter of selecting them on the map, choosing meetup, and choosing a type of place to meet up. Our prototype does not yet allow a user to specify their own criteria for finding a place to meet up, and currently only offers one option, as opposed to our Lo-Fi prototype, which allowed the user to browse a series of possible options.
From our Interactive and Pilot Study Prototypes:
Note the change in style for the context menus. The new context menus may not be as attractive as the old style, but they popup a lot faster, which is important for the user, and greatly simply the code, which is important to us. Additional testing might be necessary for the menus. One thing that might help is to reduce the width of each line item, if possible. Also, actual results for places in the area.
- changed from a static String arrays to represent lists to more easily mutable arrayList implementation
- added ability to scrape data from Android phone contact content provider
- added implementation of "advanced settings" page.
- added ability to change viewable friends on map based on their degree of separation
Comments on Evaluation Techniques
- Usually simply viewing how users actually used our interface was sufficient to show flaws or things we hadn't though of. This showed us why something like contextual inquiry is valuable.
- Even though we did try to count clicks and key presses on a number of occasions these often felt like we were doing these things just because they were suggested in the readings. I think in larger scale studies and once the program is finalized more and you are just trying to optimize these types of evaluation techniques will be more useful but since our project is really in the early stages of development where ideas arent set / fixed yet, I think quantitative evaluation had less of an impact than advertised in our readings / lecture.
- Numbering the serverity ratings did help in allowing us to know which items were higher priority when we were allocating tasks and thinking of what functionality to fix / implement as we stepped through the iterations of our program.
Our application can basically be divided into two main parts. The main map interface and the menu bar and its functions.
Main map screen
- cycle through friends on the map
- pan around the map
- display your friend's status
- Press the back button to center on yourself. If you are browsing locations, the back button will instead return you to the person you were trying to meet up with, then pressing it again will center on you. If you press the back button when you are already centered the program exits following the standard Android behavior
- bring up action menu
- change your visibility
- change your status
- bring up action menu for others
- call your selected friend
- Text Message that friend
- Meetup With that Friend
- Selecting Cafe, Bar, Restaurant lets you browse through the nearest places to the midpoint between you and your friends.
- Directly call a friend by pressing the Call button when they are selected on the map
- Change the map between Satellite and Map view
- Zoom in and out on the map
- Autozoom to show all friends by pressing 'P'
- Switch your own visibility on and off
How to use
- To cycle through your friends you "tap" the DPAD in a direction and the application will center on the next friend closest in that direction. If the person is more than two miles away, a warning is shown (see picture).
- To pan around the map, simply hold down and "press" a DPAD direction. This will result in the map scrolling around instead of snapping to center on a Friend's location
- To display your friend's status you simply have to center on them and the FriendFinder application will automatically fetch their status and display it on screen
- You can bring up your own action menu by pressing the CENTER button when you are selected, or by selecting "My Menu" from the main Android menu.
- You can change your visibility after having brought up the menu by selecting the correct radio button by using the up or down DPAD and then a CENTER press to confirm
- You can change your displayed status after having brought up the menu by entering text corresponding to your status and then selecting save.
- You can bring up an action menu for others by pressing the CENTER button when someone else is highlighted
- Selecting CALL will result in the FriendFinder application bringing up the android dialing application and dial the friend you have selected
- you can send a text message by entering text and selecting send
- You can arrange a meetup:
Once you have decided on your place, hit the center button. This time chooser pops up:
Your friend gets an autogenerated message of the time and place to meet.
Some interesting notes about some of the implementations of the above functionality
- To differentiate between a "tap and a "press" we decided through a little testing that if the movement of the map while the key was down was less than 7% of the width of the screen, the intention of the user was probably a tap and not panning the map. Users complained that the selecting/scrolling of the map was 'unpredictable' or 'odd'.
- To decide who to center on we searched all people in the given direction from the current center, and picked the one with the shortest vector distance from the current map center.
- When we change visibility we have the results appear in 3 forms of feedback:
- The text at the top of the screen changes between visible and invisible
- a pop up window appears notifying you that you have changed your visibility
- your circle representing yourself on the map changes color to dark grey
- We thought of "Away messages" and "Facebook status" as key components to social networking applications so we wanted the status to be visible along with the contacts name.
- When searching for locations to meet up at, we're currently using some undocumented features of the Android API. This allows us to find real places based on arbitrary locations and queries, but unfortunately the Android API for this feature is still unfinished and the name of locations is not available, so we used the URL instead. Hopefully Google will fix this in a future update.
- Feedback during classroom presentation suggested that the satellite mode is 'too crowded', so we implemented map/satellite switching.
- Also it was suggested to us during our presentation that friends far away would disorient the user. For this we implemented show all friends on the map zoom button - 'P'. Also, when you browse someone far away, a prompt appears letting you know the distance before the map pans.
Left out and Wizard of Oz
- A "target" box on the main map which would bring up someones status and focus on someone if they are in the middle of the screen after having used the "panning" functionality of the map.
- tie in real SMS / Txt with the Texting application
- tie in ability to really enter in a custom meetup location
- "friends" gps locations are currently randomly generated instead of grabbed
- Search button - allows you to search for a friend in your FriendFinder friend list
- Contacts button - allows you to access your android phones contact list
- Zoom button - allows you to change the zoom level on the main map
- My menu button - allows you to access the menu items associated with how you appear to others in the FriendFinder application
- Settings button - allows user to access advanced features and settings
How to Use
- After selecting the search button a text field will appear. Typing in text will cause an autocomplete list to appear from which you can choose a matching query by using the up or down DPAD keys to select and a CENTER button press to confirm.
- Nothing special about how to use the contact list functionality
- Nothing special about how to use the zoom functionality
- My menu brings up the same menu as if you were using the main map screen and had pressed CENTER while yourself was highlighted. Usage is same as in previous section
- Settings currently only has one meaning full setting which you can change. This is in the form of a slider wheel. You can use the DPAD keys to navigate to the slider and set the desired value. Then highlighting the "Apply Settings" button and pressing the CENTER key will cause the FriendFinder application to redraw the map based on the updating settings for visible friends based on degrees of separation.
- We used a google auto-complete widget to generate a list for the user to select for the search functionality
- We decided to use a "dialogue" box instead of a separate screen to maintain more of a level of continuity between different screens in the application
- Back button press while in the contacts screen will bring you back to FriendFinder
- Friends stored in the phone's global contacts are added to the FriendFinder maintained friends list. (their location is also wizard of oz generated)
- we used the default provided zoom widget, but it seems optimized for a different screen size so its not our fault it doesn't look right =).
- We decided to implement "My Menu" as a double of the "center press when self is highlighted" because we felt the ability to change ones visibility was important and wanted the user to be able to find this functionality
- We had difficulty overriding the "center" press int he advanced menu. Even when over-ridden, a center press while the scroll wheel was highlighted would result in a dropdown menu instead of confirming the current selection. We got around this by forcing the user to highlight and select the apply settings button
Left out and Wizard of Oz
- Again we are not really sending / retrieving real data to a network beyond our meetup application so any status / visibility / text message sent are all wizard of oz'ed. This was left out as these backend services are not directly related to the UI. The important feedback and presenation of assumed backend data is already shown in our prototype.
- To know if a contact is more than two degrees and how our application would figure out how many degrees of separation is not implemented yet. This idea of filtering based off of degrees of separation was inspired by someone within the group having read an article regarding a "social-graph" program which could do similar functions. The ability to filter the display is what is important to our UI as it presents the data. How we grab and filter the data while worthy of some time and thought would fall out of the realm of a UI design.