# data[].attributes.headline
Interactive Prototype + User Study : Maps vs Lists – theuxblog.com

# data[].attributes.subject
Interactive Prototype + User Study : Maps vs Lists – theuxblog.com

# data[].attributes.attachment_link.readable_text
There are pros and cons to both methods of information and data representation, appealing to different scenarios better. In the case of restaurants and dining venues, if one looks at it from the perspective of location (diving deep into the details, such as the nearest street, nearest building, nearest district, etc), then a map view may be better, as the user considers location as the first priority. But if one looks at it from the perspective of other qualities of measure, such as restaurant type, rating, price ranges, or any one of the many attributes that we can use to decide on a restaurant to visit, then the map representation may become less useful, and even over-complicate things.

A user study was conducted, focusing on investigating whether participants are likely to prefer a list based interface, or a map-based interface, in relation to the same scenarios. The scenarios are listed here again for reference, and these scenarios follow through all the way from the beginning of the "Designing the Dining Experience" series.

Instantaneous scenario: User wants to discover new restaurants and dining venues to visit on an instantaneous basis - meaning right now, or within the next hour or so. (In this scenario, who goes for the meal, and when the meal is to take place, becomes somewhat irrelevant for the app. All the app has to bother about is the 'where' portion - which restaurant to go to?)

Scheduled scenario: User is organizing a meetup with some other people (possibly friends, etc) over a meal, and this meetup will occur at a particular day and time, at a particular dining venue. (In this scenario, not only is 'where' important, but 'who' and 'when' becomes equally important.)

Before this user study was conducted, participants were made known of both scenarios, and then asked to compare two different sample interfaces which showcase restaurant interfaces.

These two interfaces have been made into interactive prototypes, and they are embedded in this post. Click here to view the prototypes at the main website!

User Study + Results

Users were told to scroll through the list of suggested coffee venues, and to select the top-rated cafe which is within 5 minutes walking distance from where they currently are.

They were told to do this on both interfaces, at different times. Eventually, they were asked the following questions regarding which interface was better for the given scenario.
Which interface did you find easier to carry out this task?

In general, while performing the above task, did the presence of the map help you significantly?

Not at all. At this stage, I just needed to know how long it would take to get there.

Helped a little bit. Useful to visually see the position on the map while choosing the restaurant.

Very helpful in giving me a sense of space and direction.

Generally, the map interface has more information visible, while the list interface abstracts away more information, providing a simpler interface.
In this scenario, do you think it is worth it to sacrifice some information for a simpler user interface?

Yes. A simpler interface for this particular task is sufficient.

No. The map provides more information, but this information is important at this stage.

Discussion of User Study Results

The overall results of the user study indicated that people generally preferred the simplicity of the "vertical list interface" over the increased level of information provided by the "map interface". The list interface emerged as the overall winner, with a larger overall percentage of respondents indicating that it was easier and sufficient to use the list interface in the given scenario.

In the scenario being studied, it is likely true that knowing the exact positions of the restaurants on the map was not an important consideration, seeing that the interfaces being studied already display more vital information for the scenario, such as the number of minutes of walking required to get to these restaurants.

Furthermore, when a user is choosing a place to dine at, other aspects, such as its rating, quality, price range and ambience are more vital considerations (as supported by the previous user study on information abstraction of restaurant attributes).
Interactive Prototype
Several users actually raised the issue that a map-based interface would be a much better fit if the primary use of the app in question was for mapping. Take the example of Google Maps and Apple Maps, where the map is a primary feature, the center of everything. For such apps, it makes sense to use a mapping interface, such as the one seen in Interactive Prototype 9.1.
Feel free to try your hand at the prototypes, and see whether you agree with the general consensus of the user study. The prototypes are available on the full website, linked here! Previous Post : Listing Restaurants - Introducing Maps and Lists
However, for an app which aims to cater to other primary purposes, such as recommending restaurants, other forms of information will likely be more important than the geographical location of the dining venues. A list-based interface, such as the one seen in Interactive Prototype 9.2, would also help to standardize the interaction, and reduce the number of different types of navigation techniques present in a single app - this is an important consideration when it comes to good UI/UX design which is often forgotten.

Interactive Prototype 9.1 features a map-based interface that borrows many similarities and design cues from Google Maps. Interactive Prototype 9.2 features a list-based interface. In this example, the list-based interface actually features less information than the map-based interface, sacrifising it for a simpler and more conventional vertical-scrolling interface. These two prototypes were used for the user study described above.

