Text archives Help


RE: [projectvrm] CloudOS


Chronological Thread 
  • From: "T.Rob" < >
  • To: "'Peter Cranstone'" < >, "'Phil Windley'" < >
  • Cc: "'Doc Searls'" < >, "'ProjectVRM list'" < >, "'Drummond Reed'" < >
  • Subject: RE: [projectvrm] CloudOS
  • Date: Thu, 12 Sep 2013 23:08:18 -0400
  • Authentication-results: mailspamprotection.com; auth=pass smtp.auth=184.154.225.7

> Can you draw in what a user sees in an ambient interface?

 

No.

 

That's the point.

 

How would you represent the user interface for a motion sensor?  Today you can buy motion sensors purpose-built into light fixtures, security systems, home automation, etc.  In Phil's CloudOS you might instead have a general-purpose motion sensor that simply published "motion detected" events.  Other devices could subscribe to these directly, or a rules engine could process them then correlate events with those from other sensors, and finally trigger more complex behaviors through actuators.  The user interface for the routine operation of the system is that it disappears from the user's conscious management.  Things appear to the user to be "smart" in relation to ambient conditions and the states of other things.  The "interface" is the behavior of the things that are actuated.

 

We already have this technology benefitting us in our daily lives and we are so used to it we do not think to ask what its user interface looks like.  For example…

 

The user interface for traffic light control consists largely of induction loops buried under the pavement at intersections.  The degree to which induction loops are invisible to drivers is evidenced by the number of people waiting halfway into the intersection for a light that doesn't know they are there because they completely overshot sensor.  For the people who do manage to stop the car above the sensor, the traffic lights seem to do more or less the right thing and respond to the presence of vehicles.  There's an API and messaging driving those interactions.  It's sensitive to the environment, i.e. ambient.  How would you draw the user interface for that and who is the user, the driver or the traffic engineer who expressed the preferences as a set of rules?

 

Similarly, we have sliding doors that open and close based on motion sensors or pressure mats.  The user interface is that the door (mostly) does what you want, when you want it without you having to think about it.  These used to be purpose-built analog devices but are increasingly driven by digital sensors sending messages through an API and tied not just to the door but to cameras, alarms and building automation.  They are sensitive to the environment, i.e. ambient.  How would you draw the user interface for that and who is the user -  the customer crossing the store's threshold, the installer who programs the sensors and actuators, or the store's owner?

 

The ambient interface Phil describes takes that level of automation and applies it to non-commercial purposes.  For example, an increasing number of merchants I shop with will send an e-receipt.  How do you draw the user interface for the transaction in CloudOS that would receive that e-Receipt, parse it and file it in a database?  To the shopper making the purchase the user interface looks like the card processing terminal in the store.  Later on, the user interface looks like a ledger entry in a purchase history display.  But the transaction to which Phil refers occurs between CloudOS and user's email server, when a piece of glue code that parses the email receipt into an XDI message then calls the API.  It has no exposed user interface.  It is event driven, ambient and outside the user's conscious control.

 

Does that help?

 

-- T.Rob

 

 

From: Peter Cranstone [mailto: ]
Sent: Thursday, September 12, 2013 15:41 PM
To: T.Rob; 'Phil Windley'
Cc: 'Doc Searls'; 'ProjectVRM list'; 'Drummond Reed'
Subject: Re: [projectvrm] CloudOS

 

I still have no idea what an ambient interface is?

 

Can you draw in what a user sees in an ambient interface? What is it that I press on to make this all work?

 

 

 

 

Peter

 

 

 

 

 

not sure what an ambient interface is

 

This gets back to the idea of headless services driven by devices and

infrastructure.  The use cases you've been concentrating on are user-driven

and real-time.  The ones I've been focusing on are device or infrastructure

driven, real-time or batch.  Phil's infrastructure accommodates both models

although his statement suggests he sees the device/infrastructure side as

being more prevalent in CloudOS.  Both are important and if XDI can span

them, so much the better.

 

-- T.Rob

 

-----Original Message-----

Sent: Thursday, September 12, 2013 12:33 PM

To: Phil Windley

Cc: Doc Searls; ProjectVRM list; 'Drummond Reed'

Subject: Re: [projectvrm] CloudOS

It will work either in an XDI enabled browser or in an XDI enabled app

with

an ambient interface (not sure what an ambient interface is). We have an

XDI enabled mobile browser so naturally it gets my vote for the

transmission of data and also a really simple interface. You can come up

with an app tomorrow and we can replicate everything inside the browser

overnight - versus trying to build a cross platform app which requires too

much investment.

After watching your video the interaction takes place inside the browser,

why? Because it's a simple interface. IMO why confuse the consumer with

something new to learn on other devices. For VRM to work you have to

have a high adoption rate, changing interfaces introduces friction into

that,

and from the stats I've seen the (real world data) the usage drops off

incredibly quickly.

Remember all of this has to integrate into existing vendor infrastructure

- in every meeting I've been in Network Admins are not receptive to new

protocols or opening up additional ports in to their networks. VRM will

not

have a single answer - VRM is a concept that can be implemented using

various approaches - the customer and vendor will ultimately decide who

has picked the right approach and the right interface.

Peter

On 9/12/13 10:19 AM, "Phil Windley" < "> > wrote:

> 

>I don't think that the browser is the place where this will get the

>most use. In fact, I envision most of the interactions with CloduOS

>being done by other services and devices on the user's behalf. The user

>will use a browse or mobile app to configure that system, but I want

>the interactions to happen away from the device. Ambient interfaces, if

>you will.

> 

>On Sep 12, 2013, at 10:05 AM, Peter Cranstone

>> On second thoughts after watching the video etc., you can do this

>>without  an XDI enabled browser. All you need to do is build XDI

>>enabled  applications, although IMO that's more complicated and comes

>>with the risk  of figuring out how to extract real value with the app

>>(i.e. give it away  for free but charge for the service). Scaling it

>>across multiple OS's is  also more complex but certainly doable with

>>the right investment.

>> 

>> 

>> 

>> Peter

>> 

>> 

>> 

>> 

>> On 9/11/13 3:37 PM, "Peter Cranstone"

>>wrote:

>> 

>>> Looks like a perfect fit for an XDI enabled browser.

>>> 

>>> Peter

>>> 

>>> 

>>> 

>>> 

wrote:

>>> 

>>>> Phil Windley has put up an excellent short site on CloudOS, an open

>>>> source OS for personal clouds. It's at http://cloudos.me.

>>>> 

>>>> Check it out. And help out too. As you can see from missing future

>>>>links  in the site, CloudOS is still new and needs more programmers

>>>>working on  it.

>>>> 

>>>> Doc

>>> 

>> 

> 

> 

 

 




Archive powered by MHonArc 2.6.19.