FinalPrototype-Group:Group 14

From Cs160-sp08

Jump to: navigation, search


Team Members

  • Megan Marquardt – implemented map database, pin clustering, wrote up the Change from Previous Design section
  • Kai Man Jim – implemented color coding, added icons to menu, did testing, screenshots, wrote up the Unimplemented section
  • Ilya Landa - implemented color coding, implemented category filtering, wrote up the Final UI Design Section

Problem and Solution Overview

Where to go for lunch? What to do with an extra hour in an unknown city? Our program is for the curious people who want to know what’s going on around them, literally. PinMap is a way for people to look at their surroundings and find great cafes, good bookstores, and find out that that sushi place that looks pretty good hasn’t gotten very good reviews. The user can place a pin on their map and can either share it with no one, their friends, or with everyone that has the program. The pin has an associated comment with the location, so the user can tell everyone how he or she feels about that location. When the user opens the PinMap program, they see their current location and either just their pins, pins of their friends, or everyone’s pins. Selecting a pin shows the user the associated comment and who wrote it.

Target User Group

Our target user group is the curious people of the world, the type of people who are looking for things to do and places to go. The age group is approximately 12-40 years old. They should have knowledge of cell phones and have experience using general programs like the Maps application already on the default Android phone. Also, should be familiar with map interfaces from the internet, like MapQuest or Google Maps. This is essentially the same user group as many social networking applications like Facebook, MySpace, etc.


Easy Look at pins local to the user’s location and open a pin to look at its information

We wanted this task to be the easiest, because that is the basic function of the program, to be able to browse local pins.

Medium Add a pin at user’s current location, insert a comment, and set the sharing level and category

This is also a very essential part of our program, but a little more difficult because it requires additional screens to navigate to.

Hard Search for a specific pin and change the category of the pin

This is probably the most complex task that our program supports, and a very useful task at the same time. There is both a simple search and advanced search, so this task is hoping the user will use the advanced, but not requiring it.

Design Evolution

Changes from Previous Designs

From Initial Sketches

Our PinMap application underwent several changes from initial sketches. We severely underestimated the amount of coding that the robust functionality of our initial sketches required, so naturally we were not able to implement every idea we had for the program. This included being able to send pins to friends, call friends that were nearby, and displaying the location of a given friend. We also planned to synch the pins with a user’s calendar or friend’s calendar, but that was much to complex to implement along with the rest of the functionality of the program in the given amount of time. We decided to simplify our design and functionality, and maybe implement additional features if we found ourselves with extra time.

From Lo-Fi Testing

The low fidelity prototype helped us mainly with aspects of the program that confused the user, especially the wording of certain menu options. The wording of specific menu items such as “Insert,” “Display,” “Protected,” and “Privacy Settings,” were much too technical for general users, and we had to change these to be much more intuitive. In the low-fidelity version, a user would define how to share a pin by selected a “Privacy Setting” and defining it as “Public,” “Protected,” or “Personal.” The users were confused by the slightly technical jargon, so we changed it to “Share with” “Everyone,” “My Friends,” or “Just Me.” This was much more intuitive and colloquial for the users. Other wording changes were “Display Level” to “Filter Display,” “Browse” to “Browse Viewable,” and “Insert” to “Insert Pin.”

We had a method of zooming in and out that used the number keypad as a mapping onto the screen, such that there was a 3x3 grid overlaid on the map and each grid square was associated with a section of the map. When the user clicked a number key, it would zoom in on the grid square associated with that number. However, when we tested, the users had no idea what to do with overlaid number grid graphic, and didn’t understand it whatsoever. We decided to leave this functionality behind and go with the standard way of zooming in and out as implemented by the Maps program, already on the default Android Emulator, which was using the keys ‘I’ and ‘O’ to zoom in and out, respectively. The previous zooming design is shown below:


