radek

We will be adding this in the next update.

The larger elevation on the trail is still there. This was always below all the trail data so you have to scrill down on the trail page.

@xyrion: We don't do anything nefarious and only build features and use data that is required for the app features. But, I do want to understand your point of view so here is a couple of questions. The tracker app test you pointed to just scans the app for the existence of a code library. Say in the case of fb. Yes there is a lib that will be used to do the fb login, but only when you actually decide to use that feature. If you never do a fb login, there is never any kind of call made to fb. How do you envision us making it work for someone like yourself, but yet still have the ability to provide a feature for those who choose to use fb login?

@brentkratz: Not yet, but it will be soon.

@xyrion: From this article sounds like one should use an iphone instead of an android phone "For comparison’s sake, a similar experiment found that on an iOS device with Safari but not Chrome, Google could not collect any appreciable data unless a user was interacting with the device.". We are going to double check, but our app only interacts with fb when you decide to use "login with fb". If you don't use that feature then there is no interaction with fb at all. And if you do it only interacts one time on the login screen to do the login verification.

If a trail is just gentle green with hardly any grade we think there is no need to amplify this visually to the user. The reason why we think that the fully shaded graph without direction bars is less ideal is that you are forced to relate the color to the sometimes minor, compressed, or hard to see elevation changes in the profile graph to figure out if the grade is related to uphill or downhill. Also with colors and bars we have more resolution in that not only can we represent a grade with a few shades of color, but also with the size of bar and the direction of the bar. We can convey more information/data to the user. The trail direction and therefore the elevation profile on trailforks is from green circle to red square. This trail direction is computed from millions of trail ride logs and recommended to be set that way to the associations. So a trail is made a particular direction because say 80% of the riders ride it that way. Of course you may ride it the other way and the default elevation profile and the grade will be backwards but I think people already intuitively compute that in their head. If the slope shown is downhill from left to right, but if im riding backwards, then i'm actually going uphill. We might even make this easier by having a button to toggle the direction and therefore switch the elevation profile and grade graphs for the user.

@Levelheadsteve: Maybe because riding a trail is not very instant?

It's already in the app ;) . Shhhhhhh! We are just not happy with it yet to enable it to the public.

The items that show up as trackers are google analytics/crashlytics which is used to figure out what happens when app crashes and the Facebook plugin that if you do choose to login it gives the option to login to the app via fb.

It works fine on 12.1.x but iOS 12.2 is the beta that is not production yet. Have not tested things with the upcoming ios beta but we will look at it and make changes to fix any issues. Thanks for the heads up.