[IxDA Discuss] A Semi-Theoretical Question

[Edwin Booth]

I second Marks' first two suggestions, although I'd rename the first one to 'multi-touch point systems' or something similar and hopefully less geeky sounding.

In this space I see two big themes you could cover - one is the thing+another thing = product - i.e. the TV+remote - where a single experience is distributed across different physical objects. 

Another is a single overall system with multiple user types, each with multiple possible points of contact tailored to their access rights and needs. For example, in enterprise systems an IT admin would access their 'admin' functions via a desktop PC, handheld and/or cell phone. While a 'task worker' might access specific content/functions created by their admin from a handheld and/or PC. Meanwhile an uber-admin manages the whole thing from their PC/handheld/cell phone. 

Designing for each individual user/touch point while maintaining overall coherency of the system AND achieving effective scalability, localization, customization, etc would class as 'advanced' in my mind.

My two cents any way.

Ted


On Wednesday, October 11, 2006, at 09:53AM, Marc Rettig <mrettig at well.com> wrote:
>Distributed interactions
>Designing for situations where the "interface" is scattered across more than
>one device. This is coming up more and more often. Relatively easy cases are
>things like TV + Remote, where there are difficult choices and trade-offs to
>make about where to situation some of the functionality. I can make a
>four-button remote, but then I have to load the soft interface on the TV
>with more complexity. 
>
>More difficult cases: I'm managing my weight for health reasons, so there's
>a PC interface, maybe a web connection with my physician, a body monitor,
>and who knows... my shoes? Or more generally, it is increasingly the case
>that services and products are spread across phone, computer, web, and lord
>knows what other devices. Many of which are simply platforms we can employ,
>but we can't really change or even predict what the actual buttons and menus
>might be.