Another complaint from users was that the search menu was very confusing. We had a search interface that let the user specify whether to search the category or the title, and the user also specified the sharing level and the category. This really confused users, so we decided to make that search interface the advanced search, and create a much simpler search screen with just a text entry area for the search query and a complete search button, with the option of going to the “Advanced Search” screen. The screenshots below show both versions of the search, the simple and the advanced:


Pilot Usability Testing

The Pilot Usability Testing was the most valuable evaluation method we used. It let the system be evaluated with the limitations of the Android SDK, and let us know which problems were seen by several users. All of our major changes came from this study, as well as some smaller changes. Most of the major changes can be seen in the two screenshots of the before and after of the high fidelity prototype:


In implementing the high fidelity prototype, we had to make a few sacrifices when it came to implementation. Instead of using a map that can pan and zoom, we used a static image of a map, and pins were created in reference to the pixels on the screen, as opposed to a latitude and longitude pair. The users saw this as very limiting, so we implemented the fully functional map interface in the final design. We also implemented a database to contain each pins’ data, including title, comment, author, location as a latitude/longitude point, sharing level, and category.

Using the static picture of a map was also very limited when the user wanted to look through pins. There was a separate menu option called “Browse Viewable” that let the user the look through the pins that were present on the screen. This functionality seemed so basic that it should not be in a separate menu. So with the implementation of the panning and zooming map, we decided to remove that menu item and just highlight whichever pin is closest to the center of the screen. Also, we had a lot of complaints that you needed to select a pin to see its information instead of having it pop up automatically, so we were able to display the title and comment associated with a pin since it was now connected to the database. Now when a pin is highlighted, the title and clip of the comment are also shown.

When giving the high fidelity presentation to the class, we received several comments that this system may not scale well. If a user has a very large number of pins, there is no way to be able to navigate through them and see specific pins in a crowded area. We decided to implement pin clustering. When pins are within a small distance of each other, those pins get clumped into a meta-pin, which a user can click to expand to a level where the pins are separable. Below is a screenshot of what a pin cluster looks like and how it expands:


We also made a number of minor changes to the interface after the pilot usability study. In the high fidelity prototype, when inserting a new pin, the user had to delete some default text in the title and comment sections, so we changed those to ghost text that disappeared as soon as the user highlighted the text box. We also changed the design for selecting a category so that the user doesn’t need to scroll down a long list, all categories are available on the same screen. The user is also able to color code pins according to category, a suggestion made by a couple classmates. These small changes are viewable in the screenshots in the Final UI Design section.

In the high fidelity prototype, there was an implementation error in that when a user wanted to filter according to who made the pin, the system actually always showed the user-made pins, but filtered according to who the user shared a particular pin with. We fixed this by wizard of oz-ing the pins of friends (see wizard of oz section), and filtered the pins according to author.

Also, since we made several changes to the menu option text in each iteration of our design process, we added icons that would clarify the meaning to users.

Final Interface

UI Design


The great thing about our project is that even though it is very detailed and, potentially, powerful, it only has a handful simple functions that users can employ: Browse Map, Insert Pin, View and Edit Pin, and Search Pins. This functions do exactly what their names imply, and allow users an easy access to all functionality that out project possesses.

Let's start with Browse Map. This is the home screen of the application, the centerpiece of the project, the central way of displaying information to users, and the location, where they will spend most of their time while using this application. When in the Map view, users see a standard road map downloaded from the Internet, the same kind as they are used to seeing in Google Maps, Yahoo, or MapQuest. This map is scrollable through the use of the directional pad on the mobile phone, and it can be zoomed in and out, as any good web map should. On this map, users see the pins of different color. Each pin corresponds to a location entered either by the phone’s user or by other people using the same application. To get to a desired pin, users scroll the map, so the pin is the closest one to the center of the screen. As a confirmation of the successful selection, the pin is outlined by a thin orange line around it, and its short description appears near it. It is expected that this application may accumulate a large amount of pins, making the map highly cluttered. For that purpose, several methods exist to make the map more readably. Two filters were implemented: the first one toggles between pins created by the phone’s user, a user’s friends, or everyone on the network. Another filter allows users to pick which categories of pins they would like to have displayed on the map. More information of authors and categories is in the next paragraph. Finally, users can choose what colors they want pins of different categories to be drawn in. At present time, twenty colors are available, separated into 4 radically different groups, allowing for a deep customization of the map display.

