RE: [Geofencing API] Request for use cases

Hello All,
I just posted the respec code for what is an initial attempt at a use cases section in the corresponding issues list (had trouble creating a pull request).

See https://github.com/w3c/geofencing-api/issues/15.


-Giri

From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Sunday, June 14, 2015 3:15 PM
To: Ravi Dandu; public-geolocation@w3.org
Cc: Jamie Knight; Michael Cooper; Neil Milliken
Subject: RE: [Geofencing API] Request for use cases

All,
Here is a version of a doc I started to put together last year.  Note that there is also now a GH issue to track this: https://github.com/w3c/geofencing-api/issues/15.  There was already one use case covering geofencing in the original Geolocation API document.  It is possible to add an accessibility use case.

-Giri



From: Ravi Dandu [mailto:ravidandu99@gmail.com]
Sent: Wednesday, June 10, 2015 4:12 PM
To: public-geolocation@w3.org<mailto:public-geolocation@w3.org>
Cc: Jamie Knight; Michael Cooper; Neil Milliken
Subject: Re: [Geofencing API] Request for use cases

A few other use cases for geofencing:

Entering an area:
    1) WebApps auto-checkin to a hotel when user enters the premises
    2) Businesses sending advertisements, offers, discounts, when device gets close to their store.
    3) Reminder App sends event on todo items when close. eg: reminder to buy a batteries when within proximity of a retail shop

Exiting an area:
    1) When user exits office, sends a text to spouse stating will be home in 30 minutes.
    2) When user exits home, app makes sure the lights are turned off

Regards
Ravi Dandu

On Wed, Jun 10, 2015 at 11:36 AM, Neil Milliken <n_milliken@hotmail.com<mailto:n_milliken@hotmail.com>> wrote:
This could be useful for other groups too. I certainly think that the prompts for routines and reminders will be useful for many with reduced working memory.

Kind regards,

Neil

> On 10 Jun 2015, at 18:09, Jamie Knight <Jamie.Knight@bbc.co.uk<mailto:Jamie.Knight@bbc.co.uk>> wrote:
>
> Hiya Michael,
>
>> From an autism perspective, this feature could be extremely powerful. Thanks for working on it.
>
> I think from a cognitive point of view i could see the following considerations:
>
> - Complex Concept - some efforts to standardise the way concept is explained, perhaps with some work done to work on some example explanations which consider a range of ability. (also relevant to younger users)
>
> - Consistent symbols and Labelling - effort to provide standardised symbols and labeling for terms used in relation to this API. Eg, "Enter" "Exit", "Leave", "Cross" etc.
>
> Use cases around autism:
>
> - Prompting and Reminders - using geofencing to surface prompts and routines (eg, bring up the "doing a shop" routine outside the supermarket, bring up the "going to the hairdresser" routine / guidance outside the hairdressers)
>
> - Safet Zones - Alert the user when they are outside of an established "safe" zone. With the correct privacy controls, alert other when a user moves outside of a Safe zone.
>
> - Dynamic Safe Zone - establish rules such as "never more than a mile from someone who can help" and then use overlapping geofence to establish a "safe" zone. Then use moving geofences updated every minute to establish if the user is within the dynamic safe zone. These would also be an effective way of knowing who to contact for help. Establishing who is "closest" in a battery efficient manner.
>
> - Notification of arrival / departing - let the support team know when i arrive at the office, or when i leave.
>
> Some of these will also overlap with other impairments.
>
> Cheers,
>
> Jamie + Lion
>
>
> ________________________________________
> From: Michael Cooper [cooper@w3.org<mailto:cooper@w3.org>]
> Sent: 10 June 2015 17:33
> To: public-geolocation@w3.org<mailto:public-geolocation@w3.org>
> Cc: PF
> Subject: [Geofencing API] Request for use cases
>
> The Protocols and Formats Working Group looked at the First Public
> Working Draft of Geofencing API http://www.w3.org/TR/geofencing/. The
> group thinks there may be interesting accessibility relationships but
> needs to better understand the use cases behind this API. We request
> that an upcoming draft include a section on use cases, which will allow
> us to better target feedback.
>