Michael Gaigg: Über UI/UX Design

18Jul0

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.

Characteristics

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.

Usability

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".

Cartography

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.

Size

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.

Creation

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.

References

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.

28Aug0

Presentation: Wiki – the right tool for my organization?

Posted by Michael Gaigg

Finally I got my head around posting a presentation I gave last March. The title is "Wiki - the right tool for my organization?" and had the purpose of introducing the concept of a wiki to a group that was about to install a wiki within their department.

Background: About three years ago I went through the effort of evaluating existing wiki platforms, installing/hosting it for our department and keeping it alive for the next two years before it got sacked. I'm here to tell you why it didn't work out in the end.

Characteristics

I jump right into the characteristics (the slide "Characteristics" is duplicated in the presentation on purpose) because I found understanding them key to a successful implementation. That's why once more I want to emphasize on the issues that need to be met in order to successfully implement a wiki, for example if your company has no culture of sharing content or employees are reluctant to give up ownership of their code, a wiki is most likely not the ideal collaboration tool.

These are the characteristics of a wiki:

  • Perpetual work in progress
  • No one owns the content
  • No specific organization (hyperlinks)
  • Anyone can edit other people’s work
  • Discussion area for each page
  • Version control: list of all changes made to a page

Critical Success Factors (aka truth about a wiki)

Only implement a wiki if you feel comfortable you can meet the following critical success factors:

  • Only 10% contribute; only 1% on a regular basis.
  • Obey the characteristics of a wiki
  • Power to the people
    • Trust the user
    • Authority to change something
    • Refuse defined structures

My previous experience taught me that implementing a wiki into your organization is doomed to fail if one is not aware of their importance and therefore

  • overestimates the reach and participation,
  • neglects the characteristics of a wiki,
  • or doesn't want or cannot give power to the people.

The truth is, only 10% of users contribute to a wiki and only 1% on a regular basis. If you have 100 employees you can expect between 1 to 10 of them to contribute and the rest to consume - which in turn will lead to lesser contribution and lesser consumption over time. Wikipedia works well because there are millions of users where 1% is still significant number to keep up quality content.
The argument of mandatory (or even monitored) participation runs directly against the characteristics of a wiki, is counter-productive and will result in your wiki failing.

Choosing a wiki: What to consider

Obviously there are many criteria and features that will directly affect your choice. I recommend Comparison of wiki software as a starting point for finding the right software but I wouldn't be surprised if you ended up with MediaWiki which is the used by wikipedia for one simple reason (besides its free usage under the GPL license and its huge community): the MediaWiki syntax is widely used and makes actually sense to learn - because it is wikipedia 😉

Criteria

  • Cost (open source license)
  • Programming language (PHP, C#, Java)
  • Data backend (File system or DB)
  • Extensibility & user community

Features

  • WYSIWYG editing & Syntax
  • Version control & Discussions
  • Permissions & Security

Keys to get a wiki going

Once you've decided to go ahead and install a wiki, what can be done to make it successful?

  • Find dedicated helpers
  • Partner with groups/people related to your mission
  • Offer structural templates for new pages
  • Add some content to major categories
  • Do lots of marketing
  • If possible, offer training

Do you work with wikis?

What are your experiences? Do you use a wiki in your company? How do you use it?