...
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.
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. |
| 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 Fusion Tables and the Google Maps API. Given the scope of this project, this was the correct choice 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 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 definitely increased usability.
...