Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This article is really about two things - expectations and communication - and Derek makes an interesting tangential point about personal quirks without actually addressing either of those issues.

Users expect things to be a certain way. In most business situations, that's advantageous - when expectations become standard across your user base it allows you to build upon those expectations. (Rapidly thought-up example: most users now expect underlined text on a website to be a hyperlink, which allows authors to link to external sources without specifying 'click here' all the time.)

But what if you want to be cutting edge, or do something that isn't expected? Then you need to communicate how you have changed expectations. When Derek checked into that hotel, they should have explained how the lights and taps worked (probably had written instructions for both in the room as well, although that's not much use in the dark).

Apple have been very successful inventing their own quirks. Some of that success is leveraging our expectations - it's why we call their devices 'intuitive'. Some of it is communication - see how many Apple ads (even still photographs) demonstrate the touch pad being used, to communicate to dedicated mouse-users that their expectations may go astray. And Apple aren't perfect - I had to Google how to turn off my wife's iPod because it wasn't in the instructions and didn't meet my expectations of an off switch.

A business coach I worked with once summed up business as: Business = People | People = Expectations | Expectations = Communication, so

Business equals Communication.

It's a useful framework when building any product for consumption by others.



> I had to Google how to turn off my wife's iPod because it wasn't in the instructions and didn't meet my expectations of an off switch.

A beautiful example! I don't know what her model is, but the iPod Shuffle 2G has the (to me) astonishing feature that the 'Off' part of the 'On/Off' slider doesn't actually mean 'Off', despite being so labelled; it means 'Reset' (forget what you've played, and where you were in the current song). The correct way to accomplish 'Off' is 'Pause' followed by 'now wait a while' --which I consider an extremely clumsy move on Apple's part (not the behaviour, which is fine once you discover it, but how un-, and even counter-, intuitive it is).


> The correct way to accomplish 'Off' is 'Pause' followed by 'now wait a while' --which I consider an extremely clumsy move on Apple's part (not the behaviour, which is fine once you discover it, but how un-, and even counter-, intuitive it is).

But that wouldn't be "off", that would be "hibernate". Which is what you want most of the time.

Off would be a complete power off, and it makes sense that the device's state is not saved to NAND (because most people won't ever need that). The configuration wasn't changed was it?

It's the same with e.g. an iPhone, a quick tap of the power button shuts down the screen, a long tap completely shuts off the device. Most people never ever need to completely shut it off.


> But that wouldn't be "off", that would be "hibernate". Which is what you want most of the time.

I agree, and, indeed, I think the behaviour, once discovered, is perfectly sensible; I'm just talking about the initial discovery experience.

The manual (at http://manuals.info.apple.com/en/ipod_shuffle_features_guide...) does not use the terminology you mention; instead, it refers at the top of the chart on p. 4 to 'Turn[ing] iPod off', then at the bottom of the same chart to 'Reset[ting] iPod' (both by pushing the slider to 'Off'!); and it does not mention 'Hibernation' (or equivalent terminology), or the fact that it should replace complete power down, at all.


> I agree, and, indeed, I think the behaviour, once discovered, is perfectly sensible; I'm just talking about the initial discovery experience.

The initial discovery experience, for most people, is that you don't do anything and you iPod "magically" does the right thing in return.


> The initial discovery experience, for most people, is that you don't do anything and you iPod "magically" does the right thing in return.

I think that, at this point, we're getting into anecdotal evidence; I don't have any idea what most people's iPod experience is, but certainly it's not natural to me to conclude my experience with an electronic device simply by walking away from it—I want to turn it off. (The fact that computers are an exception perhaps explains why a younger generation might be more inclined to the 'just walk away' approach. EDIT: OK, and cell phones. But I still think that I have more devices in my life that I turn off than devices that I don't. :-) )

My main evidence that this is not the only obvious approach is that it is different to the behaviour of the iPod Shuffle 1G, which one did (or at least could) put into hibernation by sliding the main switch to 'Off'. It was this change between generations that particularly confused me.


I had to Youtube how to put a sim card in my iphone : d


"But what if you want to be cutting edge, or do something that isn't expected? Then you need to communicate how you have changed expectations."

If it's a change worth making, you shouldn't have to communicate it.

Your users shouldn't say, how does this work? They should say, this is how it should have worked all along.


> If it's a change worth making, you shouldn't have to communicate it. > > Your users shouldn't say, how does this work? They should say, this is how it should have worked all along.

I think that this is extremely limiting. I am a moderately skilled vim user, just 'power'ful enough that I have a range of vim-specific tricks up my sleeve, and am frustrated when other editors (seem to) make the same tricks difficult to achieve. However, no one will accuse vim's feature set of being easily discoverable.

By your criterion, it seems that this sort of behaviour, which is hard to learn but powerful once learnt, can be ruled out; and this seems to confine us to a sort of playground where we can perform certain tasks very, very naturally, but are then confined once we need more.

In short, I would change your slogan (which I think is very catchy!) to the less euphonious "Your users should eventually say, 'this is how it should have worked all along'."


Within the context of the discussion, vi is horrible.

What benefit does vi provide for a user that will only ever use it once? Why should he bother learning it if he's not going to use it but one time?

However, vi is good when you plan to use it often. The skills learned will benefit you years to come. It's worth a learning curve.

Both these ideas were noted in the article, and from my take, expanded upon by the above commenters.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: