AW: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex details - 24 Sept 2015 at 15:00 CEST)

Hi Francois,

Thx a lot for your feedback ;) please find my comments inline. 

Louay

> 
> Not raised during the call as I was busy scribing, but I have a couple of
> comments as well, so thought I'd share them here.
> 
> The Presentation API is currently limited to selecting only one second screen
> at a time. That is not a real problem as the main use cases considered only
> involve one second screen (at least one second screen at a time). However, I
> wonder whether discovery of a single Thing is also a common use case for
> connected objects.
> 
> For instance, looking at the Generic Sensor API [1] that was mentioned
> during the call, I see that the entry-point to that API is to retrieve and
> monitor *a list of sensors*. Although a Thing in the WoT case may be contain
> more than one sensor, I suppose that, most of the time, the mapping will be
> one Thing per physical object, as in "a light bulb". I see value in the ability to
> select and interact with a particular light bulb, but I also think that it might be
> useful to select "all the light bulbs in this room" for instance.
> 
> Would supporting the ability to select more than one Thing at a time be
> useful? Do you see what API changes could do the trick? (That feature could
> actually be useful for a future version of the Presentation API)
[Louay] Completely agree on this I think I see more relevance in the Thing API 
for multiple select than for the Presentation API because in the Presentation API when 
you start a PresentationRequest the presentation  page  will be launched  when the user 
 selects a display but in the Thing API proposal the web page will only  get the thing. 
To support multiple changes an array of things can be passed to the page when the 
Promise is resolved instead of only one (input things instead of thing):
ThingRequest(filter).start().then(function(things){…}).catch(function(err){…});
> 
> Also, although we're addicted to screens, the typical number of available
> displays for the Presentation API should remain pretty small in most
> contexts. There may be more Things to choose from, which might mean that
> the list could grow out of control. I suppose that the user agent could be
> smart enough to group things together but that would require additional
> logic on their side.
[Louay] Yes this is a feature of the UA how to show the Things in the Dialog. E.g. 
the UA may offer groups and search field and also sort things according to user 
preferences or proximity. 
> 
> Or it may be that the light example is not a very good one. Requiring the user
> to select a light in a list just to be able to switch it on or off may not lead to
> the best user experience. The API may be much more useful to interact with
> more complex things: the user won't have many of them and selecting only
> one will be the default need. What do you think?
[Louay] yes I agree if the user always needs to  select a Thing from the Dialog to interact with it is
not a good user experience. This is why in my API proposal there is another function 
navigator.things.getById(id).then(...) which is relevant for things that are already selected by the user.
This means the user needs to select a Thing from the dialog only once in most case. The dialog is needed to get access to 
NEW  things which are not available yet for the web page. The web page can use in addition the function 
thing.getReachability().then(function(reachability) {
 handleReachabilityChange(reachability.value);
 reachability.onchange = function() { handleReachabilityChange(this.value);}
}); 
to watch the reachability of a Thing. This is very similar to the getAvailability() function in the Presentation API. 
> 
> Thanks,
> Francois.
> 
> [1] https://w3c.github.io/sensors/

>

Received on Friday, 25 September 2015 10:59:58 UTC