Of course my favourite part of the app is the map, however I think it could show more information with better/more advanced visualization techniques. It could be optional (like Apple’s own visual accessibility features in its systems).
The main issue is that looking at just the map the direction of movement is not obvious, so the starting point and ending point isn’t obvious either. This can be an issue when you travel the same route several times a day in different directions, it’s also harder to interpret it later on for editing or just looking back at your day. For example the old Moves app showed more information about the data because of the way the lines were drawn on the map. They had outlines and transparency too so when you had overlapping routes you could still follow which one was earlier and which one happened later, because it had depth to it. You could see one line going under/behind the other line. I guess the Moves app also used bolder and more smoothed out lines because of the less accurate and detailed data. But those lines kind of had a 3D effect to them for depth and showing several overlapping layers of routes. Maybe zooming into the map could be handled differently as well. Right now when you zoom in, you can see the exact location better (because of the map getting bigger but not the lines of the routes), but it’s not easier to tell the direction and chronological order or the actual route itself with overlapping/repeated or same route but different direction ones.
So I think the map could communicate the whole story of the recorded data better with some nice details. Kind of the same details like in the visual interface of a navigation system. With several layers and depth.
(This kind of reminds me of the story about the iOS 6 Apple Maps icon telling users to drive off a bridge near the Apple Campus, which was hilarious and ironic given how bad Apple’s actual map and navigation was back then. But you can get similar misinterpretations about your own routes with the current way of Arc’s visualization on the map.)
For the direction part, the lines could use striped arrow patterns pointing in the direction of movement or some other way of indicating what direction a line is pointing to and from where (similarly to the direction of traffic in streets on city maps or navigation systems).
Another thing that comes to my mind related to this is that it would be cool to be able to see in a heat map or just darker/lighter kind of gradient colouring of the lines on the map the speed or elevation/altitude of the route similarly to workout tracking apps for running and cycling. Maybe you could choose or toggle for the map what aspect of the movement should be visualized on the map and in the way the lines/routes are drawn, colorized, renderred.
Basically you could switch between what dimensions of the recorded data you want to be in focus on the map at that moment. I get the minimalism of the flat lines on the map but since there is so much detail in the recorded data about the nature of the activites, there really should be more tools to visualize the different aspects of them on the map.
Direction is something I’ve long wanted to be able to display on the map, though doing so is non-trivial, for a reason I’ll describe in a sec.
Moves app had one major “advantage”: It recorded orders of magnitude less data. Simply put, Moves didn’t have much data to display. Arc records hundreds or thousands of samples (eg location coordinates in paths), while Moves recorded only tens of samples. So a Moves daily map view might have been showing 100 coordinates in total, while an Arc map view might be showing 10,000 coordinates.
When it comes to putting annotations and overlays on maps on a smartphone, what you can do is constrained by certain memory of CPU/GPU limits. To see a painful example of this, try viewing Arc’s monthly or yearly timeline map views, and see how long it takes to load all of that data onto the map. It’s very slow, because it’s a massive amount of data.
And that’s even after simplifying the data to reduce the coordinate counts. Try zooming into a monthly or yearly timeline map view and you’ll see that the path lines are much more jagged than the daily/weekly map views, due to having so many coordinates removed, to get the map data to fit within memory and CPU/GPU limits.
The map overlays / map path lines that Arc draws are using Mapbox’s built in path line drawing - it’s basically just colour, opacity, width, and coordinates. If instead Arc drew complex custom shapes for every path line (which is what Moves was doing), it would explode the memory and processing costs, even for modern phone models.
Aside: What Moves was doing was not drawing a line, but drawing an entire shape, ie an outline around where the path line would be. So that’s at least double the number of coordinates for each path line, and in practice probably closer to three times as many.
I would love to do more with the map annotations though! High on my todos list is to update Arc to use the latest, new generation Mapbox SDK. I’m hopeful that the new Mapbox version will be better optimised, and maybe also allow for more tricks when drawing path lines. Though I’m not getting my hopes up just yet.
Thanks for the detailed reply, I wasn’t aware of the current technical limitations. I have some ideas to maybe do more with less or rather more with kind of the same.
The app is already doing the chronological order part to some extent (each activity being a separate line on a separate layer the later ones being higher/in front) but it’s hard to tell with overlapping/intersecting lines having the same 100% solid colours. I was hoping that it would be easy to add transparency + borders/outlines and/or drop shadows around/behind them without changing much about the way of drawing the lines and layering. Scrolling back in the timeline already does a bit of this with transparent versus highlighted routes and later ones being invisible, but more could be shown on the map when you look at the whole day.
The direction also could be indicated with adding a start tip and end tip (maybe a specific colouring or some other sign for them) to the line of each separate activity and the same way to the vertical lines in the timeline view. This way you don’t have to change much about the actual activity lines themselves.
For the overlays or showing extra information like speed or elevation on the lines it could use less accurate/smaller portion/more averaged out data as a “cheat” for example for the gradient colouring of the lines. This way you could still have accurate route lines but the colouring using less of the actual extra data to be shown.
Unfortunately drop shadows are very GPU expensive, though transparency isn’t. I did experiment with different levels of opacity to indicate recentness, early on in Arc’s development, but it ended up looking cool but being unintuitive to read, so it wasn’t a good fit for the purpose of indicating recentness.
I would like to experiment with that again at some stage though, because it feels like it should work, so I’d like to try again and see why it didn’t. I think it might’ve been that opacity levels aren’t distinct enough to be easily readable as differences in time, and especially so when the lines might also be different colours.
I was thinking about this last night, and that was my first through too. It’d look cool to have arrow tip / tail details, and that shouldn’t be excessively GPU expensive. But then what happens when you zoom in and beginning/end of the path aren’t visible anymore? Would have to move the direction markers in from the ends, and place them somewhere sensible along the path line within the viewport. That would certainly be doable, but adds complexity to the implementation. Still would be cool to try though.
For colour gradient along path lines, Apple’s Fitness app does this, and it looks cool but ends up not being very readable. So I’m not really sold on it yet. Though it might just be that Apple’s chosen colour palette is too confusing, and would be better off with a simple brightness or saturation gradient instead.
Aside: Here’s an example, in Bikemap app, of a way of showing elevation along a path rather I rather like. You can move your finger along the elevation line at the bottom and it moves the dot on the map to match.
Oh I like the look of those! Those are clearer than the ones I’ve been coding up in my head for the past couple days.
What are the black markers? They’ve done a good job of annotating those paths in a readable way. Nice.
I wonder also what the GPU cost of the line stroke they’re doing would be. Looks like they’re also using Mapbox (OSM branding bottom left). Though they’re probably on the new SDK, which is something I need to set some solid time aside for with Arc. I don’t immediately see stroke settings in the API docs. Hmm. Maybe Komoot is doing it manually by layering a thinner blue path over a thicker white path, which presumably would be more costly than built in line stroke styling.
Just an FYI. I use Komoot a LOT for both trail planning and navigation. I ‘believe’ they use their own map system (don’t mind being corrected), but the trails are very clear and accurate to use.
Their arrows on a there and back route don’t clash, so it’s very clear where to go.
I personally don’t have any immediate application for direction markers but I am curious about the discussion. What happens when you go on the same path several times in a day? There would be arrows in every direction?
Yeah that’s one of the things I’d want to shake out in testing. For routes that you travel back and forth on repeatedly, there’s potential for lots of overlapping lines and arrows, and becoming unreadable. Would have to find an implementation that still comes out more readable rather than less, in those situations.
Yeah, OSM is owned by Mapbox these days, so they’ll be using the Mapbox SDK, same as Arc. Though no doubt they’re using the newer SDK, which I need to update Arc to eventually too.
They might also be using their own custom map style. Arc also uses a custom style by default, made by Arc’s designer, Mladen. It’s designed to have lower contrast, which helps to keep the path lines more readable on busy maps.
My inspiration was the Runtastic app (which is now Adidas Running), the gradient colouring isn’t as precise, also I guess you might need to transform the data in some way in order to show to differences in a more dramatic way visually with the gradient colouring.
Also my use case would be a bit different, the separate window for the extra data is way more precise, but I was thinking about something more casual, that works at a glance without dragging anything and just looking at a the map at different locations looking for interesting patterns at a glance without actually digging myself through the data. After that first at a glance examination I could see myself digging deeper for more details.
So it might not be as detailed, but you can see it all on the map all at once at the specific locations for a more general usage.
Here are some examples from the Runtastic app, it’s used for speed here but I think it could work for elevation too:
My problem with this style of gradient (which presumably Apple copied from Runtastic, or maybe the other way around) is there’s no indication of whether green is fast or red is fast. The only way to know at a glance is to remember the run and remember some portion of it that you definitely ran fast or slow.
I think if I were to implement a gradient style like this in Arc, I would go for a single colour and adjust the saturation to indicate low/high. So the gradient would be from grey to red, for example, with fully saturated red indicating the fastest segments and plain grey indicating the slowest. To my mind that would be much more intuitively readable at a glance.
Runtastic is older than Apple’s Fitness app, I think it had these map features as well before the Fitness app was introduced.
The screenshots do show a legend for the amount of speed indicated by the gradient colouring (although it’s hard to see here, it also states the lowest and highest speeds at the two ends of the scale under the horizontal gradient coloured line).
I think this specific colouring is necessary for maximum contrast and visibility/differentiation between the two ends of the spectrum and it follows the seemingly general consensus of typical speedometer, thermometer designs, topographic elevation maps or other similar gauges and displays/graphs (speed = power = red compared to the relaxing (slow) green colour (sometimes they even use the calmer blue colour before the green one, so I guess typically cooler colour means slower/lower/less, warmer colour means faster/higher/more).
I guess it would be more obvious if it started with blue being the lowest because this way you can mix it up with green meaning +/positive/correct/increase and red meaning -/negative/incorrect/reduce which is of course the opposite of heat maps, with blue - green - (yellow - orange) - red the direction is more obvious. But a legend for it would be useful.
The gradient colouring and the legend might be dynamic based on highest and lowest values here according to the actual current data’s range being shown on the map.
Also a nice attention to detail is the darkened map in the background in order to improve the visibility of the lines without having to change the colours of the lines to something darker reducing the available colour range/spectrum/contrast of the gradient itself.
So potentially the most scientific and functional/utilitarian way to do this kind of gradient colouring for such visualization, although not as aesthetically pleasing or minimalist visually and does require some explanation.
Out of curiosity I did try out a few different configurations with these limitations. I used one layer of narrower activity coloured lines with opacity, and one layer of wider white coloured lines underneath to imitate an outline around the activity coloured lines (however it isn’t ideal because this way the opacity of the two layers are adding up underneath each other). I also added a few black compass/navigation arrows with 50% opacity as kind of a third layer contrasting with the other two to indicate direction.
Here are 11 different versions, mostly in increasing order of complexity (and file size):
#1 Activity coloured lines with 100% opacity (Current, with no arrows or second layer of lines or opacity)
#2 Activity coloured lines with 100% opacity + Added arrows (I didn’t change these, all images show them with 50% opacity and black coloured)
#3 Activity coloured lines with 50% opacity
#4 Activity coloured lines with 75% opacity
#5 Activity coloured lines with 100% opacity + White lines with 100% opacity
#6 Activity coloured lines with 100% opacity + White lines with 50% opacity
#7 Activity coloured lines with 100% opacity + White lines with 75% opacity
#8 Activity coloured lines with 50% opacity + White lines with 75% opacity
#9 Activity coloured lines with 50% opacity + White lines with 50% opacity
#10 Activity coloured lines with 75% opacity + White lines with 75% opacity
#11 Activity coloured lines with 75% opacity + White lines with 50% opacity
So the arrows are the same on all, and changed the opacity of the two layers (where there are two) to 100%, 75%, 50% in different combinations that seemed to make sense. It isn’t obvious how to balance it out, also some of them show more details while being less readable or not having enough contrast.
My first bet would have been #11, however #8 is also interesting (both use a different combination of 75% and 50% opacity for the layers), #11 shows the activity colours better while #8 shows the white outlines and the layering better. Probably 50% or 75% on both layers at the same time (#9 and #10) would either hide too many details or not have enough contrast. #6 might be interesting as well if you don’t want to see what’s going on behind the activity coloured lines and it still shows more details than #5 and #7. As for only having one layer but with opacity in this case (#3 and #4) it does show more details but it can be confusing and without noticing which colour shows more above the other colour, it’s hard to tell which layer/line is more recent/higher, and you need two different colours for that in the intersections.
The arrows are unicode characters that could be written on the map as a text:
➤
BLACK RIGHTWARDS ARROWHEAD
Unicode: U+27A4, UTF-8: E2 9E A4
(Arial Unicode MS font variation)
I guess these are more fitting for this usage because of the narrower shape, being filled in and only having the arrowhead.
As for the placement of the arrows, there are clever ways to place them or to use the smallest number of them in the most effective way, for example in the middle of mostly straight paths divided by taking turns or changing direction. Or placing every arrow after a certain travel distance or travel time (this way it would kind of indicate speed as well). Also arrows at the start and end of the paths could have a different colouring or gradient colouring, outlines, etc. from the rest of the arrows indicating the start and end of the activity.
And I disagree with almost all of them By my measure, they’re almost universally terrible.
Leaving aside the issues of red/green colour blindness and culturally different meanings for red and green, a multi step gradient is always going to be more challenging for the mind to interpret than a two step gradient. That extra cognitive burden has to pay for itself by providing extra information, otherwise it can’t be justified.
I think the only viable exceptions are when there is more than one ontological category represented in the gradient, for example below sea level / sea level / above sea level; below freezing / freezing point / above freezing; low pressure (rain) / high pressure (dry). (Though that last one is still better represented with a two step gradient, to show a spectrum from no rain to lots of rain).
For a spectrum of speed, I can’t see any justification for going to multi step gradient. You can’t go slower than zero - there are only positive numbers. It’s one ontological category: speed. You go from no speed to high speed.
I could see an argument for claiming multiple ontological categories if gradient steps were bounded to the crossover speed points between walking and running and running and sprinting, but I doubt that’s what either Apple Workout app or Runtastic are doing, and even if they were I still don’t think it would justify the extra cognitive load and decreased readability. That’s better represented by discrete steps, as Arc already does with solid green for walking and solid orange for running. (Aside: I’ve long wanted to add another activity type and colour for sprinting, because the activity types classifier absolutely can detect sprinting as a separate activity).
Data visualisation is difficult to do well, and Arc doesn’t do some of it as well as it should, but I do try to stick to one basic rule as often as I can: Only show the data you’re trying to communicate and nothing more. Anything extra you add should only be there because it increases understanding and readability of the intended data. Beyond that point, all you end up doing is increasing the cognitive load and reducing readability and understandability.
If your visualisation needs a key, you have to step back and question whether there’s a better way to display it that wouldn’t need a key. Maybe the key is ultimately unavoidable, but you still have to step back and think it through, to make sure you’re not unnecessarily complicating the visualisation, adding more but communicating less.
By my measure, they’re almost universally terrible.