Michael Gaigg: Über UI/UX Design


UI/UX/Carto/DataViz Community for Maps on Slack

Posted by Michael Gaigg

So we’ve started a slack community for Maps UI/UX/Carto/DataViz. The group was born after organizing the UI/UX special interest group (SIG) meeting at 2017 Esri DevSummit in Palm Springs. 38 participants - partners, distributors, users – came not knowing what to expect but with questions that go beyond what Esri offers or teaches. So I thought: it takes a community to raise a child...

This slack community is a great place to:

  • listen to our partners and users (be interested, not interesting)
  • network and share with designers/developers from other mapping companies
  • show our great work and cool stuff AND get instant feedback
  • help others with their problems

Request an invite at http://www.designingmapinterfaces.com/patterns/join-maps-ui-ux-community-on-slack/ and feel free to forward to your buddies 😉

Please join https://maps-ui-ux-community.slack.com/ and participate. Hope to see you there...



User Experience and Interface Design for Web Apps

Posted by Michael Gaigg

Here the video for my talk about best practices for designing map applications on the web from Esri DevSummit 2015.


Every map application has two characteristics in common: it tries to solve a problem, and it needs a user interface (UI) to do so. This session presents best practices for solving well-known design problems and how to create easy-to-use and compelling interfaces. - See more at: http://video.esri.com/watch/4316/user-experience-and-interface-design-for-web-apps


Part 1 (Michael Gaigg)
Part 2 (Allan Laframboise)


Proposing: Spatial Dashboard

Posted by Michael Gaigg

Dashboards are everywhere, they can be found in business apps, management information systems, administration tools. They all have the following in common, they show summaries, key trends, comparisons, and exceptions. Usually all of above relate to key performance indicators or to derived (rolled up) data.

The "traditional" Dashboard

Traditional Dashboard (published by directionsmag)

Traditional Dashboard (published by directionsmag)

In the spatial space the data is rolled up to geographical (mostly political) units like continents, countries, or states and therefore provide a graphical presentation of the current status (temporal) in relation to its geographical location. This is typically displayed as a thematic map side by side with summaries, charts, gauges, graphics, or tables.

While this approach is completely valid its biggest weakness is the disconnect of visual perception to visual presentation of information, i.e. the intent of communicating geographical information isn't clear or at a minimum ambiguous. How do the data charts relate to the data shown on the map?

The proposed "new" Dashboard

that outlines considerations about your target audience, domain, data, and visuals to be used.

I hope this article inspired you so please let me know what you think and anything else that comes to mind after reading this article.


Web Mapping Application Interface Design – Best Practices and Tools

Posted by Michael Gaigg

These are my slides from the tech session held at the Esri DevSummit 2013 in Palm Springs, CA.

The session teaches participants best practices for reviewing, conceptualizing, designing and building user-centered mapping applications in a competitive business environment. Methods, techniques and tools for improving the user experience and designing useful and appealing front-end interfaces will be discussed.


The World as we know it

Posted by Michael Gaigg

I just love the stereotypes used to create the world as we know it map of the world by Osama Haj jaj). True or not, that's what we associate with these countries and you better have a sip of Tequila and a Taco when you travel to Mexico or watch a soccer game when in Brazil.

The world as we know it


Progressive overview #map

Posted by Michael Gaigg

Flickr has a very slick way of showing the geolocation of a photo (thanks to Nicholas Furness for sending me this finding!). As you move your mouse towards the center of the map on the right panel of a photo page, the map zooms in a couple of times.




A quick re-engineering showed me that the HTML structure is really basic, a container holding a link, the 3 images (see above images) generated by REST calls at different fixed zoom levels (highlighted in bold above), the location marker (dot), and the copyright statement. JavaScript triggers the hover effect, now that is really slick and innovative - Bravo!