# data[].attributes.attachment_link.title
Interactive Prototype + User Study : Maps vs Lists - theuxblog.com

# data[].attributes.attachment_link.description
There are pros and cons to both methods of information and data representation, appealing to different scenarios better. In the case of restaurants and dining venues, if one looks at it from the perspective of location (diving deep into the details, such as the nearest street, nearest building, nearest district, etc), then a map view may be better, as the user considers location as the first priority.

# data[].attributes.headline
UX Best Practices for web based map - User Experience Stack Exchange

# data[].attributes.subject
UX Best Practices for web based map - User Experience Stack Exchange

# data[].attributes.attachment_link.description
I am looking for best UX practices for controlling a map in a web environment. The use cases I'm looking for are: Creating/editing shapes and polygons Switching maps Playing with object layers

# data[].attributes.headline
Getting Lost and Found – Maps and the Mobile User Experience | Interaction Design Foundation

# data[].attributes.subject
Getting Lost and Found – Maps and the Mobile User Experience | Interaction Design Foundation

# data[].attributes.attachment_link.readable_text
The ability to harness GPS data and map data on smartphone platforms offers designers a chance to enhance the user experience of their products. However, in order for maps to deliver better experiences for users - it's important to integrate these features with UX in mind. There are some sensible rules that can be used to increase your chances of success when using location data and maps in mobile apps.

Author/Copyright holder: Search Engine People Blog. Copyright terms and licence: CC BY 2.0

There's no doubt that the smartphone has brought users and designers a wealth of choices when it comes to new facilities; one of the most popular of those is the GPS (Global Positioning System) functionality. GPS can be used to calculate the user's position and be combined with map data to provide ways for users to find locations and get directions to them.

However, it is important to consider how you will implement maps within your mobile websites and applications before automatically deciding on their conclusion. Research from the Nielsen Norman Group found that when presented with a mobile site which did not include a map on location search results pages - not a single user wished that a map had been provided. In fact their research recommended that maps should be an option for users to toggle out to and that location data should be presented as a list ordered by mileage from the nearest location in the first instance.

Why is this the case? It is almost certainly because maps within mobile apps and websites fail to take into account certain usability considerations.

Usability Considerations when Implementing Maps in Mobile Designs

Scrolling and Panning

One of the nice things about maps is the ability to pan across them by dragging the map. This functionality works extremely well in a desktop environment when the user clicks on the map and then drags the map with a mouse. It is more difficult to pull off on a smartphone screen where the user interface is a touch screen.

Users will often scroll the page rather than pan or vice-versa because the boundaries of the map and the boundaries of the screen conflict. This may be overcome with the use of borders around the map so that the user has a distinct area for panning within.

Pinpoints Conflict with Target Sizes

It can be easy for designers to forget that touchscreens are not the most sensitive of devices and that ideally, for a user to click on an area, it needs to be about 36 x 36 px.

Pinpoints on maps are all too often rendered smaller than this 36 x 36 px target which makes it difficult for the user to affix on a target and interact with it.

There is also the issue that if a map is presented at too high a level; there may be may pinpoints found at the same location on the same screen. Differentiating between these pinpoints via touch is a frustrating experience. This may be handled by using notifications that allow the user to touch a single point and then choose from a list of pins or by presenting a map at the appropriate magnification to ensure all pins are distinct and separate.

Author/Copyright holder: Arambar. Copyright terms and licence: CC BY-SA 4.0

Touchscreens, Networks and Other Issues

The touchscreen is not the most sensitive of devices and when combined with a slow network connection; maps can often lead to frustration beyond the designer's control. A user who uses the screen to expand a map view, for example, may find that a slow network connection makes it appear their efforts are not having the correct impact.

This in turn leads to the user redoubling their efforts and over expanding the view, which becomes a source of frustration. It is difficult for the map interface to provide useful feedback to a user in these circumstances - it is very much worth considering an option to allow the user to move directly away from the map and back to a list view of locations at any given point in their interaction with the map.

Gesture Control

The simpler you keep the UI on the map, the more likely you are that your pins and controls will meet that 36 x 36 px guideline for touch points. That does not mean that you cannot offer additional functionality to a map user. It does mean that you will need to consider gesture controls for this additional interactive functionality. These gesture controls may not be immediately obvious or intuitive for the user and will need careful application to add real value to the user-experience.