Although is would be trivial to create a preset database containing the locations the developers consider useful, the current design assumes that the users will receive this application without any locations already stored in it. The customers would, then, populate this application with new locations themselves, and to, virtually, take over all roles associated with entering and organizing data over the network of people with this software. Naturally, the basic operation required for this is creating a new pin from user input. Trying to keep our system simple, we, currently, only have three pieces of information associated with a new location: its name, user’s comment about it, and the category it belongs to. Names and comments are freely provided by users, but the Category is limited to options set by designers. At this point, the application only has 7 distinct categories, but the new ones can be easily added when required. One more piece of information users have to provide while creating a new pin is a share level associated with it. Pins can be either made visible only to their creator, to the group of selected contacts, or to everyone who owns an identical mobile phone and software.

Once a pin is created, the basic operation for it is to examine all the information associated with it. In order to do so, the desired pins hast to be selected in the Map view as described above. One a pin is selected, its name and comment appears next to it on the map. If the selected pin really is a pine originally intended by the user, a quick press of the Center button opens this pin for viewing. By doing so, users enter the View Mode. At that step they are still unable to make any changes to the pin, but all the data associated with that pin is made available to them: pins name, comment, category, and the share level.

The next logical step from View Mode is Edit Mode. Our application provides users with a capability to change any information associated with a pin or delete the pin completely, all provided that a user has a sufficient security access to change that data. A user that created a certain pin has options to rename it, change its comment, category, and the share level. The reason for that is to correct spelling mistakes done while creating the pin, choosing a category that better describes it, or simply deciding to let everyone see a location previously only available to this user or his friends. Finally, a pin’s author can delete an obsolete or a mistakenly placed pin. We have not yet implemented transferring pin data between phones, but the following is the description of how other users would interact with someone’s pins. For users who can see a pin but did not create it, the editing options are fairly limited. They are only able to extend a comment for this pin. The reason behind that is to let users comment on places they have visited without having an ability to radically modify or delete someone else’s pins.

The final key function available to users is searching through pins. By its complexity it surpasses everything described above, but, like most modern search engines, our Search mode is simple to use, and it yields easy to read results. In the Search mode, users indicate whether they want to search pins by name or by comment, they enter the keywords in the name and comment fields. Users choose among which categories they want to search for the pins and specify whether they want to search only through their pins, pins created by their friends, or pins created by everyone on the network. Once all these parameters are specified, out search algorithm is launched. It finds the pins with proper categories, authors, and containing given keywords in their names and comments. The way that keyword matching works, if a user indicates that he wishes to search only for name or comment, he is shown pins that contain the search keywords in the correct fields; and if a user asks to search for names and comments, he is shown a union of pins matching either of the two parameters. This union search is also invoked when users use Simple Search, in which they only specify one set of keywords. Also, Simple Search automatically searches through pins of all categories and by all authors. The search results are provided in a List view, giving users an ability to scroll through then and select a desired pin. One a pin is selected, the map appears, centered on a selected pin. If this pin is not what a user was searching for, it is possible to return to the list of search results and select another pin.

User Interface

Map View

This view shows users a default Google Map, with pins overlaid on it. This is a center view of our application, but interface-wise it is also one of the simplest. The map is scrollable by using DPad on the emulator’s keyboard. Pins appear attached to the map, as they move along with it, maintaining their position over fixed geographic locations on the map. As described above, the pin closest to the center is outlined, and a transparent box containing its name and comment appears nest to it. This design is intended to provide users with standard map controls and an easy way to select and examine a desired pin. The map can be zoomed in and out using "I" and "O" keys.

Map View Options

