You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

< Back to Project Home

GR2 - Designs

Scenario

Frodo Baggins, a recent college graduate, is working under a government contract to find optimal locations for new WiFi towers in Africa. He is new to using ANB, and is learning mostly by intuition because his boss is too busy to give him detailed training.

Frodo's first task is to pull data sets from a remote shared database. His data sets are:

  • satellite coverage
  • current WiFi towers
  • rainfall
  • demographics

Once he has this data, he wants to overlay the data sets on a map of Africa to help him evaluate how good the current WiFi coverage is. He wants to quickly find regions that have insufficient coverage. For each of these regions, he needs to find the location(s) for new WiFi towers to optimize coverage. Periodically, he'll want to share his findings with his co-worker, Samwise, and get his input. When he thinks he's finished, he needs to share a report with his boss, Gandalf.

Designs

Design #1

This design aims to offer maximum flexibility and efficiency by having many toolbars visible on the screen. It offers the user a lot of options, sacrificing some cleanliness and simplicity.

Storyboard

Frodo first logs in to his account, where he can view his existing projects and create new projects.

Frodo creates a new project to analyze Africa's WiFi coverage. The screen initially shows thumbnails of visualizations, from which Frodo selects a geographical map. In the left toolbar, there is an empty list of "Current Data Sets". Frodo clicks on the "+" button to import data into the map. This brings up a box where he can search and browse data sets and drag them into his Current Data Sets list.

After importing the data he needs, he can see the data sets visually laid out on the map. The map's zooming and panning functions are externally consistent with other maps, i.e. Google Maps.

The Current Data Sets list allows him to toggle each set on/off in the map, and provides a legend of how the data is visualized. The timeline on the bottom shows a line graph of data that varies over time. The timeline has its own legend where data sets can be toggled on/off. Frodo can zoom in and out of the timeline (e.g. view by years, months, or days) with the slider at the top of the timeline. To display a time average of the data on the map, he can use his mouse to highlight a selection of the timeline.

The toolbar on the right side provides specific data geared toward optimization and more detailed analysis. Frodo can create scoring metrics to assess how good coverage is in the currently visible region. He can display an overall "score" (i.e. percentage of the population with access to Boingo WiFi), and highlight areas on the map where coverage is insufficient. Below the "scoring toolbar," Frodo can see specific data about the area his mouse is currently hovering over. He can also adjust the size of the "hovered area" (i.e. the circle around his mouse).

Frodo will want to add hypothetical new Boingo WiFi towers to the map to improve his score. On the lower left toolbar, he can add new towers to the Boingo WiFi towers data set. He can click and drag a new tower onto the map, and data related to the new tower will display right next to the mouse. The data on the right-hand side of the screen will also update automatically as Frodo moves his mouse around the map.

To see data for towers on the map, Frodo can hover over them, and a box will automatically pop up next to the tower. To edit this data, Frodo must click on the tower, then the box of data will remain visible when the mouse is moved. He can adjust parameters with sliders, and see tradeoffs between different factors such as cost, power, coverage area, etc. There are also buttons to add a note and to delete the tower. To move the tower, Frodo can click and hold down the mouse for ~1 second, then drag the tower to a new location.

If Frodo gets stuck, he can ask his friend Samwise for help. First, he might want to write some comments on the map itself. He can click on a commenting toolbar on the left side, which will have tools for adding textboxes, circling areas, etc. Although not pictured here, the toolbar will have external consistency with programs such as PowerPoint and Photoshop.

To share his project with Sam, Frodo clicks on the "Share" icon at the top of the screen. A window drops down from the Share icon, where Frodo can enter Sam's username/email, set editing privileges for him, and add a message. Sharing allows for real-time collaborative editing, as it does in Google Docs.

After Sam tells Frodo that his analysis looks perfect and wonderful, Frodo is ready to "publish" a final report to his boss, Gandalf. Functionally, publishing sends only the a copy of the current project, and does not send real-time updates like sharing does. Ideally, Frodo would be able to select which parts of the project to include in the report, and provide extra commentary/analysis for his boss. However, since we are focusing on the UI for visualization, Publish will look essentially like Share, at least for now.

