Settings (or is that preferences?) in software – like their mechanical counterparts – have long been grouped together and placed out of sight from day-to-day use. Alternatively they are surfaced to create a control-laden interface weighed-down with options that are almost never needed. Revealing options contextually can be an elegant third way to solve this problem but the execution needs to be tight.
The Kindle iphone app has a nice example of how this can work in the way that it manages orientation. Rather than having an option to lock it buried away in a menu somewhere or always cluttering the screen, it instead appears the moment the screen switches. It’s subtle but obvious and presented in an elegant, modeless way that doesn’t interrupt you if you did intend to switch the orientation and extends a hand if you didn’t. If you’ve already locked the orientation it provides a nice status indicator right at the point it becomes relevant; which doesn’t interrupt your reading if you didn’t mean to switch the orientation but catches your eye if you did.
I’m reading my book:
The orientation switches (whether accidently or deliberately) and the lock status/control appears:
If I’ve already locked it I’ll instead see this:
You aren’t conscious of the orientation of the screen until it switches; and at the very moment your locus of attention is drawn to the orientation, the locking option appears. Before you can finish thinking “I need to lock that screen” the control to do just that appears – it almost feels a little bit like magic.
I’ve always found the iPad’s handling of orientation a little bit clunky. I need to think about it and it becomes a mini-task in its own right. This is a more elegant solution and an exemplar of how to deal with complexity without breaking flow.