Our Map View is the only screen in our project with a menu. This menu contains most of the key controls for this application. All the options in the Options menu come with icons helping to understand the purpose of these options.

  • Filter Display (name subject to revision) opens a new menu with three options: "Everyone's pins" – display pins created by everyone on the network, "My friends' pins" – display own pins and pins created by user’s friends, and "My pins" – only display pins created by this phone's user.
  • Filter Category opens Check Category View (detailed later) that allows users to select which categories of pins they desire to see. Note that "Filter Display" and "Filter Categories" work in unison, allowing for a high degree of customization for the Map View in terms of the displayed pins.
  • Search Pins this button does what its name implies and takes user to Simple Search View
  • Place Pin once this option is selected, a crosshair target appears in the center of the map. The map is still scrollable, but now, when a user presses Center button, instead of opening the centermost pin, user is taken to Insert Pin View, where he inputs the specifications for the pin. Upon finishing the insertion process, the new pin is placed in the center of the map, where the target used to be.
  • Settings this option gives three options to the user: "Colors" which leads to Color View where users choose colors for pins of different categories, "Sharing" – Sharing View that allows customization of what pins other users on the network can view, and "Delete All Pins" – Delete All View that gives users an option to delete all pins that they have created. The names of these options are simple to understand in conjunction with the fact that they are located in "Settings" menu.

Check Categories View

This view contains a set of 8 checkboxes, 7 of which correspond to 7 categories ion the application, and 1 to select all categories at once. This view can be called without providing any arguments, resulting in only "All Categories" being selected, or it can be called with the information of what categories are presently selected, resulting in corresponding checkboxes being already checked on activity start. Button "Set" at the bottom saves all the changes done to this view and returns them to an above activity.

Simple Search

This view provides users with a single text box and two buttons. The text box contains ghost text "Enter Search Criteria Here". If user enters a keyword in that field and presses the "Search" button, the application will run a simple search as described above and take a user to "Search Results" view. On the other hand, if a user simply presses "Advanced Search", he is taken to "Advance Search" view.

Advanced Search

Unlike “Simple Search”, where search options are locked, this view contains a variety of controls that allow users to set their search parameters:

  • Search text box where user input their search keywords
  • Name and Comment check boxes to indicate whether search will look through names, comments, or both
  • Share radio group to indicate whether a user wishes to search only through his pins, pins on his friends, or everyone’s pins
  • Set Categories button that takes a user to “Check Categories” view to select what categories of pins will be searched
  • Search button to launch search algorithm

The limited space on the emulator's screen prevented us from putting more controls or descriptions into this view, so our current controls and layout are designed to make defining a custom search an understandable and logical process.

Search Results

The search results are split into pages with 4 entries each. The single page contains up to four horizontal buttons each with a pin’s name on it. Clicking on any of these buttons leads to a map that will be centered on that pin. At the bottom of the "Search Results" is a standard "Page a/b" indicator. On each side of it are buttons "Prev" and "Next" that appear and disappear accordingly to whether the current page has a page before or after it. Clicking on one of this buttons will open another page of results. As of now pins are not sorted, but this can be easily implemented.

Place Pin

This is a very straight forward screen. It contains text boxes for name and comment, "Share" radio group, "Set Category" button that leads to "Select Category" view, and Insert button that finalizes the insertion process. Once again, all controls are logically labeled and positioned to allow to a simple and logical process of defining a new pin

Select Category

Originally this screen was just one big radio group with 7 entries. Despite its simplicity, this was the only thing in our applications that had ever looked positively ugly. Unable to make a radio group with 2 columns, the items extended well beyond the screen creating a need to scroll. To complete the ensemble, a large "Save" button was needed to leave the activity after the correct radio button had already been selected. This layout did provide the full required functionality, but it had to be improved visually for the final version. And that is precisely what we did in one of the later revisions.

The current layout is the following: radio buttons have been replaced with picture buttons. Unselected buttons are white, while the selected button is red. This activity is started with a selected category passed in as an argument. Upon load, the correct button is marked as selected. Then, once a user clicks the desired button, the previously selected button becomes white, the clicked button is colored, and, within a second, this view closes. If it launched again, the previously selected option is now colored on the activity load. No additional elements are required for this view.