Analysis

Learnability: This design relies primarily on visibility, feedback, and external consistency for learnability. Because of the numerous toolbars, the user can easily see many features without having to click on submenus or buttons. The user will have to explore the toolbars for a while to become familiar with them. Real-time feedback also makes the interface more learnable. For example, the user can see the data in the right-hand toolbar changing as the mouse is moved over the map area. Clicking a checkbox in the left toolbar will instantly make the corresponding data set appear or disappear in the map. Many of the toolbars and icons bear resemblance to other programs like Google Docs, Google Maps, Photoshop, and PowerPoint. Some features that are not visible may present learnability problems, such as clicking on towers to edit its properties. In this example, a small tip could be displayed in the properties box when the mouse is hovered over the tower.

Efficiency: The toolbars also provide efficiency in this design by keeping many options easily accessible on the screen. The user can perform almost all actions within three clicks. Once the user has had some time to become familiar with the interface, (s)he should be able to very efficiently navigate through the toolbars to the desired tool. The design also tries to keep likely actions located close to the mouse. For example, when the mouse is hovered over a tower, it is likely that the user wants to see and/or edit that tower's properties. So, the properties are displayed right next to the tower, where the user is currently looking. When the user clicks to edit a tower, all the possible editing actions are right in the vicinity of the mouse's current location, minimizing time taken to point the mouse.

Safety: The consequences of user mistakes are usually reversible and have little, if any, adverse effect. The UI will incorporate standard keyboard shortcuts for undo and redo. The worst mistakes are probably accidental deletes and shares. The interface design accounts for this by making deleting and sharing hard to do by mistake. The "delete" button for a tower is at the bottom of the box for editing tower properties, and will be colored red. We may also choose to pop up a confirmation box, since deleting towers will probably not be a very frequent task. 

Design #2

The idea behind this design is to keep it very clean and simple. Manipulation is largely mouse-based and allows for a lot of real-time visual updates in response to the user's actions. The emphasis is on learnability. It should be intuitive for the user to move around the map, to choose and add layers, to select objects on the map to bring them into focus, to manipulate the time, etc. These actions should all map to actions that users are generally familiar with through other software and real-life activities. In addition, the focus on clean and simple design means that there are fewer aspects of the design for the user to learn. Efficiency may be sacrificed as a result, however, because in an effort to be minimal, certain things may be more than one click away, but the use of sliders for some functionality may help in that respect. As for safety, the user is fairly limited in their actions. They may accidentally add layers they don't want or change modes, but these errors are fairly simply undone.

Storyboard

When Frodo logs in and uploads his file sets, this is the first screen he would see. At the top, there is a title bar indicating that he is in analysis mode. There is a flat very lightly colored gray scale map of the area in question (pictured here is the northern two-thirds of Africa). Similarly to Google Maps, Frodo can drag around the map with the mouse, as well as zoom in and out using the controls on the left. In the top left there is a button that toggles between month and year (other option can maybe be added) and corresponds to the slider on the bottom. For instance, if he is in month-mode, the slider will move through monthly averages of the data from January to December while in yearly mode, it would move from 2000-2012 or something of that nature. On the top right of the screen, there is a button titled "Layers" which when Frodo clicks on it, will generate a drop-down list that contains all the data sets Frodo had selected on logging in. The large arrow on the right of the screen allows Frodo to shift into the next mode (which for lack of a better name is referred to as the edit mode in this design), after he has finished his analysis of the data sets.

Frodo can then click on the "layers" menu and select the option, "demographics" (here written as population) for instance. The first consequence of this action is that a box with the name "demographics" and a small "x" will appear to the left of the "layers" menu. In addition, the data set will be added to the map. Color and specific shading can of course be determined later, but let's assume for this design that demographics is represented by the color red. In that case, a light red area representing the entire year's population area will appear on the map, and a bright, solid red will indicate the area covered in that specific month. There would be a similar outcome in yearly mode as well.

