
More Details on the Insidious iOS Snap-To-Road “Feature” - lawnchair_larry
http://regex.info/blog/2016-01-19/2666
======
TrevorJ
Apple seems to suffer from the cargo cult of simplicity.

They seem to view UI simplicity as the goal instead of viewing it as the end
result of elegant design choices. Simplicity for the user is something you
earn by making good design choices, it's the end of a long arduous process. If
you shortcut that, you don't actually end up with something that is simple to
use. You end up with something that looks easy to use but is actually very
hard to use.

By failing to arrive at clean interfaces the hard way, they make their tools
frustratingly inconsistent and difficult to use. Functionality is abstracted
away from the user, but there is no consistent process by which the user can
predict how to access these functions from program to program, or across the
product line.

~~~
adajos
I am an Apple fan and iOS developer, but I completely agree.

~~~
fishanz
Likewise, and Steve is just rolling in his grave. Apple used to be so
meticulous about UI. Directly unrelated to the road snapping, but a shining
example of this inconsistency: I open up the App Store, and tap on the
'hamburger' to get ... "Wish list"???!!

~~~
TrevorJ
I have a theory that big, product driven companies benefit from having
somebody up top who just keeps saying "No, it's not good enough, find a way to
make it better."

------
tmaier
This could be also the reason or at least be connected to a behavior I
experienced when using Apple Maps on the iPhone:

Apple Maps lacks support for bicycles, so when I cycle I usually use the
pedestrian mode, as this fits closer to the tracks and routes available for
bicycle drivers than the car mode.

But when you cycle to fast, Maps thinks you changed over to a car and tells
you to turn around, as the current route does not fit for cars... How common
is it see a bicycle in 1 Infinite Loop?

~~~
wwweston
There has to be an entire category of UX problems like this, even with Apple
products (maybe _especially_ with Apple products), where some well-meaning set
of product owners decides they're going to automatically detect something that
might normally be a user input (like mode of travel), and then it turns out
their heuristics for detection weren't thought through carefully enough and
run afoul of a use case they didn't account for.

~~~
jimminy
Actually had this happen the other day on Facebook.

Unfollowed a friend due to some strain on the relationship, and just needed to
avoid them temporarily and didn't want to see anything from them. They shared
some of my content, which placed them in my notifications.

Notifications can only be marked read, not deleted, so it was somewhat
stressful. it's a very minor use-case, but there is no remedy but to get other
interactions to force the notification out of sight.

~~~
underwater
Facebook offers tools that are more fine grained than unfriending. You can
block someone, unfollow them so they don't appear in your feed, or turn off
notifications for the piece of content they shared.

Exposing more controls is always a balancing act. From a user experience
perspective it can add complexity to the product, this can make it feel more
confusing. The privacy setting, for example is very powerful but the UI is
built so that most complexity is hidden until you need it. There is also
engineering debt. Once a feature is added it is very hard to remove. A setting
like hiding notifications on a per-user basis would have to stay in the
codebase for all time, even if Facebook decided to stop showing the UI to new
users.

------
protomyth
"As expected, I've not heard any reply from Apple on the bug report I
submitted."

Does anyone ever get a reply on any bug submitted to Apple? With one
exception, I get the someone else reported it or it stays open with no
comments from Apple.

I have only one bug they ever put the need more information generic text and
that has no followup since I followed their instructions, not even a "you did
it correctly, thanks".

~~~
Bud
This isn't even a bug. It doesn't behave the way this user would prefer and
the feature is not as refined as it could be. Neither of these things is a
bug.

~~~
CamperBob2
(Shrug) It's a terrible idea to add a feature like this without giving the
user a way to turn it off. Who in the world would _prefer_ it to work this
way?

~~~
eli
You could say that about every tiny feature and then you'd have a Settings app
that has thousands of options. Most people don't want that and, I think, would
prefer the device to do its best to guess at the correct setting even if it
gets it wrong sometimes.

~~~
DonHopkins
You should be able to talk with Siri about your thousands of options and
correct its thousands of guesses.

"Siri, why do you think I'm walking in the middle of the road?"

"Oh, I'm sorry -- you're not driving a car? Would you like me to stop snapping
your position into the middle of the road, then?"

~~~
dzhiurgis
Too Googley

------
fallous
My response to a lot of this behavior among a number of products/vendors is
"stop helping me." The presumption that users are idiots and cannot be trusted
with control over behaviors or settings is a constant source of irritation.

If you insist on injecting yourself into the user's workflow because you
believe you know better, then either your solution is flawed and needs this
interference or your arrogance is showing and you think you know better than
the user what they want. Both of these are evidence that you shouldn't be
designing things.

~~~
userbinator
_or your arrogance is showing and you think you know better than the user what
they want_

