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.
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"???!!
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."
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?
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.
There's a strong belief running through the Apple developer community that having a setting means you didn't think hard enough about the defaults. There is some wisdom in that idea but sometimes people take it way too far.
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.
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.
I'd put this bug here - on iPhone 6S opening camera stops music. Presumably something to do with Live Photos which are disabled. They also did some fix in iOS 9.2 - leaving camera now resumes music.
See also: automated bathroom fixtures. What if I want to fill up a glass, rinse something off, or get more than one hand towel? Why have the designs of these not significantly improved in 10+ years?
"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".
I once got a call from them on an bug I encountered with an Airport Base Station. They had me load a testing firmware on to try to reproduce the bug. I've also had a couple of bugs replied to (usually asking for more information), but these were when I was playing more with beta software.
I have. I sent in a report saying that the Safari address bar autocomplete menu doesn't exit when you drag the favicon or link to another app, ultimately rendering Safari inaccessible unless you use your mouse and they asked me for a video example. I posted the video, but I haven't heard anything since. However, it is fixed now, so there is that
Yes, I've gotten requests for follow up questions, links to other bugs that mine was a duplicate of, and indications of when a particular bug would be fixed. In one case I was "doing it wrong" and I got a pointer on how to do it right.
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.
It absolutely is a bug! The app has decided that you're driving a car, which is false: you aren't. Because of this falsehood, it is reporting a different location from where you actually are, through no fault of GPS.
It could be that the requirements specification for the program requires these falsehoods. In that case, the specification has a bug.
(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?
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.
Tough to say in the general case, but it's often a good idea to adhere to the so-called "principle of least surprise" in UX design. If I'm riding on a trail that periodically approaches and diverges from a nearby highway, which is common around here (Seattle area), I don't want my recorded path to snap to the highway every time I exceed 12 MPH. That would come as a surprise -- an unpleasant one. I'll go so far as to say that nobody would ever expect this to happen, or be dismayed if it didn't.
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.
> then you'd have a Settings app that has thousands of options
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.
On Firefox, about:config is a great feature: if you know what you're doing, you can tweak any setting that's tweakable.
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.
> 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.
One or two sentences of description per variable/valid option would go a long way as well.
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.
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.
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...
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.
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.
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.
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.)
It could save on battery power: If the user has been on the road, we can ping the GPS less often on the assumption they'll be mostly moving along one of a set of known paths.
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.
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.
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.
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?
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.
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...)
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.