Author/Copyright holder: Intel Free Press. Copyright terms and licence: CC BY 2.0

Tool Bar Positioning

Tool bars can occupy a big chunk of screen real estate and they must remain spaced out far enough from the map itself so that the user does not accidentally end up activating the tool bar when trying to interact with the map.

Ideally, tool bars should also be simplified and reduced when the user is engaged with the map to try and accommodate the easiest interactions with the map.

Author/Copyright holder: BaseCamp. Copyright terms and licence: Fair Use.

Help and Escape

The final tip for implementing maps is one that applies to many areas of UX design. Always give your users a little assistance (you can use pop up messaging to aid understanding of gesture controls or other functionality that may require explanation, for example) and a way to get out of the map and back to a more familiar interface.

The Take Away

Implementing GPS and map functionality may not be necessary and it is a good idea to test the requirement with users prior to implementation. If it is useful to your user base, you should try to incorporate the guidelines in this article in order to improve the UI and UX of the map implementation. Maps are a real challenge for small screens on smartphones and need careful handling to provide value to users rather than detract from it.

References

A case study in map deployment using Google maps - http://www.tnooz.com/article/lessons-for-mobile-app-developers-on-why-google-maps-for-iphone-looks-so-good/

An interesting examination of usage issues for map data within mobile apps - http://www.slideshare.net/fgarofalo/ux-considerations-for-mapping-apps-on-touch-devices

Brad Frost examines the adaptive map here - http://bradfrost.com/blog/post/adaptive-maps/

Hero Image: Author/Copyright holder: Johan Larsson. Copyright terms and licence: CC BY 2.0

# data[].attributes.attachment_link.title
Getting Lost and Found - Maps and the Mobile User Experience

# data[].attributes.attachment_link.description
The ability to harness GPS data and map data on smartphone platforms offers designers a chance to enhance the user experience of their products. However, in order for maps to deliver better experiences for users - it's important to integrate these features with UX in mind.

# data[].attributes.headline
UX Considerations for Mapping Apps on Touch Devices

# data[].attributes.subject
UX Considerations for Mapping Apps on Touch Devices

# data[].attributes.attachment_link.title
UX Considerations for Mapping Apps on Touch Devices

# data[].attributes.attachment_link.description
Demo Theater, co-presented with Allan Laframboise

# data[].attributes.attachment_link.readable_text
Citymapper is what happens when you actually understand user experience.

Every so often, an app comes along that just completely understands the way you think. I don't normally write long posts about an app I've used. But Citymapper is so incredibly well-made that I decided to put together a list of common use cases of a maps app, and how both Google Maps and Citymapper handle them.

Scenario 1: I need to get somewhere as fast as possible.

Citymapper, 10 seconds: I can see all 4 options (public transport, walking, car/taxi, and biking) side-by-side, allowing me to compare options quickly.

Google Maps, 20 seconds: I need to click through each individual option and remember which is the fastest. Also, the flyover animation is cool but unnecessary when I'm trying to see what the fastest time is.

Scenario 2: I want to see the time needed to get from point A to point B.

Citymapper, 10 seconds: I can enter my origin and destination at the same time.

Google Maps, 30 seconds: I need to first enter my destination, then specify how I want to get there, and then change my origin from "My Location" to a different address.

Scenario 3: What are the trains near me?

Citymapper, 2 seconds: Since I know the subway system pretty well, I don't always need full directions - I just need to know where the closest subways are so I can judge which one I should take. With one click on the train icon, I can see all the trains near me, sorted by distance. Same thing for buses.

Google Maps, 30+ seconds: There's no way to see all nearby trains, so you have to manually look around your waypoint and click on each station. There is a public transit option in the sidenav, but it only highlights the lines on the map and you still need to click through to see which stations are closest. And at transit hubs (in this case, Union Square) it considers different subway entrances and lines as separate, so it won't let you see aggregate information for a particular station.

Scenario 4: How long will it take me to get somewhere by Citibike?

Google Maps, can't do it: Google Maps doesn't have bikeshare integration, so I'm forced to switch apps and use the equally scatterbrained Citibike app to find availability.

Citymapper, 15 seconds: Not only does Citymapper find where the nearest Citibike location is and let me choose whether I want the fastest route or the quietest (read: safest) route, it also notices that the closest Citibike location to my destination has no available spaces and reroutes me to the next closest one that does. That's magical.

