• An Ontology of Pop-ups

last modified November 4, 2009 by rpenate

The Problem

So I was tossing and turning in bed on Thursday night thinking about the OpenLayers UI proposal. Something wasn't sitting quite right with me, there was something amiss about the proposal that I couldn't put my finger on. Then it occurred to me that the sidebar was all wrong—not just how it was being used, but that fact that it existed at all. When Mouna and I made the initial suggestion it was an easy solution to the problem of finding a home for the comments. In proposing an off-the-cuff  solution to a minor problem, we had inadvertently boxed the entire project into a faulty paradigm.

See also: Cartography 2.0 - Data Probing

Desktop application vs. Web application

We kept thinking of the map as a desktop application with a monopoly on screen real estate  as opposed to a web application that can exist in a myriad of spaces and configurations. We had basically imposed upon users (both producers and consumers) a map which could only be used one way: alone, full-screen, with little context.

The reason that  things like Google Maps keep popping up in every corner of the web is because they can. Google makes it incredibly easy to produce and disseminate maps. and his ease of use has lead to widespread adoption—it doesn't take a computer scientist to figure out how plop one into a blog post. We, on the other hand, not only make it hard to consume maps, by disallowing embedding in our OpenPlans software for 'security' reasons, but are now on a path to make it difficult  to produce maps as well.

As an example of our narrow focus, picture the map as it is now—running edge-to-edge on our luxuriously large monitors. Looks neat, eh? A real application will all these neat pop-up effects.  Now shrink it to a generous width of 620 pixels and embed into a blog post, like so:

vespucci-tight.png

See what happens with the sidebar? It takes up 340 pixels (well over half) of the room available on the map and leaves no room for the pop-up itself, which is supposedly the star of the show. Clearly this model is not going to cut it.

The Solutions

Fortunately, we don't have to reinvent the wheel. Google Maps already provides us with a working model of how to approach mapping on the web. Much of this model has already proven itself on the web and established conventions as to what sort of interactions users expect.  We don't have to start from scratch with new models to be innovative when instead we can build on others' successes and contribute our own competitive advantages.

We don't need to fight Google head on when we can instead build to our strengths. We can improve on their model in several ways, including: better organizing the information in our pop-ups; providing better collaboration tools, such as comments and history; and being more open about how we import, export, and share data. The latter two are primarily technical issues  (though they likely have interaction aspects), so I am going to focus primarily on the first: how we structure our pop-ups.

Anatomy of a Pop-up

openlayers-anatomy-of-a-popup.gifWhy add more objects to the interface when we should instead improve the one we have?  Rather than arbitrarily using a sidebar to collect metadata about a marker, we'd be better off leveraging the pop-up itself. Doing so is not only more intuitive for the user, but also declutters the interface and simplifies issues of trying to synchronize state between the pop-up an a sidebar.

As Google and Yahoo have proven in their mapping applications, the pop-up can be a very versatile tool. Unfortunately, it can also be a bit unweildy if improperly structured or inconsistently used. My proposal is that we scrap the sidebar and instead structure our data using the carefully defined pop-up structure on the right.

  • The red section in the upper left is the title and describes the entire object.
  • The orange section just below is for different views on that object including notes, comments, and history—though one could see contexts in which other would be appropriate, perhaps 'team' and 'tasks' if it is a view of an OpenCore project.
  • The green section in the center contains the content of a particular view and is the only section that scrolls if the content exceeds the maximum pop-up size.
  • The blue section in the lower left is for state-changing actions related to the current view, such as adding a comment when in the comments view or editing the notes when in the notes view.
  • The purple section in the lower right is for actions or resources that terminate or are supplemental to the current state, such as a comment feed when in the comment view or the save/cancel options when editing the note.
  • The white section in the upper right is reserved for actions that are attached to the entire pop-up, not a particular view within it.
Although these conventions should be adhered to as much as possible, they should not be a hindrance to the user and should be deviated from in exceptional circumstances. Below is an application of this pop-up anatomy to our different needs and a comparison to how Google handles similar problems in their mapping apps.


