Dueling Y-Axes

An interesting reading about fanciness and pointlessness of displaying data.

The team at OmniGraphSketcher wrote about the display of multiple y-scales overlaid on the same graph, to make it possible to plot several different types of related data on the same chart. I do this too in TrailRunner but my solution targets the middle of what they call a bad idea and what they suggest as a realistic solution.

The main conclusion of the OmniGraphSketcher team is that overlaying data with disparate scales saves space, but it makes the data significantly harder to interpret. The dual axes “duel” for your attention. So instead of overlaying scales, [they] recommend using a set of multiple graphs, aligned along their common axis.

> Omnimouth blogpost
> Read their Article

Tracks, Trails, Routes, Workouts, Laps, Courses, WTF

„TrailRunner is powerful but at the same time can be confusing for first time users.”
This is what I hear from many users. The typical learning curve goes from prejudices on how things should work to misunderstandings on what is actually going on to understanding and loving TrailRunner or bailing out for something else.

This all rotates around the difference between a track, workout, diary entry, route and the network of tracks.
And to be honest, I know this problem and I am constantly trying to make things easier to understand.
In fact TrailRunner is three applications in one. TrailRunner is
- an activity journal
- a mapping application to maintain a network of tracks
- a route planning application

So whenever you import something into TrailRunner, your intentions might go into either direction. And interestingly this even shifts over time — as new users with new devices stumble upon TrailRunner.

Probably the following "glossary" might help understanding what TrailRunner is about and what the application can do for you — whenever you drop data into it:

A track is a list of geographic points with GPS coordinates. Within the real world a track describes the path from e.g. one sign-post of a hiking trail to the next. Each sign-post representing a crossing that connects to other tracks. Within the context of such a way or street, a track contains no timing or heartrate information. It's only where, not when and how.

Network of Tracks
One big feature in TrailRunner is to build and maintain a network of tracks. That is much like the lines of streets, roads, ways, trails and pathes printed on maps. The difference is that your network of tracks is your personal collection. A collection that represents the paths you actually run or cycle on, masking everything else out that you dislike or haven't strolled along yet.

Within this network of tracks you have routes. A route is more or less a sequence of tracks. One important thing is that within a route, if you go back and forth a track, this track is part of the route twice. This is the most problematic part as simple GPS recordings never have this kind of conceptual differentiation. So I reject the idea that a route and a track should be the same thing. They could appear as — in the degenerate case where a route is being made of one track being used only once within the route. But that is just a special case — although typical in activity tracking applications that just import GPS data points and visualize them.

The biggest similarity between what others call a track is what I call in TrailRunner a workout. Garmin calls this an activity but I dislike this term as it fits better to being a diary entry. But back to the difference between tracks and workouts: If a recording contains data points with values like heart-rate, cadence and calories, it's not a track. It's a sequence of training session data-points and therefore it is a workout. For this reason TrailRunner generally distinguishes between routes and workouts. Routes belong to geographic data, workouts belong to performance over time or distance. A workout and a route can be connected to each other if they follow the same geographic course, but must not.
TrailRunner even offers features to merge a workout with the course of a route. That's important for training devices that can track distances but not GPS locations (e.g. the Apple Nike+ iPod Sensor)

Summary: The different faces of a track
To sum this all up, a track can have the following faces:
If the track contains a series of geographic points without timing information, then it's a track within your network of tracks.
If the track contains additional timing information, then it's the course of a route containing the single track or a sequence of tracks.
If the track contains timing information and values like heartrate, cadence etc., then it's a workout.

Import of a track
Whenever you import a track into TrailRunner, the importer shows you the course of the track in the map part of the main window. Then in the lower part of the importer you can decide if the workout face of the track should be attached to a new diary entry.
Then below that you have options to add a route to your list of routes that is based on the course face of the track. If you choose the option to import as one piece then one long track is added to your network of tracks along with a new route that contains this single track as it's course. If you choose any of the other options, TrailRunner will merge the track into the network of tracks, splitting the track into smaller tracks and joining all similar sub-tracks with existing tracks. One important fact now is that the resulting route will be made of a sequence of tracks that describe the almost identical course as the original recording but complementing your network of tracks.

But most importand of all is: your imported track can go a split way. If you choose the diary and the merge way, you actually have two items deriving from one source but being independent after the import:
- The workout became an immutable one-time recording being stored in the diary.
- The route and your extensions to your network of tracks are mutable.
On tracks you can apply operations like move, split and join affecting the routes that use these within their sequence.
On routes you can change the sequence of tracks they should follow during their course.
But in the end you can create and modify routes to match your plans and use an exported course as a basis for your orientation — while taking your gear out and burning some calories. What you then record can be imported as a new workout into TrailRunner.

To complement this all, a map within TrailRunner is just pixels. A background image you see beneath your network of tracks and a hint for your orientation and manual creation of new tracks. The lines drawn on a map are not part of your network of tracks unless you add them by re-drawing them using the track-tool or by adding GPS recordings that followed the same geographic course of the "line".
The only difference comes with openStreetMap. The openStreetMap map source is a pixel representation of the openStreetMap track network. For this reason it is recommended that when you are using openStreetMap for routing (streets tab) you should also use the openStreetMap map source as your backound maps. As both then perfectly match.

Further Reading
After reading the above, please revisit the following tutorials.
> About TrailRunner feature slide-show
> Import and Edit Tracks Tutorial
> Mastering Track Merge Tutorial

If you still have questions, remarks or suggestions — I do listen! Just write me. Either here, in the forum, on twitter or classic email.

Help !!

This time I'd like to place a call into the TrailRunner community. A call for your help.
In the past, TrailRunner became more and more feature rich, not yet over-loaded but pretty complex. And TrailRunner has conceptual limitations by it's nature of being freeware using free services and a single person background (me).
My development cycle goes from answering support emails, fixing bugs, developing new features, documenting features and back again.
As you might have noticed I tend to develop features with the highest request rate first. But this ignores a great number users: The first time users. And to make TrailRunner bigger and better, we need helping them to get onto the trail. And that's what I am asking your help for.

Currently I have set up three tutorials, one for each technical target group. But when Steve Jobs explained us all in his keynote that the Amazon Kindle will fail due to the fact that no-one is reading anymore, he was quite right. Written tutorials are good for those that take the time but nothing for a first time user. They want video tutorials. But video tutorials are double the work, or even more.

Many software packages try to solve the learning curve problem by providing assistance like tip of the day, warning messages with the obligatory "don't show this anymore" checkbox and the glorious MS Office paper-clip assistant. I already have added warning messages on key usage trails but that's far from being perfect. I started on a tip of the day system but haven't completed this yet.

In the age of internet it looks like every software package is required to have a forum. But at least after a month you need a forum administrator — and that's me. So I ignore the whole forum demand and keep focused on my feedback mails, unless I would know there would be valuable and useful support content growing in the forum content, without my intervention being required.

All in all, my questioning is, who would like to help me out by:
Extending, refining and completing Tutorials, possibly by creating a video Tutorial.
Giving me pointers on where first time users (like you once where too) would get stuck in the application and what tips of a day would help to get further.
Making suggestions on forum topics that might help new users to get valuable information that is generated by other users, and not moderated by myself.

If you have the time and ability, please drop me a line. Didn't you not always want to use iMovie and didn't know what for… Here you go (maybe).