Scenario 5: I just searched for directions at the office, and now I want to see those directions again.

Citymapper, 5 seconds: Previously searched destinations can be found right underneath the search bar for easy access.

Google Maps, 10 seconds - if you know where to find it: For some reason, previously searched destinations are found under your profile (the person icon next to the search bar) instead of when I search. I never noticed that until I started writing this post.

Scenario 6: I'm late to a meeting so I'm sprinting as quickly as possible down the street, looking at my phone for directions.

In any other app, shaking my phone might mean "undo last action" (e.g. Mailbox) or "submit feedback" (e.g. some beta builds of mobile apps). In a maps app, though, there's pretty much one thing a shaking phone means - I'm running, biking, or just moving. And when I do any of that with Google Maps, this happens:

It blocks my view, it shuts off turn-by-turn directions, and is altogether a pretty terrible interaction.

Other design details

City icons

Going to a different city? Citymapper's customized icons for each of its supported metro areas gives the app personality.

Offline subway map

If you're in the subway, you can access a full offline zoomable subway map by clicking on an icon on the homescreen. They also have a "Save trips" option on the directions screen so you can save directions for offline use (e.g. on a subway).

Humor

First, their release notes are legitimately funny:

And when presenting your transit options, Citymapper will occasionally throw in a funny option:

But I guess I'm easily amused.

Final thoughts

Citymapper is more thoughtfully designed for urban travel. But for people who drive cars, something like Waze - with its fullscreen interface and crowdsourced realtime information - is a better choice.

And there are still features I would love to have in Citymapper. Turn-by-turn directions. Spoken directions for when I'm on a Citibike. Maybe personalized time estimates that are tailored to my walking, running, and biking speeds. But whatever Citymapper adds to the app in the coming months, I know it will be thoughtfully engineered and designed to make finding directions almost fun.

If you're so inclined, you can download Citymapper here. (And disclaimer: I have no relation to Citymapper. Just a happy user. They didn't even know I was writing this post.)

# data[].attributes.attachment_link.description
Every so often, an app comes along that just completely understands the way you think. I don't normally write long posts about an app I've used. But Citymapper is so incredibly well-made that I decided to put together a list of common use cases of a maps app, and how both Google Maps and Citymapper handle them.

# data[].attributes.headline
6 Mistakes to Avoid When Designing Maps for Your Apps

# data[].attributes.subject
6 Mistakes to Avoid When Designing Maps for Your Apps

# data[].attributes.attachment_link.readable_text
Have you wondered why every app you try to open today asks you to enable location access? Everyone out there wants to know where you are, though not in a creepy way - we hope. Similarly, gone are the days of asking for directions. No matter where you have to go, you open the map and check it out even before you leave the house.

And how often have you spent the better part of an hour just fiddling around with maps, trying to get a figurative view of where you are and where everything else you know around you is.

Let's face it, maps are just everywhere. We use them and need them, all. the. time. No wonder Google Maps is the most used mobile app in the world.

However, despite some truly remarkable innovations that have made maps an indispensable part of our mobile experience, almost every map-based app out there has something left to be desired. Extensive usability testing is required to make sure you gain a nuanced perspective of every usability issue that can happen when using a map on a mobile screen.

Small screens, fat fingers, slow networks and a number of other contingencies need to be accounted for and an extremely effective design needs to be implemented to truly make your in-app maps usable.

So here are a few easy-to-miss details that you must pay attention to when designing maps for mobile:

1. Scrolling and Panning Problems

When I want to scroll, the map begins to pan. When I want to pan, the map zooms. Swipe ambiguity is a major reason most users have a hard time using in-app maps. It used to be easy on the desktops, just press, hold and drag the mouse to pan the map, or scroll away without a second glance. On mobiles though, things get a little more difficult.

Most often, an average 5-inch mobile screen just about holds the map, with little space left in the sides and the bottom. If a user wants to scroll down, pass the map and go over to the list of results or any other section of the page, the user tends to use the most common swipe-up-from-bottom-gesture. However, instead of scrolling, this gesture begins to pan the map. There often seems no way to figure how to stop the panning and start scrolling, or the other way round.

Designers can try to overcome this issue by providing a 'gutter space' at the sides of the screen, which the map doesn't occupy and can be used by the users for scrolling. Alternatively, you can provide an option to hide the map, allowing users to skip straight to the list results.

