Apple really goes out of their way to tell developers that they can be penalized for circumventing their restrictions, but if both developers and end users want to circumvent the restrictions you really have to wonder as a company if you are on the right path.
The bad press that Apple has gotten because of stuff like this in the last year is really starting to add up, and I think this is one of the best examples to date of why such control is wrong.
Strictly speaking this is not an 'easter egg' but a user interface policy violation, presenting it as an easter egg including a very difficult activation sequence should prove beyond doubt to Apple that these users are going to be perfectly happy with their volume control not working in the Apple dictated way. It is their volume control button after all (the users', not Apples).
if both developers and end users want to circumvent the restrictions you really have to wonder as a company if you are on the right path
And most people do wonder, and then they cave. Which explains the dynamic that drives 90% of the designs out there:
CUSTOMER: "I want to be able to receive email from inside my blog."
DEVELOPER: "No, really, you don't. Email is a complex beast. It will make your blog software much bigger and more complicated and fragile. You will spend a lot more to develop it and a lot more to maintain it. It will be hard to design in such a way that it's easy to learn and understand. And you may think you need it, but you don't."
[five minutes pass]
CUSTOMER: "The most important missing feature is: I want to be able to receive email from inside my blog."
DEVELOPER: "We talked about that five minutes ago. It is a really bad idea!"
[iterate fifty times]
CUSTOMER: "I want to be able to receive email from inside my blog."
DEVELOPER: "Okay! Okay! I want that, too, so that I can charge you money to implement it instead of fending off the request every five seconds."
[two months later]
CUSTOMER: "Why is my blog software so difficult for my new employees to learn, and why is it so complicated, and why does it cost so much to maintain?"
DEVELOPER: [stabs self with pen]
---
Design integrity is hard. Hard on everyone. Maybe that's why so few products have it.
Yes, but in this case the feature was dead simple, developers and users were on the same page but the vendor of the hardware (and the distributor of the software) nixed it.
Your example sounds like things I've been through multiple times, the best way we ever improved software was by leaving infrequently used features out. At some point we had blue-screening and stereo images in the webcam software, I don't think anybody ever used those except us for a demo of how cool the software was.
It made it quite difficult to get people back to 'normal' after a round of random clicking on settings to see what they do.
This sort of frustration is not just limited to the software world, in industrial design similar things happen.
Good design is usually tied to someone that knew as much or more about removing stuff than it is about adding stuff.
Personally I'm a big fan of the old 'Braun' designs. Someone ought to start using that sort of design for websites.
They do, it's called vitsoe.com. The thing is, the feature isn't dead simple. Implementing it would completely break a solid rule of the HIG of the iPhone. The quality of the UX on the iPhone exists because of those rules, just because something may seem like a good idea doesn't mean it is. Allow this and they're not volume buttons anymore, they're just general purpose buttons whose action is context specific.
I'd like to reduce the volume of my music but I'm in the NYTimes app so that will favorite the article instead.
> The thing is, the feature isn't dead simple. Implementing it would
> completely break a solid rule of the HIG of the iPhone. The
> quality of the UX on the iPhone exists because of those rules
I'm sorry, but if the HIG is Apple's 'ten commandments,' then they are guilty of multiple mortal sins. I can't comment much on the iPhone, but Apple has consistently (since the inception of OSX at least) broken their own HIG in their own applications. If Apple can't even play by their own rules, then why should everyone else?
It doesn't matter if it's something you enable explicitly, you're thinking about this the wrong way. Even if you enable it explicitly you have now compromised the uniformity of the utility of those buttons. There is now a cognitive cost of working out what that button is going to do every time you press it that didn't exist before, your quality of experience suffers. It's saving you from yourself.
Now you probably think that sounds anal retentive and patronising in equal measure but that's how you make good UX across a platform - by understanding the power of consistency to reduce the cognitive load of an interface.
Don't like it? You're welcome to go buy some random Android device with a random amount of buttons and widgets and d-pads and track balls that take a photos in this app and ring your grandmother when shaken to the left in the other app.
Personally however I'm glad this stuff is enforced. Sure, if it wasn't I could avoid apps that broke HIG, market forces and all that crap but that gets hard. I then have to try and find alternatives or put up with not having access to some functionality.
why does that only apply to physical buttons? The thing about the iPhone (and Android for the record) is that there are rather few interface commonalities between apps. It seems that everyone is designing their own widgets, styles, and creating vastly different affordances. The apps are all very flashy, but user interaction can vary pretty significantly from app-to-app.
I don't think that's necessarily a terrible thing. But why is that ok for the software (which is the bulk of the interface) and not the hardware?
So what happens six months after Apple greenlights a hypothetical "easter eggs can bypass stated rules" policy?
Do we see app instructions listing urls of unlocks right in iTunes? Is that a good place to be, with just about every new/updated app having an obtuse post-install 'enabling' process to achieve advertised features? (advertised, if not in iTunes, certainly by every review or word-of-mouth referral)
That doesn't sound like a remotely desirable situation to me. If a particular edge of policy is dumb, we should argue for it to be changed. Or flat-out argue for the removal of review.
Arguing for Easter Egg Bypass sounds like defeated bargaining.
I don't see how your link is not relevant, first of all.
(edit: eg, you could post links to lots of Flash, Java, whatever that run on OSX but aren't allowed in the App Store)
Also, I don't see how "developers and end users wanting it" changes anything, Apple is clearly not interested in letting developers and end users dictate how they operate, otherwise they would have been doing things differently from day one, and most obviously there would be Flash on the iPhone.
I think the point of his link was to show that OSX contains easter eggs, implying that Apple is being hypocritical by including easter eggs in their own software while rejecting iPhone applications that include them.
But this reasoning is flawed: Apple allows easter eggs in iPhone applications provided that the hidden behavior is revealed at review time. And running tetris in OSX's emacs is not an easter egg; tetris is a documented feature of emacs: http://www.gnu.org/software/emacs/tour/
What's good for the goose...
Apple really goes out of their way to tell developers that they can be penalized for circumventing their restrictions, but if both developers and end users want to circumvent the restrictions you really have to wonder as a company if you are on the right path.
The bad press that Apple has gotten because of stuff like this in the last year is really starting to add up, and I think this is one of the best examples to date of why such control is wrong.
Strictly speaking this is not an 'easter egg' but a user interface policy violation, presenting it as an easter egg including a very difficult activation sequence should prove beyond doubt to Apple that these users are going to be perfectly happy with their volume control not working in the Apple dictated way. It is their volume control button after all (the users', not Apples).