This is one of the options in the “Settings” menu. This view contains 7 image buttons, each with a label next to it with the category. The buttons are filled with colors currently corresponding to their categories. Clicking on any of these buttons leads to the “Color Grid” view where users can choose colors for the categories. “Save” button is located at the bottom of this view; it saves all changes done to category colors and exits the activity. Since moving a cursor over a brightly colored button is very hard to see, another method of indicating which button is currently selected was implemented – category name in the label next to the selected button turns from white to yellow, resolving this issue.

Color Grid

The whole view is just one big Grid View with 20 colored squares in it. By scrolling through it, users can select a desired color for a category.


This view contains checkboxes that define which categories of pins can be seen by user’s friends, or everyone of the network. Also, the “Edit My Friend List” button at the top of this view leads to a simple list of checkboxes corresponding to people in the phone’s address book. Selecting these boxes makes these people as user’s friends.

Delete All

This is just a simple confirmation window asking users is they really want to delete all the pins they created.



Even though the SQL database was only implemented in revisions after the Interactive Prototype, it is now the key feature and the base of the entire application. Before the introduction of the database, the pin data was stored in data structures throughout the code. Even though it did provide full functionality for a single run, all the data would be lost once the application was restarted. Clearly, this was unacceptable for the final version. We had some idea about creating a log file where we would copy all the data from out data structures upon exiting the program, so that we could later restore these data structures from the log file on the next launch. However, while this implementation would only complicate the application, introduction of the SQL database actually simplified it. We could directly access this database while running the application and it persisted even when we would restart our computers. The database only holds pin information. It has columns for all pin data including their geographic locations. As soon as a new pin is created it is added to the database; editing or deleting a pin also affects the database immediately. Plus, due to a special structure of our code, we received an unexpected bonus from using a database. Every time a map is undated, the algorithm erases all pins and redraws then anew from the database. So, any change to the database immediately affects the map view.

A funny episode happened to me (Ilya) because of this feature. I was working on implementing colors for different categories. I modified a code for (as I though) creating a new pin to draw a pin using a correct color from the database. After making sure that the insertion operation was working properly I called it a day, and left implementing modifying an existing pin color for the next time. When, the next day I decided to work on it, I, first, wanted to see the current state of the code. To my amazement, the color change was working perfectly. I wrote Kai: "Did you do it?" – No; Megan – No. Eventually, I realized that I modified the general update code that was invoked during all operations involving updating pin data.


This is another key feature that was missing in the Interactive Prototype. Originally we had a static picture in the background. The real map was implemented later; in the same revision as the database. To add a working map, we used a default Google Map view that came with Android. A layer of pins is added to the map. When map moves, the pin layer moves with it, so it seems that the pins are actually attached to fix map locations.

Communicating Between Activities

Originally, passing data correctly between various activities in our application was the source of most our problems. It took us some time to discover and memorize the syntax for all Android conventions in communicating between activities, and even longer to be able to use these conventions in the application.


The entire project is structured in the following way: MainActivity is the center of our project. Nearly all out sub-activities are launched directly from it (even those that look like they are launched from other sub-activities). The reason for this nonlinear structure is that MainActivity also holds all the data for the application. Our pin database is stored there along with a multitude of flags and values needed to organize all the events that are taking place.

MainActivity is also the location of most of the code for processing data. Most of our sub-activities function only as data collectors. So New Pin view doesn't actually create a new pin. It only takes user inputs and sends them back to MainActivity. Even the intimidating Advanced Search shares the same role – collect data and pass it back. All the information in our system is just too intertwined to be processed individually. The single most influential function in out code is OnActivityResult in MainActivity. As can be assumed from the description above, this function receives bundles of data from all over the application, and needs to process it. Smaller calculations are done inside that function, larger are sent to separate functions.