IMHO that's what Apple has mostly been about: telling users what they want.
Their success shows that it may not be a bad business strategy, but it's
definitely not for everyone. I definitely notice there's a culture of
conformity around Apple, which is especially ironic considering some of its
early ads and the slogan "Think Different" \--- "Don't Think" might be a
better fit for today's Apple.

------
maxerickson
Apparently Strava has complained about it:

[http://ilquest.com/2012/11/02/ios-6-is-unusable-for-
people-r...](http://ilquest.com/2012/11/02/ios-6-is-unusable-for-people-
relying-on-accurate-gps-tracks/)

(That blog isn't Strava, but it quotes a Strava customer service person
discussing contact with Apple)

I guess if Apple doesn't change the feature when requested by activity tracker
companies they aren't going to change the feature.

~~~
beejamin
That's somewhat ironic, considering Strava does their own form of 'snap-to-
track' normalisation on GPS data. They have to, in order to do leaderboards on
segments, at a guess, but still...

~~~
ygra
At least they snap to what usually are cycling tracks and are not trying to
put you on the motorway ...

Also, as far as I know, they only do that to determine the segments, they
won't change the actual data of the track.

------
stepanhruda
Sounds like this is a configuration issue. There should be two sets of data
available, both of them are valuable.

~~~
beejamin
Except if it's an optimisation for battery life. Theoretically, you could use
less power by pinging the GPS less often in 'snap to road' mode - if that's
the case, the 'real' data wouldn't exist or wouldn't be accurate.

------
HappyTypist
I think this feature is ridiculously poorly thought out. Why would you ever
want to destroy / reduce the entropy of data? Apps can snap to the nearest
road themselves.

~~~
Bud
How well did you really think this out? It only took me a couple seconds to
figure out a reason why this feature would be beneficial: it could be more
accurate in many circumstances.

~~~
mikeash
And it could be less accurate in many other circumstances. That's why you
provide the original data and maybe _also_ the snapped data, and don't just
make the original inaccessible. (And worse, tell no one you're screwing with
the data you're giving them.)

------
userbinator
_internally Apple calls it “Map Matching”; I call it “Snap to Road”._

I've noticed that Apple tends to give things vague-sounding names, and it's
probably not by accident. I mean if my GPS had an option named "Snap to Road",
I'd immediately understand its function. If it was called "Map Matching", I
would be a bit perplexed.

To me, this feature seems like a horrible workaround for poor GPS accuracy,
and doing it at the API level is just wrong. If an app reads coordinates from
the GPS it should get the most accurate location possible (some concession
could be made for pseudo-anonymising randomisation as a security/privacy
option). If they feel the need to do some sort of "smoothing" on the data,
then it must be an opt-in option, not obligatory.

~~~
danpat
"Map matching" is the term used in most literature for this function.

[https://en.wikipedia.org/wiki/Map_matching](https://en.wikipedia.org/wiki/Map_matching)

~~~
userbinator
Unfortunately it is not very descriptive, nor the term most GPS units use. The
question that comes to mind when I see the phrase is "match a map with
_what_?" Even the article you linked to begins with a pretty opaque sentence:

 _Map matching is the problem of how to match recorded geographic coordinates
to a logical model of the real world, typically using some form of Geographic
Information System._

That sounds like something far more general than "snap to road", which is what
this feature is doing; nothing more or less.

------
adajos
Seems like this should be easily fixable by making it the app developer's
decision via CoreLocation.

If the app developer in turn wants to allow the user to modify that setting,
then more power too them.

~~~
majormajor
Seems like it is the developer's location, with the following note from the
bottom of the link:

"(However, there's still the caveat that if any app triggers “Snap to Road”,
all apps get “Snap to Road”.)"

which seems to be a poor implementation decision vs providing apps snapped or
unsnapped location data based on their setting, but may be the result of some
early-on ill-considered internal designs?

~~~
comex
An indirect and undocumented decision, apparently, based on this somewhat
confusing list of "activity types":

[https://developer.apple.com/library/ios/documentation/CoreLo...](https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManager_Class/index.html#//apple_ref/c/tdef/CLActivityType)

------
ino
I've noticed this yesterday in a flight just before landing and I found it
funny how the airplane was following the roads each for a few seconds before
snapping of.

I also confirm it snaps on both google maps and apple maps with airplane mode
turned on, most probably due to caching.

I've also found it amazing that the iPhone 6S held the cache of a map 3000km
away after 3 days abroad, with intermittent wifi and lots of google maps and
safari use.

------
kazinator
> _iOS seems to require Internet access (or cached map data) for [snap to
> road] to work._

???

If you have no network and no cached map data, what road is there to snap to?

------
zimpenfish
> I'm a geek about my data

I'd expect someone that concerned about their GPS tracks to be using a
dedicated GPS device (Garmin, Polar, Suunto, etc.) rather than an iPhone -
they're just not reliably up to the job regardless of road-snapping (which
I've never triggered when walking...)

