Hello and welcome to the third part of my series on user experience tips and tricks for indoor location apps.
If you haven’t already, be sure to check out the first part and the second part!
The next thing I would like to talk about is the heading, and what you should use it for. Together with the location of the user, you will also get the heading. While the location tells you where the user is, the heading indicates the direction that the user is facing. This extra information will make it easier for users to orient themselves on the map.
How do we use maps in real life?
To begin with, let’s consider how we usually use maps in real life, without all benefits of using a digital map. Let’s say we have a paper map in our hands and we need to understand where we are, and where we should go. First, we find our location on the map. Once we have that figured out, we need to understand what direction we’re looking at. To get this information, one way is to rotate the map so that it lines up with the real world. By doing so, whatever in front of us in real life is also in front of us on the map. Now, with this map lined up, it is easy to figure out where we should go.
This is how I use maps in real life. With the use of digital map, I will get much of this for free and I can faster and more easily get to where I’m going. And all this gets possible by using the heading information, so let’s look at how we should implement that, and the different aspects to consider when using the heading.
From previous, we already have the blue dot on the map. The simplest and often the most overlooked feature is to add some sort of arrow on the blue dot. This arrow will indicate the direction of the device in the horizontal plane.
For some more experienced map readers, this might seem like unnecessary information, but for most, this will really help the user to understand his location. Most map providers give you some sort of arrow on the blue dot. Some more subtle than the others. The important thing is that it’s present.
The next is the rotation of the map. To help the user to understand their location we should rotate the map using the heading we get. Since we have the heading of the user, we can automatically rotate the map for the user. What the user has in front of themselves should also be in front on the map. That way the user can easily and without much effort locate themselves on the map.
In my experience, there is one catch with the rotation though – not everyone will benefit from it. Therefore, I recommend that the rotation should be optional. While rotation might help one person, it might confuse another. One frequently used approach to make this rotation optional is to implement a centering-button with three states.
The states here are “None”, “Center”, and “Center and Rotate” and pressing this button will toggle between these three states. This approach is widely used by map providers for this purpose.
- None does nothing. The map stays still as it is and the user moves and rotates the map manually.
- Center locks the user location to be in the center of the screen. When the position is updated to a new location, the blue dot stays locked in the center and the map moves underneath it. The heading arrow circles around the blue dot as the user rotates.
- Center and Rotate locks the user location to the center, but it also locks the heading to always point up on the screen. When a new heading is reported from the SDK, the map also rotates underneath the blue dot.
Still, when implementing these features, there are other questions to answer. For example, in any of the center modes mentioned above, what should happen when the user manually moves the map around? This question does not have a single correct answer and could be different depending on your use case. However, the best general case in my experience is as follows.
If the user drags the map manually, in any of the center modes, you should change to the None-mode if the drag is distinct. To clarify, if the user only slightly moves the map due to zooming or accidentally touches to map, you should not change the mode to None. But, if the move is distinct, like when the user wants to move the map to look at another location, then you should change the mode to None. Exactly what this threshold value should be is not universal, and the best is to test is on your specific map.
Another case when you should change the mode to None is when the user manually changes floor with the floor-switch-button. This is an active action and you can assume the user do not want to follow the blue dot any more.
Managing multiple floors
Especially floors is an aspect that is kind of unique for indoor maps. Since the user can be on the same latitude and longitude, but on different floors, it is important to use this information correctly as well. When the user changes floor, how should the app behave? This depends on the current state of the centering-button.
For any of the center modes, it’s advisable to automatically change floor whenever the user changes floor. Otherwise, the user might be lost.
For None, the best practice is to not do anything automatically. This because you do not know if the user looks at the blue dot or anything else. However, for the best experience here, there should be some indication that the blue dot is currently on another floor. How you should do this depends deeply on how your map looks like. One example could be to indicate on the floor-switch-button where the blue dot is.
* * *
This was the third part of my blog series A Blue-Dot Experience – some simple tips on how you can make a great blue dot experience on indoor maps. Be sure to check out Part 1 and Part 2, in case you haven’t already.
As always, you can find more details on this topic on our Technical Documentation. If you have any questions at all, don’t hesitate to send me an email.
Tim is a Senior Software Engineer and Front End Specialist at Senion.