2. Too Many Points Too Close Together

When a map is searched for queries like 'Restaurants in Paris, You'll probably see something like this.

See how many little icons overlap each other here? Pin pointing a specific one out of all these would be a challenge for even the slenderest of fingers. It also doesn't give a clear enough idea of how many options there are to choose from. Zooming in would solve the problem to an extent, but that would eliminate the outer results from the screen's periphery, making it harder to make a comparative analysis.

Densely packed display of icons is thus another issue that app designers will have to work through. A good concise list result with relative mileage of each from a point of reference is the better way to do this.

3. Slow Networks Lead To Less Responsive Maps

Sometimes, zooming-in on a map does nothing. So you zoom again. By this time, the map is blown way out of proportion and everything is a blur. This is because due to slow network, your first zoom gesture took too long to respond.

You thought nothing happened and zoomed again. When the network finally caught on, your map had been zoomed in twice, maybe thrice. You try to zoom out, but it's taking its time again, making you wait longer. So what should have been a second's job has now taken far too many.

It is important to design your maps in a way that allows users to zoom smoothly even on low-speed networks.

4. Simple UI and Innovative Gesture Controls

At the moment, the only two major gestures commonly used are the swipe and the pinch. It is however possible to make innovations and take things to the next level and create more effective gesture controls for maps. For the moment though, keeping your UI as simple as possible is important to let users effectively navigate through apps.

5. A Better 'Near Me'

It happens all the time that we Google 'Restaurants Near Me' and end up receiving results for a restaurant that, though popular, is over five miles away. Locators aren't always doing a good job of filtering results to show places near me. There should be a provision to specify a radius, so the map can show relevant results within that radius.

6. Provide an Easy Out

While this is a general rule that applies to all UX design, no harm in reiterating it in context of maps. For users who wanted to try out a map interface but are now just about done with it, be sure to provide an easy way to exit the map and return to a simple interface. Also, use visual aids, prompts and examples to explain areas and gestures that need explanations. In short, just do whatever it takes to make users' lives simple.

Wrapping Up

Maps are an extremely significant part of our mobile experience and with an increasing number of businesses using location-based data to provide information, special offers and customized service, the demand for quality map-based apps is only going up. Quite obviously, so is the competition.

It is better to not have a map than to have a badly functioning map. The above pointers will help you avoid the common problems that plague maps usability on mobiles so that you can design a great map app.
Written by Almeda Brooks, a freelance writer for MoveoApps.

Guest writers occasionally contribute their insights and expertise to IoT For All and help us educate the people building IoT solutions with new technologies. If you're interested in sharing your insights as a guest writer, please visit https://www.iotforall.com/contribute/.

# data[].attributes.attachment_link.title
6 Mistakes to Avoid When Designing Maps for Your Apps

# data[].attributes.attachment_link.description
Have you wondered why every app you try to open today asks you to enable location access? Everyone out there wants to know where you are, though not in a creepy way - we hope. Similarly, gone are the days of asking for directions.

# data[].attributes.headline
search - Displaying data on a map - User Experience Stack Exchange

# data[].attributes.subject
search - Displaying data on a map - User Experience Stack Exchange

# data[].attributes.attachment_link.readable_text
Yes, limiting the number of results on the map will simplify the map, however...

...it creates a bias that could influence your user in either a positive or negative way. There are a lot of factors that go into this though and there are two tracks of people I can see when using this map (Explorers and Beeliners). Explorers are going to go around the map, take their time, see what applications are out there, play with the filters, etc. Beeliners are going to go straight to the application they want with no goofing around, playing with filters, and so on.

With these two types of people in mind, there are a few other questions you need to ask yourself. Are your users going to be exploring or are they going to look up a specific application? What else can they do? Are they allowed to edit the application?

Based on the two groups of people I described above, my suggestion would be to show all of the points, and use a clustering algorithm to show a pod with a large number in them (like in the image below).

Clustering on Google Maps or Leaflet would be a great way to have all of your data available to the customer while not providing bias. It also allows for both scenarios of people (explorers and beeliners) which caters to the largest number of people. Finally, you would still be able to apply multiple filters to the markers and allow your users to see any variation of the data they choose.

# data[].attributes.attachment_link.description
it creates a bias that could influence your user in either a positive or negative way. There are a lot of factors that go into this though and there are two tracks of people I can see when using this map (Explorers and Beeliners).