Our ambitions had forced us into this structure, but sometimes it gets ridiculous. When a user fills "Search" or "Advance Search" forms, the data he entered is sent back to MainActivity. In there, a search algorithm applies this data to the database and calculates a set of pins that match the search parameters. Then, without ever even loading the map, these pins are passed as arguments to the Search Result view. When that sub-activity receives the pins, it parses them, splits into pages and displays to users. When a user selects a pin, the sub-activity simply returns an index of the selected pin. When MainActivity returns an index, it matches it to the pin in the list of pins from the search algorithm, and centers the map at that pin. But from the user's perspective, the entire search process seems linear: MainActivity -> Search View -> Searching -> Search Results -> Map.

The plus side of this structure is that all our sub-activities are relatively simple to implement. Designing them, we can concentrate on the interface layout, on responsiveness of the buttons, on the correctness of the information it returns; and the often arduous job of processing this data can be left for late. Even better, since all the data is processed in one place, radically modifying the application does not need to be as painful as usual. When we switched from data structures to the SQL database, most of the MainActivity was cooingly rewritten to an untold horror of some group members. But since our sub-activity had nothing to do with accessing data structures or a database, and simply served as a way for users to input data, they were not affected, and remained primarily unchanged through the various code revisions.


This is our main menu, we get rid of the "Browse" button, and let the phone automatically browse for changes instead. We also add another application called "Filter category", which can display pins with specific category only. This way users can easily and quickly look for locations like restaurant or lecture hall on the map if there were originally lots of pins on the map. Moreover, we added icons on the menu and also the sub-menu. We think icons are really needed because it can make the UI more user friendly and can help users understand the options by metaphor.


Within the filter display, we have three options: Everyone's pins, My Friends' pins, and My pins. These are the three ways of filtering pins based on the security level. Everyone's pins displays pins that are from other users who are using the same product. These people could be someone that you don't know. My Friends' pins displays pins from friends that you know. Friends are the one that from the address book. And My pins displays your own pins. At the same time, your own pins will not be shared to the public to whoever have the same product when they are filtering under Everyone's pins.


This is the new option that we added to our menu. Instead of filtering by security level, users can filter by specifying the category they want. And it is located under the Display option in main menu.


This is our search option. Instead of browsing pins on the map, users can type in the name of the specific location and either choose a simple search or advance search. During the demonstration, we presented our advance search by inputting name of location, security level, and category since simple search wasn't finish implementing. Simple search is now done. Whenever users input a name for location, the phone will return whatever that matches the name with all kinds of category.


This is our place pin option. As we had presented during the demonstration, users can navigate the map for target location and then hit enter. Once they hit enter, a new screen will pop up and users are required to fill in the information of that target pin.


This is the setting option of the application. Notice that we added two extra options which are Load Friends' pins and Delete All Pins.


The Load Friends' pins loads in all the pins from the users' friends, and Delete All Pins will clear the datebase for all pins.


This is the color option. We implement this option to let users to choose whatever color they like to specify they pin color for different category. Notice that the color of the text for category turns to yellow to show that the cursor is currently at that position. When the users press enter, a new screen with a color gird will display. After the users specify the color they want, the pins will automatically change their color. As you can see the difference between the same map here and above.



Left out and Why

In the share button under setting, there is a button called "Edit My Friend List". We left out to implement this list because we think the friend list is not very important to our main goal. Although we do have an option of loading and browsing pins from friends, but the main purpose is how to retrieve the data and output it on the screen. Therefore adding or deleting friends on the list is not in our task and that is why we do not implement it.


Wizard of Oz

We tried to limit the amount of wizard of oz-ing, but we had to wizard of oz the friend list and the sharing of pins across a network. Instead of sending pins across the internet or between phones using google’s messaging service, we just placed pins into the database where the author was not the user, but “Sally” or “John”, etc. The pins are placed onto the map using the “Load Friends’ Pin” option under the Settings Menu. Ideally, we would have liked to implement this, but it would have taken quite a while to implement, and we wanted to spend our time working on features that our classmates suggested needed improvements.

[add comment]
Personal tools