GR6 - User Testing

Design:

Our final design is made up of a map and a sidebar, as shown in the overall screenshot below:

The map contains visual representations of the datasets imported, and allows users to click on various areas of the map to get more information, and manipulate and add towers. It has all of the movement functionality of Google Maps, as it uses Google's API.

The sidebar provides a basic visual interface for filtering data shown on the map. There, users can change the visibility of the two data set layers, and view certain subsets of population and rainfall data. In essence, this is a visual way of querying the data, which improves upon previously existing software that requires the user to input SQL queries.

The motivation for the sliders came from our initial user interviews conducted before beginning the design process. During paper prototyping, we formulated our design decisions for the layout of the sidebar.

Our final design incorporated many of the suggestions made in the heuristic evaluations. The most "catastrophic" problems that we fixed are described below:

| In the final design, we built custom overlays as tower objects, and used a WiFi tower icon in the center of the circle. Users could move the circle by dragging the icon in the center. We also provided cursor feedback when hovering over the resizer handle and the center icon.
|

Implementation:

The implementation was designed with a web interface in mind.  On that note, a combination of HTML, Javascript, and CSS was used to direct the proper visual representation of elements.  The main element, and also challenge, of the project was the map.  Both the visual appearance of the map itself and the databases that supplied information about population, rainfall, current towers, and newly added towers were generated using the Google Fusion Tables and Google Maps APIs.  Given the scope of this project, this choice saved us a lot of time, as trying to implement the same sort of functionality from scratch would have ended disastrously.  However, using the API proved to be very difficult at times.  A lot of the necessary functionality was not available in the public API and therefore had to be hacked together with various workarounds.  On the positive side, using Google Maps allows us the time to implement a very appealing visual style, and the familiarity of every user with the Google Maps interface definitely increased usability.  

There are certain features that we were unable to implement, either because their difficulty exceeded the scope of this class, or because they were impossible to implement within the Google Maps API.  One crucial feature that we had to eliminate was the Overlay vs Intersect button, which essentially provided a way of doing an OR vs. AND query. Because Google Fusion Tables does not support an inner join, which is a standard SQL operation, we had to eliminate the Intersect mode. Most other implementation problems did not affect the usability of the design, however, and so overall, the implementation was a success.

Evaluation:

Unfortunately, due to the nature of our project, we were unable to get in contact with three users from target audience of our project (since the user population is fairly small).  Instead, we used one target audience member as well as two students taken from the MIT population (although not from the 6.813 roster).  The most important effect that this may have is that our target user population would like have extensive training with the software and would also be much more intimately familiar with the problem at hand.  With that in mind, this is the information we presented each of our users with prior to the test:

User 1:

Task 1: On task 1, the user did successfully locate the areas of the maps the had both high population and high rainfall.  However, it seemed to take him many, many clicks and turning on and off of both layers to determine this fact.  What's more, he never clicked the arrow buttons to the right of the datasets that would have allowed him more control over what he was viewing.  After he had tried all of the tasks, the experimenter brought this up and asked him what he though that arrows would lead to.  He correctly thought that perhaps it would be some sort of context menu, and once he used it, he thought it was very helpful.

Task 2: Adding new wifi towers was not a problem.  The change in cursor after clicking the "Add Towers" button seemed to make him aware of what he needed to do pretty readily.  He dragged around the towers with no problem, although resizing them was not intuitive, and he didn't really know what to make of the sliders in the pop-up window. 

Task 3: The user was able to complete the task, although again, he had to repeatedly toggle the data layers (population and rainfall) on and off in order to decide where the ideal location was to place the towers.  This was made slightly easier when the ability to filter out the layers was demonstrated to him.

Feedback: 

• The colors were a bit confusing.  They seems to blend together somewhat and it was hard to tell what was what.
• The legend was originally not too visible.  It might be better if it were a part of the sidebar.
• The menu location and general feel of the whole project was good because it reminded him of the standard Google Maps interface (sidebar and all) and that was familiar and easy to use as a result

User 2:

Task 1: On task 1, this user also successfully located the areas of the maps the had both high population and high rainfall and it took many clicks and turning on and off of both layers to determine it.  Se never clicked the arrow buttons to the right of the datasets, but just looked at them as is.

Task 2: She added towers easily, and didn't really test out the popup windows much.   

Task 3: She toggled the datasets visible and invisible multiple times to figure out where she wanted to put them.

Feedback: 

• Figuring out which color related to which dataset confused her.  She kept clicking them off and on to solidify which she thought was which.
• She didn't even notice the arrows next to the datasets on the sidebar.
• Other than those things everything is intuitive.

User 3:

This user is an MIT Research Fellow working with Boingo and IBM on the problem of constructing a WiFi network in Africa. This is the person who suggested the idea for the project, and a real user from our target population. Because he already knew about the problem and our project, we did not give him a briefing or task list.
We presented him with the website and asked him to use it just as he would to solve the real-life problem he's working on. In general, he found the interface very clean and learnable, a significant improvement over previously existing solutions.

Usability problems:

• Add more information without cluttering the interface (major): He said that the project is off to a good start, and the next step is to add more layers of information in a way that tells a story to the user, without requiring the user to filter through long lists of data sets. For example, when existing towers are clustered in a small area, the user would want to know when they were placed there and why. Adding this extra functionality is probably outside the scope of what was possible during the semester, as we did not have access to that type of data.
• Add New Tower button should be logically separated from filtering (minor): Because the button is outside of the Google Map, it may not be obvious to some users to click on the map to place a button. This is only a minor problem because adding a tower is very learnable after the first try. One possible solution, especially when there are more map-interactive features, would be to move the button to a "drawing toolbar" on the map itself.
• Pop-up info windows should show data for all layers (major): He wanted to know all information for a given location that they clicked on, not just for the top layer. For lower layers, it was impossible to see the info window without removing the upper layer first. Solving this problem may be potentially difficult within the Google API, as it may require querying the Fusion Tables database for intersecting regions.  
• Map should include zoomed-out overlay map to show where the current view is on a map of the entire world or continent (major): For this user, it took a few seconds to realize where the map was zoomed into (South Africa). He said that it would be good to include a small map in the bottom right corner that the user can pan over to select different regions. This should be easy to solve - we think it's a built-in feature in the Google Maps API.

Reflection:

Through our iterative design process we learned that small details are important for the understanding and usability of our users.  Things like menu word choice, color of datasets, and icons on new towers added a lot to the usability.  In our first paper and computer prototypes there were a lot of questions about what exactly users are supposed to do with the different aspects of our design, however in the final that was clear to the testers.  One important design decision we made was to use Google's API for the map interface, which definitely had benefits as well as risks.  Though it made integrating with the rest of the interface and the backend more challenging, it was familiar to our users, which makes the interface more learnable.  Overall, all of the choices we made along the way still make sense as they made implementation not too time consuming so that we could focus on the important small details.