...
Our final design incorporated many of the suggestions made in the heuristic evaluations. The most "catastrophic" problems that we fixed are described below:
- In our first prototype, we chose a red color for the population data layer, and green for new towers. One evaluator pointed out the resulting problem for red-green color blindness. We solved the problem by making the
Picture | Problem | Solution |
|---|---|---|
| In our first prototype, we chose a red color for the population data layer, and green for new towers. One evaluator pointed out the resulting problem for red-green color blindness. | We solved the problem by making the population layer a brown color. |
| In our first prototype, users were confused about what the controls on the left sidebar did, and at the time they were not functionally linked to the map so it was not obvious that they were data filters. | We added a helper explanation at the top of the left sidebar. |
| The color scheme we used was not very intuitive, and users didn't know how the different shades of colors corresponded to different values in the data. | We made the color coded boxes in the left sidebar larger, and created a legend overlaid on the map. |
| In our first prototype, info windows overlapped with each other, and sometimes, a new window would appear behind another one when it was opened. Windows were obscuring each other, and users found it a hassle to click the small X button to close each window. | We made a design decision to only allow one info window to be open at a time. This eliminates both problems mentioned, but at the cost of being able to display multiple info windows at once (i.e. to compare data at different locations). |
| We initially used Google's built-in Circle overlay with the "editable" property set, which allowed the user to move and resize the circle. However, users found the built-in resizer handles and moving handle (in the center) to be difficult to use. |
...
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 the Google Maps APIAPIs. Given the scope of this project, this was the correct choice 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 , sort of 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 API Google Maps interface definitely increased usability.
There are certain features that we were unable to implement due to the fact that their difficult , either because their difficulty exceeded the scope of this class. Most , 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.
...