>Augustin Farrugia testified that Apple did not offer a more detailed explanation because, “We don’t need to give users too much information,” and “We don’t want to confuse users.”
A very revealing statement about the way Apple perceives its users. Shut up, pay, and don't ask questions.
As somebody who has had to do tech support, I fully understand the desire to provide the users with less information. Believe me, most of them confuse easily.
As someone who has also had to do tech support, I have hated Apple for this ever since, because it limits the user's ability to provide me with any information. 'An error has occurred.' Thanks Apple, real informative.
I always admired the technology and integration in Apple gear, but since the days of MacOS system software I have always hated the dumbed-down, hard-to-customize operating system, and have never purchased an Apple product. I'm going to have to pick up an iPad at some point because there are so many good apps aimed at Musicians, and I respect the fact that OS X is basically BSD in gift wrap so I can get to a command line if I really want to know what's going on. But I don't feel that enthusiastic about it, because I think there's something fundamentally user-hostile about obfuscating what's going on behind the curtain.
As a software developer and ex-linux user (it's still crap on the desktop) it's quite clear Apple have segmented their user base. Out of the box it's quite simple, but get a (free) developer account and install Xcode and you have the full power of the BSD system right there, but with a windowing system that doesn't crap out when you plug in a new monitor.
Unfortunately it is rather opinionated and you do have to do things 'the mac way', but if you live in a Terminal having copy on a different key to interrupt is amazingly useful. Also having windows auto-restore when plugging in an external monitor, I only just learnt that Windows doesn't do this.
As for errors, almost everything is logged in some way, but again it's hidden from regular users.
Also, a lot of users don't give a shit about how something happens (all the gritty details). They just want to understand what is happening.
Most of the time this is because they have better things to do.
When it comes to documentation: if the implementation details are not important to the user, you should skip them. Words on a page that a user reads but doesn't care about is wasting their time and they could be reading about other important details.
If you have a broad user base who largely don't care about implementation details you're better hiding them from everyone rather than showing them to everyone.
The flip side of that is being completely opaque, and pushing all responsibility on the user. E.g. ISPs terminating large, encrypted file transfers and then playing dumb when a user tries to call them on it, "it must be a problem on your end.'
> What are the chances that the person you spoke to had any knowledge of the action you are talking about?
Little to none, but this is by design. If they had made such a decision, tracing it to them is difficult. Easier to tell the phone reps nothing and push the blame onto either end of the transfer rather than on the path in-between. How many people will pursue this past just venting about it on the Internet?
> For that matter, how do you KNOW that the ISP did indeed terminate your large encrypted file transfer?
If it's a single transfer, then you really can't. That said, you can establish a pattern. For example, if your connections always terminate around the 20-minute mark and this happens regardless of the other end of the connection (or the network path to that end-point), you could make a compelling case that it's the ISP's fault at the very least.
I find Apple highly culpable for many things, but I won't fault them for defining their public interface their way. At some point private implementation details are just that.
A very revealing statement about the way Apple perceives its users. Shut up, pay, and don't ask questions.