More Details on the Insidious iOS Snap-To-Road “Feature”
regex.info
regex.info
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.
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?
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.
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.
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".
That's a good reason not to include a given feature, or at least to allow it to be turned off. Someone at Apple obviously thought it was a good idea, but they clearly didn't ask very many other people, or ask any cyclists at all.
However, some people would actually like that, me for instance. On Firefox, about:config is a great feature: if you know what you're doing, you can tweak any setting that's tweakable.
> prefer the device to do its best to guess at the correct setting
This is actually the worst of both worlds. From a UX perspective, I can understand having multiple behaviors with a setting, and I can also understand having a single behavior with no setting. However, I can't agree with having multiple behaviors that change opaquely at the whim of the machine (like in this case), which is just frustrating.
At the very least, Apple should have surfaced a setting to developers to control this and made it opt-in.
That said, I do wish they'd make it a bit more organised than a long list of tersely named options; perhaps a tree view like many other apps' settings use.
The idea of providing good defaults, and that of providing rich configuration options, are not necessarily opposites.
One or two sentences of description per variable/valid option would go a long way as well.
"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?"
It could be that the requirements specification for the program requires these falsehoods. In that case, the specification has a bug.
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.
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.
http://ilquest.com/2012/11/02/ios-6-is-unusable-for-people-r...
(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.
Also, as far as I know, they only do that to determine the segments, they won't change the actual data of the track.
It could compensate for poor GPS availability, by allowing the track generator to make more informed guesses about where the user has been, if a GPS ping happens to get dropped.
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.
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.
If the app developer in turn wants to allow the user to modify that setting, then more power too them.
"(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?
https://developer.apple.com/library/ios/documentation/CoreLo...
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.
???
If you have no network and no cached map data, what road is there to snap to?
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...)