Normal view

 google-1-default.gif  openlayers-1b-default.gif
Google's typical pop-up. It appears when you click on a marker.
A summary marker could appear on Vespucci when you hover on a marker, much the same way as the functionality on Yahoo Maps. The marker could show the number of comments and information about the last edit. Clicking on the marker would expand into the expanded view. Clicking on the number of comments should jump straight to the comments view.

Expanded view

 google-1b-default-expanded.gif

openlayers-1b-expanded.gifopenlayers-1c-expanded.gifopenlayers-1d-expanded.gif

And this is their expanded view. It appears when you click on 'more info' in their standard pop-up.

Obviously their information design is sorely lacking. The tabs seem to float in some invisible navigation forcefield. 

This proposed layout addresses the problem of navigating through different forms of data attached to an object on the map in a similar way as Google, but with better information design.  Rather than use wiki space to handle content in pop-ups like Google does, we can opt for the more user-friendly solution of guided content management. For pop-ups that allow multimedia, the notes context could have various sub-contexts (like images or videos) that display a summary of all of the attached content. Clicking on an item displays it in a subcontext of the Notes context in the same way that the "Add comment" view is a subcontext of the Comments view.

Edit view(s)

 google-2-edit.gifgoogle-3-edit.gif openlayers-2-edit.gifopenlayers-2b-edit-description.gifopenlayers-2b-edit-images.gif
Google is inconsistent in their edit views between the main mapping application and MyMaps. In Google Maps the edit functionality is attached to the individual pop-up, while in MyMaps it is attached to the state o­f the entire map via a sidebar button. It's acceptable to deviate from conventions when there is good reason to and the Edit view is the only view that is an exception to the general information design conventions. This pop-up proposal consolidates the edit, delete, and move functionalities that Google spreads across different pop-ups. For notes that allow other forms of media besides text, it borrows the visual language conventions of the context tabs to declutter editing subcontexts on the Notes view. Since the Edit mode contrasts with the contexts in the View mode, it'd probably by wise to give it a slightly different visual treatment—perhaps a faded background color or hatching.
google-3b-edit-icon.gif

 ­google-2b-move.gif  The move workflow that Sonali, Seb, and I have hashed out  collapses the pop-up and attaches the marker to the mouse. When a user clicks to place the marker in a new location the pop-up reappears and the Save/cancel actions verify or discard the move.­

History view

­
 ­google-2c-history.gif
Google's newly implemented history view is a bit clunky and indicative of their general issues with information design. To reach it one clicks on the edit feature in Google Maps and then the view history link that appears. The implication being that history is subservient to editing.
openlayers-4-history.gif ­
Google has yet to implement history in any collaborative way (it doesn't yet appear on MyMaps), making this a key area of competitive advantage for us. Foregrounding the history makes the 'cost' of editing seem lower and thus encourages collaboration. Coupled with commenting ability we are one step closer to social mapping.

Comments­ view

­ ­ ­
 openlayers-3-comments.gif­
Commenting isn't something any other web maps allow users to do, which is surprising given how popular it has proven on blogs and even Google's own YouTube and Video apps.
openlayers-3b-add-comment.gif
 
Adding a comment should be as straightforward as doing so on WordPress.

Exte­nding the model

There is no reason to limit ourselves to using the basic information design of the pop-up on markers alone. The same structure can be expanded to address other issues on the map, such as the tools and map history. Updating the proposal Sonali and I came up with before to fit into this model would result in something like this:

 

openlayers-tools0001.png

openlayers-tools0002.png

openlayers-tools0003.png

openlayers-tools0004.png

 

Multimedia notes

­

While a more long-term proposal for embedding images and videos in the Notes context is detailed above in the examples for the Expanded view and Edit mode of pop-ups, there are obvious benefits to making short-term, incremental improvements rather than jumping headlong into something new and untested. Below is a simplified version of the proposed image-handling pop-up views to get the ball rolling.


 

openlayers-simpleimage-view.gifopenlayers-simpleimage-edit2.gifopenlayers-simpleimage-edit1.gif