<div id="photo-story-map">
<a data-ywa-name="Location, Taken in, Map" class="photo-story-geopanel-trigger ywa-track" onclick="return F.actionQueue.queue_click(this.id);" id="photoGeolocation-smallmap" href="">
<img width="300" height="100" alt="" src="http://gws.maps.yahoo.com/MapImage?appid=FlickrDev&amp;clat=58.276828&amp;clon=13.602856&amp;zoom=4&amp;imh=100&amp;imw=300&amp;mflags=YKM" id="photo-story-map-zoom-out" style="opacity: 1;">
<img width="300" height="100" alt="" src="http://gws.maps.yahoo.com/MapImage?appid=FlickrDev&amp;v=2&amp;clat=58.276828&amp;clon=13.602856&amp;lat=58.276828&amp;lon=13.602856&amp;zoom=7&amp;z=7&amp;imh=100&amp;imw=300&amp;h=100&amp;w=300&amp;mflags=YKM&amp;year=2011" class="defer" id="photo-story-map-zoom-in" style="opacity: 0;">
<img width="300" height="100" alt="" src="http://gws.maps.yahoo.com/MapImage?appid=FlickrDev&amp;v=2&amp;clat=58.276828&amp;clon=13.602856&amp;lat=58.276828&amp;lon=13.602856&amp;zoom=14&amp;z=14&amp;imh=100&amp;imw=300&amp;h=100&amp;w=300&amp;mflags=YKM&amp;year=2011" class="defer" id="photo-story-map-zoom-street" style="opacity: 0;">
<div id="photo-story-image-dot" class=""></div>
<canvas id="photo-story-dot" width="16" height="16"></canvas><canvas id="photo-story-copyright" width="300" height="100"></canvas>

Real Name?

I dubbed this feature "Progressive overview map". If anybody knows the real name, please let me know, this is a cool feature!


Proposing “Sparkmaps”

Posted by Michael Gaigg

This is my proposed definition of "Sparkmaps":

Sparkmaps are small graphics that are embedded in a sentence, table, or listing to enrich its content with spatial information.

What do I mean by that?

Any geographic feature (=piece of information that has location information) becomes more relevant in relation to other (fixed or derived) features, e.g. mentioning a place makes more sense if I can see its location.

It's not always feasible to show a full-blown map or even only an image of a map as a figure on the side. All I want is to show the spatial information right where it is needed and without being taken out of the context.


The main characteristics of #Sparkmaps include that they are

  • embedded in (textual) content
  • small in size
  • simple (in terms of data)
  • comparable
  • value adding

That means that all irrelevant content is removed, leaving only the essential data.

When to Use / Examples

I believe that Sparkmaps can be used in many cases, especially to enhance understanding of:

  • Reference
  • Detail
  • Relation

Example 1: Mention of a location

An article is mentioning a location, e.g. Austria, Europe Austria. Yes, got it?

Example 2: Type-ahead Search (Gazetteer)

Auto-complete search using Sparkmaps

Figure 1: Auto-complete search using Sparkmaps

A user searches for a location. The application could offer type-ahead results with Sparkmaps to show the location in the context of the search, e.g. searching for "salem" would return a candidate list as the user is typing. Figure 1 shows an example with and without Sparkmaps/ Hey Google, you could learn something here!

Example 3: Preview when tabular data is side-by-side with a map

Map and Grid side-by-side

Figure 2: Map and Grid side-by-side

A search for "Colorado" returns rivers in Colorado. Identifying a single river is easy, one just needs to click on the table row to highlight the feature on the map. Sparkmaps reduce the physical effort by providing a preview of the feature (see Figure 2) hinting its location without the need to identify each and every row.

Example 4: Features not visible in current extent

A spatial search for US cities with a crime rate above 10% returns the results list but at the same time the map is already zoomed to a certain extent that does not include all the search results. The name of the city might be meaningless without the spatial content and one might only find out about the actual location by zooming to it and therefore loosing the current extent, which is undesirable. Sparkmaps provide this context without zoom-hell.

