Re: [w3ctag/design-reviews] User Idle Detection (#336)

Great feedback @kenchris ! Let me try to address that!

> Should this be event based instead of observer based? Check our design principles 
> https://w3ctag.github.io/design-principles/#events-vs-observers


Great question and thanks for pointing out that doc!! Super helpful!!! The following seems to be the [general guidance](https://w3ctag.github.io/design-principles/#events-vs-observers):

>> In general, start your design process using an EventTarget and only move to Observers if and when events can’t be made to work well. 

In the specific case of idle detection, I run into the following:

>> Instances observe specific targets, using the observe() and unobserve() methods. The callback provided in the constructor is invoked when something interesting happens to those targets.

In that, in the [EventTarget formulation](https://github.com/samuelgoto/idle-detection/blob/master/README.md#navigatoridlequery), `navigator.idle.query({threshold: 60})` takes a configuration object with a threshold. Does that cross a line to tip us towards observers? Or would are there more precedent for configurations to be passed as the creation of EventTargets?

> Should events be delivered to tabs in the background - I think they should, as my Hangouts and Slack 
> tabs are seldom in foreground and people still want to know whether I am idle or not

Yes, events are delivered to tabs in the background. That's more or less the point of the API, because when your tab is in the foreground, idle detection can be polyfillable (with detecting gestures and the Page Visibility API).

> Are events restricted to top-frame and https? - they should be

[Yes](https://github.com/samuelgoto/idle-detection/commit/f2d319989523e54e80ed53876acb384a1e1a7efd).

> To reduce multiple sites identifying me as the same person due to the time I idle, it might be possible to > introduce some fuzziness between reporting to the various observers

Ah, good point. That came up on a security/privacy review. Let me digest this a bit more and circle back.

> For IM, users usually want to know if a user is available to know whether they can expect a response 
> or not - but often people in meetings/busy cannot respond - maybe we need a API for sites to report 
> business and these should be tied together

Hummmm ... can you walk me through how this would work?

> how important is the configuration? I can easily start a timer myself for say 5 minutes idling before I 
> update my UI, and the event is only send infrequently

The only configuration available is a `threshold` you pass, in seconds, as the criteria for idleness. Without a threshold, you'd have to poll. Does that make sense?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/336#issuecomment-469431564