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)
- 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:
Example 1: Mention of a location
Example 2: Type-ahead Search (Gazetteer)
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
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
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?
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
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.
- Sparkline theory and practice (from Edward Tufte, May 27, 2004 and excerpts from Beautiful Evidence by Edward Tufte).
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.
- Proposing: Spatial Dashboard
- Question: How can Internet Mapping Applications be made accessible?
- Happy 5th Anniversary
Enjoy this article?
Posted by Michael Gaigg
Michael Gaigg is Lead UI Engineer in Esri's Professional Services Division.
He has been designing map application for over 10 years and can't stop thinking about improving them.
- Accessibility (16)
- Code Samples & Tips (15)
- Conclusions (6)
- Design Guidelines (12)
- Designing Map Interfaces (6)
- Go figure (9)
- Good News (28)
- Here and there (30)
- Map Applications (14)
- This Week's Highlights (53)
- Usability & UCD (28)
- Web Design (30)
- 15 Outstanding Examples of Braille in our World
- Dashboard Design
- Go figure: 10 Comic Strips that have Something in Common
- Powerpoint Wireframe Stencils as Free Download
- Job Posting: User Interface (UI) Engineer at ESRI
- Redundancy is NOT bad!