Frodo clicks on the "layers" menu again. We can see the menu pop open here. He selects a new layer, "rainfall" for instance, and it gets added to the map, in a different color from demographics, but overlaying the previous data set.

When Frodo is done setting the data, he can hit the arrow on the right side of the screen to move forward. The first thing to occur after this action is that the title bar will change to "edit" mode (here written as "edit hotspots"), and a pop up window will appear as the background fades out in some way indicating inactivity. The window will indicate some backend sort of magic occurring (not the focus of this class, so we will just assume it exists) that will generate a number of new hot spots, strategically placed on the map.

After the computer finishes generating the new towers, this last frame pops up.  This is the "edit" mode screen that Frodo can actually interact with. Note that now the arrow is on the left side of the screen, indicating the way which he can return to the analysis screen (by clicking or perhaps with a keyboard shortcut). The layers menu button along with the current layers are still visible, although not editable. What is new, however, are the circular forms on the map. Each of these circles represents a new wifi tower as generated by the magic backend algorithm. There are also sliders (three sliders pictured, although more or less might be appropriate as needed for the parameters the users desire) in which Frodo can adjust things like total cost, quantity of towers, average strength of towers, power used, etc. These sliders would have an immediate effect on the representations of the wifi towers on the map, in that using the sliders would change the size of the circles appropriately. In addition, it would be possible to manipulate each individual tower by clicking on it. Clicking on a circle would display the information pertaining to that particular tower (i.e. location, strength, wattage, and whatever else is relevant). It would also be possible to drag it to change the range or move the circle itself.  Frodo can use these manipulations in order to place the towers ideally based on whatever criteria is most important.  Although not pictured, there would be a share button to the left of the save button which would allow Frodo to send a message to Samwise with the current design.  Samwise could then respond through email or chat or something like that.  The save button would both allow Frodo the option of saving the layout to his computer and also of submitting an official report to Gandalf.  Thus, when Frodo is done, it is very easy and intuitive to save and submit.

Design #3

This interface views important information in an efficient way, as well as an easily manuverable layout.

Frodo is a frequent user of this system. He opens up the program automatically to a login screen. He has the option to create a visualization as a guest, or sign in with his username and password. He can then choose the source from which his data is coming from and the type of visualization that will be used. This is very learnable because users are used to login screens, and this one is very similar to many that exist. It is efficient because you only have to go through one screen in order to login. Also in Frodo’s situation the username, password, and most frequent datasets could be autofilled since he is a frequent user.

Once Frodo hits “Go”, he will be brought to the main page interface. This interface allows users to pan through a stack of multiple data maps vertically (similar to cover flow in Mac OS). This main frame contains a general map that can be zoomed and moved, as well as some more specific data information. His data maps include satellite coverage, current Wifi towers, rainfall, and demographics. He wants to quickly find regions that have insufficient coverage and map that against the wifi towers that exist, so he will pan to the “satellite coverage” map, click “overlay”. Now when he pans, that map will stay static and the rest will pan. He will then pan to “current Wifi tower” and hit overlay. Now, both of these maps are overlayed on the main page, as well as more detailed information about both in the bottom right corner.

In order to actually optimize coverage, given the current Wifi towers and adding one or more new towers, Frodo will go to the top panel and check “tower location” and “tower number”, since these are the things he is looking to change. Then he will hit “optimize”, which will give him the option of what he would like to optimize. This is not too learnable, but once someone shows you how to do it, though if the user is experimenting with the software he will probably come across it. It is very efficient in terms of optimization based on certain things. The alternative method, which is widely used now is querying. This is a lot more efficient than that. For safety, there is always the option to cancel, or once you hit go, you exit the optimization with the button in the bottom left. Once the data is optimized, and the new towers are added, Frodo can hover over one of the new data point(s) and see and edit information about it.

Through his project he periodically hits “share” at the bottom right side of the entire screen in order to show his coworker, Samwise, his progress.

  • No labels