The enemy here is an abuse of skeuomorphic[1] design principles. The Reason and iBook examples are the most blatant abuses of this technique.
Buttons are a good example of skeuomorphic done right. In real life, if something's supposed to be turned, I expect it to be a knob. If something's going to be pulled, I expect there to be a handle. Since you're expected to click or tap buttons, it they should obviously look like buttons.
I think that Apple's decision to continue buttonizing touch UI was probably wise in the beginning, but seeing Windows Phone 7's all flat everything approach feels really fresh. Why don't they chrome up their touchable objects? Because its a _touch screen_ and the only thing you can POSSIBLY do is _touch_ them. The context is I took out my device to do something with it, I expect to be touching things.
So while buttons may still need to be buttons on the desktop, I'm happy to see chrome fade away in touch UIs.
But not everything is a button. Designers need to be extra careful when displaying non-interactive fields on the same page as buttons if they are going to remove UI chrome.
Twitter for Android is an example of how nonintuitive a flat interface can be. When viewing user profiles, you are presented with a list of information (name, bio, tweets, lists, etc). Clicking Name or Bio does nothing, but they are the first items listed and look exactly the same as every other item. (Actually, clicking them causes the item to highlight as if you were clicking a button, but there is not any associated action, so nothing happens.) When looking to see a user's tweets, it always takes a moment to remember that "Oh right, some of these words are interactive."
The Settings menu in Android attempts to solve this by greying out fields which do nothing (e.g., the Model field in About Phone). It works there, but the same technique could fail if your app also has potentially disabled buttons or important static information that shouldn't be grayed out.
Reason is fantastic. It's actually a fantastically intuitive interface for its target market, and what's more, it's psychologically effective.
The skeumorphism in Reason is so over-the-top – there's a physics engine in there! - that it gets you in the right mindset: it's playful, it doesn't take itself seriously, and that's exactly what you need to get making music. It's exactly the opposite of WriteRoom because it's serving a very different mindset.
I use Reason every day, and while I assure that its design was somewhat appealing at first, the sheer insanity of having to deal with virtual instruments and sequencers as if they were the "real thing" grows tiring extremely quickly.
Even during my education, wherein I dealt with more than a few individuals in Reason's "target market" (see: aging film composers who have spent their fair share of time plugging real cables into real sequencers) found it appalling and difficult to use.
The only reason I still use the program at all is because it has a few excellent patches built into it. The fact that I have to wade through the swamp of illogic that is its user interface remains one of most frustrating parts of my job as a media composer.
Also, one of the ironies in reason is that you quickly arrive at the point where you want to wire the relevant knobs and dials to one central virtual control surface, because scrolling up and down over 3 screens full of devices gets old rather fast.
But there is no such thing that I know of (in Reason4), so without a physical MIDI control surface you're effectively lost.
Disclaimer: I'm only a casual Reason user, perhaps I'm missing something. I also hear Reason5 has some improvements but haven't upgraded yet.
The problem I had with the article is he didn't prove that these interfaces impede functionality. I don't know the market well enough but you seem to be a user of Reason and the interface obviously appeals to you.
Same with iBooks. I know people who love the faux-3d book pages and who swear it enhances the experience for them. Perhaps the author has a point about them not being proportional but that would be a suggestion to make the effect more useful. Not a reason not to use it.
Skeumorphic design elements are, by definition, decorative elements that CAN enhance functionality. So even if they don't enhance functionality they're still acceptable as long as they don't impede it.
It's definitely not obvious, but there's only so much that you can make _obvious_ on such a small screen. Its important that cancel and done are obvious, as they're the primary action here. I think its important that you know you can delete some of this info, so the delete is buttony. Is it nice knowing that you can change the label of a phone #? Yep. Is it important? Not really, especially if the contact has only one number (probably the overwhelming majority of contacts). If you care and start poking around, will you discover it? Probably.
I actually didn't discover it. I had to look online to figure it out. Think too of how one would come across this screen. My goal was to add a home phone number. One doesn't think that you need to change "iPhone" to "Home" to add a phone number.
FWIW, you've just pointed to a howto article which describes it as "hard to find" - and they must have thought it was hard enough that people could do with some extra help before they wrote the article. You can't please everyone!
I can't remember how you would change an entry labelled "other" to "home" with that version of the interface. One benefit of the current one is that you change the field label in the in the same way that you set it the first time, so there are less "parts" of the interface.
1) I don't think 3-D looking buttons are a bad thing per se. I was actually thrown for a loop by the iPhone contact screen where to make a call you have to click on a flat and non-button-like half of a wiget.
2) Some times, I think 3-D shapes can guide the eye/ help the user make sense of a GUI.
3) I actually grab syrup bottles by the little handle. Does that make me a bad person?
Buttons are a good example of skeuomorphic done right. In real life, if something's supposed to be turned, I expect it to be a knob. If something's going to be pulled, I expect there to be a handle. Since you're expected to click or tap buttons, it they should obviously look like buttons.
I think that Apple's decision to continue buttonizing touch UI was probably wise in the beginning, but seeing Windows Phone 7's all flat everything approach feels really fresh. Why don't they chrome up their touchable objects? Because its a _touch screen_ and the only thing you can POSSIBLY do is _touch_ them. The context is I took out my device to do something with it, I expect to be touching things.
So while buttons may still need to be buttons on the desktop, I'm happy to see chrome fade away in touch UIs.
[1]: http://en.wikipedia.org/wiki/Skeuomorph