...
Our final design is made up of a map and a sidebar, as shown in the overall screenshot below:
The . The map contains visual representations of the dataset datasets imported, and allows users to click on various areas of the map to get more information, manipulate and manipulate and add towers. It It has all of the movement functionality of Google mapsMaps, as it uses Google's API. The sidebar provides supplemental information to what is one
The sidebar provides a basic visual interface for filtering data shown on the map. ThereThere, 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:
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 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.
...