- From: Dan Lyke <
>
- To:
- Subject: Re: [projectvrm] Ambient Interface
- Date: Fri, 13 Sep 2013 07:43:58 -0700
Stupid GMail interface meant the first pass of this went straight to
Peter. Sorry.
On Thu, Sep 12, 2013 at 4:08 PM, Peter Cranstone
<
>
wrote:
>
Browserless Information should be glancable and require no
>
navigation (I don't agree with this other than to display a
>
picture. There has to be a menu somewhere).
A menu is a way to navigate a hierarchical tree. I think what many of
us desire in interfaces is flatter navigation, which is why the world
tends towards command-lines. And if you're one of those people who
says that we've settled on the GUI, I offer one observation: Search is
a command-line for the web.
But really, I suspect that what T.Rob means by "ambient interface" is
one that takes already available information and acts on it. This
isn't the environment around me presenting me with a menu, this is it
engaging me in a conversation.
It's a tricky space: When I flip a light switch, I want the light to
go on. I don't want the light thinking "what did he really mean?"
(Mostly [1]). But when I do switch on that light, I'm telling my
environment a lot more than "hey, I'd like some more light in here".
Likewise when I turn on my stove, or open a door, I'm engaging an
interface, but if those handles have notion of context, they can know
to do a lot more than light the burner or allow me access to the room.
Okay, here's one: My bathroom light switch plate has 3 switches
(light, fan, heater) and a timer knob (heater). One of those switches
has 3 positions, light off, on low, and on. If I'm up in the middle of
the night, I want the default to be "on low". If the hall light is on,
I want the default to be "on". If something knew the state of the
other lights in the house, it could figure this out from how I
interacted with the switch right fast.
No smart phone. No touch screen. In fact, probably the same physical
hardware. And, yes, I'd pay $50 to know that I was far less likely to
stumble into the bathroom in the middle of the night, want to find
something, and accidentally turn on the bright light and make myself
*wide* awake.
This is why designing interfaces now, or starting with interfaces, for
the "Internet of Things" seem to me to be doomed to failure: I shed
gigabytes of intent just walking around my two bedroom house. I
already have buttons in the house that confuse visitors[2]. What I
need is not more buttons and menus, but fewer. Which brings us to:
>
Calm Should be seamless with the environment
One only has to look at the mocking of walking and texting to see that
phones aren't seamless with the environment.
>
Persistent connection Information must be current, and
>
regularly updatable (this will eat your data plan and
>
battery on mobile if not coded carefully)
The interface must be responsive. This is different for different
applications. A tenth of a second is too much lag in some UI, in
others we're happy to have interfaces with latency of minutes
(although sometimes we'll but in a secondary effect to message the
user that something will happen: beeps when we press the crosswalk
button, feedback on thermostats).
>
Decision driven data Should be personalized and summarized
>
to help users make decisions quickly and easily. "Should I
>
bring an umbrella with me today?" (Context is key)
Great example: If there's rain forecast, maybe my hat stand knows
about the weather and rotates to put my wool outback hat on the
accessible side, rather than the ballcap. Doesn't force the decision
on me, just makes a recommendation.
The interface for the Internet of Things will be on a screen, and
especially on a touch screen, only if the Internet of Things has
failed horribly and utterly.
Dan
[1]
http://www.kosherswitch.com/
[2] Hot water recirculator. "Help, I was on the toilet, pushed that
button because I wanted to see what it did, and now there's a humming
that I can't turn off". When we stopped laughing... Of course now we
have a bidet seat, hopefully the Toto icons don't really give visitors
like that a shock...
Archive powered by MHonArc 2.6.19.