Example 5: Tabular data without a map

Bookmarks using Sparkmaps

Figure 3: Bookmarks using Sparkmaps

Sparkmaps can help providing contextual info when showing geographic data in tabular form, e.g. a list of bookmarks (Figure 3).

Example 6: Printing tabular data without a map

Let's assume a user has chosen to print out a results list (e.g. derived like in Example 3) but this time there is no map and therefore the spatial reference is missing altogether. Sparkmaps could provide this information right within the data table. Recipients of the print-out will be thankful also 😉

More examples could answer questions like:

  • What are the surrounding street names?
  • Is the house on the left or the right side of the street?
  • Does the pipe run underneath the street or next to it?
  • Which other relevant features are close-by?
  • Etc.

How to Use / Considerations

While creating the examples I realized that it is challenging to keep Sparkmaps legible and meaningful.


Like with any other user interface element, the value and downfalls of using Sparkmaps depend greatly on its use and abuse. It is really important to only use Sparkmaps when necessary or important for completing the task on hand. Sparkmaps should not be used just "because we can".


We will need to improve our cartographic and content selection capabilities to meet the need for creating small-sized maps. I'm not only talking about Sparkmaps here but also about map display for mobile that typically feature smaller resolutions than web or desktop.


The size of Sparkmaps can range from 24 pixel to 32 pixel. I found 16 pixel not being sufficient and 48 pixel too big in most cases.


Right now I'm not aware of any API that meets the need for the creation of small-sized maps. This needs to change either through explicit specification of Sparkmaps REST attributes (e.g. &sparkmaps=true&size=24) or through server-logic that is able to translate the request of a small-sized map into a meaningful cartographic layout.

Special case: On-demand Sparkmaps

On demand Sparkmaps

Figure 4: On demand Sparkmaps

Users might not be interested in each and every geographical detail, so we might not want to show Sparkmaps on every line of our data grid. Instead we could choose to display this information on demand, meaning that users can show/hide spatial content where needed. This is particularly useful when printing directions (see Figure 4) or similar. In this special case the maps can be of higher resolution because they would only consume real estate if really needed and requested by the user.

Your Opinion / Implementations

I want to hear your opinion on this subject, improvements and experiences greatly welcome. I suggest also to use hashtag #Sparkmaps when posting anything related to Twitter.


Update: Having done some more research I found an article by Andy Woodruff written on 16 March 2009. He is contemplating about Sparkmaps based on the same idea of having tiny, non-intrusive supplemental maps - in his case suggesting to embed them in the margins along the text or as popup windows.


How to trigger “Edit Mode”

Posted by Michael Gaigg

In a recent discussion it occurred to me that there are really only 3 ways to trigger "edit mode", i.e. tell the map that I want to add/edit/remove something:

  • Binary
  • On
  • Selection


The edit mode is either turned on or off. Turned off is the default mode and requires explicit action by the user to turn it into edit mode with the advantage that user is aware of this switch, which might also trigger other behaviors to be turned off (map tips,...) or removed from the map (scalebar, overview map,...)

Use "binary" if editing is a major part of your app so that this distinction becomes crucial.


On is a subset of the binary case where the edit mode with all its functionality is always on by default and any interaction with the map allows users to select features to be edited or deleted, or add something new.
This case might conflict with other mouse events (e.g. a left mouse button up event usually triggers a map tip) and therefore needs to be very well thought-through before implementing.

Use "on" if you can fit it into your workflows and you can oversee and have control over most/all map functions.


Selecting an edit tool through a toolbar for example is the classical way of setting the map into edit mode. It speaks very loud GIS expert to me and seems to not being familiar to the average map user, i.e. it may be difficult to find the right tool from the sway of icons, learn (and remember) that this action is required AND know that the mode needs to be turned off again after being done.

Use "selection" if your map app already has a toolbar and you want to be on the safe side.

How do you prefer doing it?

What are your preferences/experiences?