Identifying Design Principles

From CS294-10 Visualization Sp11

Revision as of 02:09, 19 March 2011 by Michael Cohen (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Lecture on Mar 16, 2011




  • Pictorial and verbal tools for conveying routes, Lee & Tversky (pdf)
  • Rendering effective routemaps, Agrawala & Stolte (pdf)
  • Identification and validation of cognitive design principles for automated generation of assembly instructions, Heiser et al. (html)

Optional Readings

  • Designing effective step-by-step assembly instructions, Agrawala et al. (html)


Brandon Liu - Mar 16, 2011 05:43:09 pm

An observation I had on the assembly instructions project was that the computer-generated instructions had a consistent, isometric perspective. I would be interested in seeing the hand-drawn instructions, and how the use of a consistent perspective relates to spatial ability. My intuition tells me that people with high spatial ability would minimize the number of times the drawing changed its perspective; only in the cases where a piece goes in an occluded spot does the perspective changes. In most cases, it seems that 2-3 perspectives would be enough to cover all cases. Another interesting facet of this area is how to use zooming in instructions. In some cases, we may need to 'zoom in' on a component to describe more detail. A great dataset for this would be those LEGO instruction booklets.

Michael Porath - Mar 16, 2011 07:37:10 pm

The Mapblast project reminded me of a conversation about mental maps I had lately. Most of the maps I come across are drawn to scale. Mental maps, just as Mapblast, recognize the fact that this is not how we perceive the world. While spatial information is important for many purposes, it doesn't reflect our representation of space.

For my final project I'm looking at visualizing people's driving and mobility patterns. One thing this discussion sparked was whether I could show mobility patterns in some way other than based on spatial distances. A more obvious way to do that would be to distort the distances based on the time it takes to get from one point to the other. The data I'm working with samples a person's location, speed, and velocity based on GPS information. Showing two data points equidistant from each other would do that distortion in a very obvious way. San Francisco and Palo Alto, around 40 minutes away from each other, would be as far away from each other as the two sides of the Bay Bridge during rush hour are when driving during rush hour. Another representation along the same lines could distort the spatial distances based on CO2 emissions or gas consumption. Does anyone know of seminal papers about map distortions?

Julian Limon - Mar 16, 2011 08:27:56 pm

I was particularly intrigued about the framework that was proposed in class today to work with design principles. I believe there is a lot of value in applying the concepts of identification, instantiation and validation of design principles before settling on a final design or algorithm. I think this is particularly true on the web: where multiple experiments can be run at the same time and a lot of variables can be controlled. Of course, not all visualizations are meant to be seen in a computer screen, but in the cases in which it is possible it would be really valuable. For example, one could imagine a GPS manufacturer trying out different visualizations and measuring results.

On a totally different note, I just found a recent blog post that features LineDrive and discusses the motivations of an atlas (general purpose, similar to the wedding map problem) versus the motivations of a set of directions (getting from point A to point B). It's interesting how Google Maps shows the same interface for two different use cases and doesn't default to the most suitable one depending on the situation.

Siamak Faridani 23:50, 16 March 2011 (CDT)

The first two readings were very interesting. Tversky's paper made me think though. In Agrawala's paper the whole assumption is that one would like to take a look at the route or print it. In other words the diagram is static and won't change.

I am now wondering what if we want to build a GPS systems that shows effective routs. We can obviously use Tversky's principles but I am wondering if such a device would be as effective as current GPS systems. These maps lose the linear mapping to the real world and that might make them harder to understand. Is it still crucial to render the effective route if we have a GPS display that can show the routes dynamically? Is there any way to abstract out unimportant and natural turns of the routes and still maintain a mapping from the visualization to the reality that does not impose a cognitive complexity?

Candidate solution

In the dynamic display setting perhaps we can maintain full linear mapping from the local display to the current surrounding and relax the mapping from display to what comes later in 10 minutes. As car moves through the route the display can be updated and become more relevant to the reality. What bothers me with current GPS systems is that I have a good understanding of the local route since I can see it on the display but I have no idea about the whole route since my GPS does not show that to me at the same time, unless I change the zoom and zoom out, I am wondering if we can combine different zoom levels and for nearby places use a realistic map and for the places near the destination use a zoomed out map with effective routes (I just own a very low end GPS so may be this problem is solved in other systems)

Krishna - Mar 17, 2011 01:50:47 am

The more I think about Route Maps, the more convinced I am that the system is a complex, wonderfully hand crafted smoothing algorithm. This makes me wonder if the same hierarchy of optimization steps - shape, road(curve), label, context can be applied for visualizing generic time series . In other words, would it make sense to use a similar algorithm , with almost similar constraints, to summarize a filtered output of a time series where each turning point would correspond to an event - either specified or inferred from the user's query ? Unlike in maps, there wont be intersection(s) and any adjustment to the length should correspond to some distortion to the scale of the axes. I am just thinking if such a strategy would highlight the general trend of the time series in relation to the events.

Michael Hsueh - Mar 17, 2011 04:07:30 am

Lee & Tversky's comparison of depictions versus descriptions of routes uncovered a common conceptual structure that should more or less allow translation between the domains. Regarding the conceptual structure, one could think about the minimal set of "conceptual elements" a toolkit must embody to be sufficient to specify any arbitrary route. Once established, the task of constructing more pragmatically sized toolkits becomes a seemingly more tidy task, at least theoretically. Optimal sets of non-essential elements can be added, all the while balancing redundancy, complexity, and just adequacy in general, with size. The paper mentions several examples including stop signs and u-turns.

Another thought: A picture in the Lee & Tversky paper really helped me put a finger on one of the ways route depictions help facilitate cognitive ability. I got the insight (and a chuckle, for that matter) viewing the student created map that had "Serra St. = TOO FAR." Come to think of it, this was actually an extremely helpful, though not strictly necessary, addition to the map. Depiction readily lends itself to specifying features not directly relevant to the target route: contextual clues, if you will. An advantage inherent to depictions, as described in the paper, is the enforced specificity of depicted elements. Contextual clues are of course non-essential, but I think depictions can much more effectively incorporate them. Sprinkling in conceptual clues can greatly enhance the effectiveness of route maps, as seen in the demos in class today. They can be readily added as additional non-essential elements to LineDrive-type generalization techniques given appropriate data, parameters, and so on.

Saung Li - Mar 17, 2011 05:38:02 pm

I found the discussion on LineDrive regarded routing maps to be quite interesting, as it tackles the visualization problem of generalization. Removing a lot of the real information around the routes help reduce clutter so that users can focus on the actual route. This is like removing the grid lines from a graph to make it look cleaner and avoid distraction. This is especially important when the maximum size of the map is small, such as on a mobile phone. Exaggerating certain routes to improve visibility provides great advantages against accurately depicted maps in which the roads are too short to see all the street names. There may be the problem of removing too much information. Sometimes, landmarks might help people find locations significantly better than street names. The problem here then is to figure out what landmarks to include in these maps, and being careful of not adding in too much as cluttering is what we wanted to reduce in the first place. This reminds me of the CS160 project I did back in sp08, where my group took a GWAP-style approach where players labeled important landmarks and such.

Matthew Can - Mar 17, 2011 06:15:15 pm

For me, the biggest take away from the lecture and the readings was the staged process of identifying, understanding, instantiating, and evaluating design principles for visualization. I think it makes the design process scientific and principled. Equally important, the process generalizes to design in many domains, of which route maps and assembly instructions are just two examples.

Since I'm a computer scientist and I care most about the implementation of these systems, what caught my attention was the optimization-based approach to automatic design. In all the examples we saw, the design problem was framed as a search problem in a high dimensional design space. The design principles were translated into an energy function that was minimized under some additional, explicit constraints. This is a powerful abstraction that is suitable for arbitrary automated design problems.

Karl He - Mar 17, 2011 11:58:20 pm

The LineDrive system was interesting in how it distorts the world. By abstracting streets to a point that they no longer resemble the real world, the distortion can only be interpreted in an abstract way. LineDrive and the assembly instructions both share the idea of following how people think about doing things. This is generally something I've found difficult about making visualizations, knowing whether the viewer interprets it as I designed it, thinking about the problem the way the assembly instruction system was designed would likely be very beneficial.

Sally Ahn - Mar 18, 2011 01:05:39 am

One thing about LineDrive that stands out to me is that it identifies and address a very widespread and common problem. People of all ages and occupation use computer-generated maps, and yet users simply accepted the limitations of the prevalent non-distorted route maps. Even today, most popular online mapping services present the same unhelpfully accurate route maps. I think this encourages one to think about identifying other common but accustomed problems. For example, we saw many automated layout algorithms in the past few lectures, and yet the internet is full of poorly laid out pages. Often times, online tutorials or references will be cluttered with advertisements that can be very distracting. This is an inconvenience that most internet users have come to accept, but perhaps a solution exists in an automated layout algorithm designed for such poorly laid out websites.

Manas Mittal - Mar 18, 2011 06:36:47 am

I liked the Hieser et al paper because it is right at the intersection of Physch and computer science. I was surprised to find that the computer generated instructions were faster and better than anything else. I was wondering though if there was any difference in terms of hand drawing for people who were Spatially challenged (i.e., slow) vs the Spatially competent. This is a really great paper because it is cognitively grounded, and incorporates several major 'surprises'.

The Line Drive paper was great: For one, I could see the parallels in both the LineDrive work and the automated assembly instructions (i.e., optimizing a constraint space). Another thing that stood out was that searching the space was necessary over a deterministic solution (which was not possible). I wonder if one could relax a constraint (say, size of the map) and come up with a deterministic algorithm.

Dan - Mar 18, 2011 04:36:57 pm

I thought LineDrive was an excellent way to produce driving directions. I truly believe it needs to be the way that google maps works, I guess it's unfortunate that patents work the way that they do sometimes. I tried to see if I could break it, but it was very smart, even on U-turns and other non-obvious types of driving routes. Overall LineDrive produced easy to read directions that don't require a map and text, the map itself is sufficient.

I also like the automated assembly instructions project. The occlusion algorithms for choosing the best way to assemble the 3D objects was interesting. Although they didn't take into account structural components when choosing an assembly, they definitely allowed for rotations and transforming the orientation to allow people to assemble the objects in ways that are feasible. The results also proved that this method is not only more efficient in the sense that it is computer generated, but that people could complete the assembly in a faster time. Now that is a project well done.

Michael Cohen - Mar 18, 2011 09:00:31 pm

I also like LineDrive, and think it fulfills its purpose well. I'm a little more skeptical of the new route maps with context (water, highways, etc.). I share the intuition that more context is better, but I think the result may actually be a bit misleading compared to the straightforward "hand drawn" maps. In the Seattle directions, it appears that you're crossing much of downtown as you approach the end point. A LineDrive map looks enough like a real hand-drawn map that the lack of scale (or changing scale) is intuitive. With the additional context (even with the distortion and hand-drawn look) I think there's more of a temptation to treat the roads as being to-scale, or at least to-scale relative to the distorted context in the immediate area, which might lead to overshooting turns. I really want the contextual maps to work because in principle more information is better, but I think they may be in an "uncanny valley" of maps where the lack of realism is too subtle and the result is confusing.

[add comment]
Personal tools