WIP: Use Cases #30
WIP: Use Cases #30
Conversation
|
Thanks @tomayac, this looks like a great start! (Enjoy your vacation!) All - please review the WIP use cases @tomayac has put together. We are expected have a discussion at TPAC around these and any other use cases brought to our attention that will inform the API design. To ease the review, here's an HTML preview of the latest in this branch. (I just enabled pr-preview for this repo that automatically adds similar HTML preview as well as an HTML diff link to any PRs submitted.) |
use-cases.html
Outdated
| </section> | ||
|
|
||
| <section id="usecase_content_annotation"> | ||
| <h4>Annotating content with location information</h4> |
There was a problem hiding this comment.
Why does this use case require background-continuous geolocation updates? It seems similar to the social networking example above except that it uses background sync to upload data when connectivity is available. The geolocation data itself is associated with actions the user took when the application was in the foreground.
There was a problem hiding this comment.
I have removed this use case altogether. It is covered in one form or the other in the other use cases.
|
Note: 87f31c1 adds @mkruisselbrink as a co-author. |
use-cases.html
Outdated
| </section> | ||
|
|
||
| <section id="usecase_poi_alert"> | ||
| <h4>Alerts when points of interest are in the user's vicinity</h4> |
There was a problem hiding this comment.
This feels more like geofencing, otherwise the user would have to be actively using the application before the notification is generated.
There was a problem hiding this comment.
Right, or both. I can see a use case where an open guide app means ”I’m interested in POIs near me” while a backgrounded app means do not bug me with those POIs, I’m doing something more important.
I think this text communicates that idea:
We note that the categories are not mutually exclusive and that overlaps exist. A task might start in the foreground, then continue in the background (for example, while the user quickly responds to an incoming email), and then eventually terminate in the foreground when the user multitasks back.
There was a problem hiding this comment.
@reillyeon The use case was indeed written with an actively interested person in mind who would have a tourist guide app open in the foreground.
There was a problem hiding this comment.
Can you clarify that in the description?
use-cases.html
Outdated
| status updates with location information. It does this by monitoring the | ||
| user's position with the Geolocation Sensor API. Each user can control the | ||
| granularity of the location information (e.g., city or neighborhood level) | ||
| that is shared with the other users. Any user can also see their network |
There was a problem hiding this comment.
This seems to be conflating two use cases, a) geotagging status updates and b) social sharing of real-time location. The former only requires foreground-one-off location while the latter is what requires background-continuous location.
There was a problem hiding this comment.
I think this is really by design conflated. You check where your friends are (and see where you are) in the foreground, but indeed of course your location gets shared in the background, too.
There was a problem hiding this comment.
Can you make it a little clearer that we are intentionally conflating the two? "Location-tagged status updates" are a feature multiple social media platforms already support that doesn't use background location. We should make it clear that this is different.
There was a problem hiding this comment.
I will highlight this aspect.
use-cases.html
Outdated
| </section> | ||
|
|
||
| <section id="usecase_real_estate"> | ||
| <h4>Real estate search</h4> |
There was a problem hiding this comment.
This feels like more of a geofencing use case but that depends on how many simultaneous geofences the API allows an application to set.
There was a problem hiding this comment.
That is a good point. Related, we should capture somehow that a high number of geofences might create a bad UX. Needs research whether the spec should set some limit or leave that up to the implementation.
There was a problem hiding this comment.
If we imagine there is a high hit rate of matching real estate offers, then it should not be a geofencing use case, but a "send location to a server in the background and have the server apply some business logic" use case.
I agree that the spec should point out that implementations commonly enforce a limit of geofences that can be set, and that the ability to set a geofence is a privilege.
There was a problem hiding this comment.
I will clarify this aspect.
|
The latest changes LGTM. Welcome @mkruisselbrink! I think we might want to bring these nicely documented use cases into the Geolocation Sensor spec direct to get more eyeballs on them. WDYT? We might also want to note that ”Background—Continuous geolocation updates” use cases have the most significant privacy implications and maybe that there are no preexisting UX/UI patterns (for the Web) for this category. Based on F2F discussion I felt the group wanted to make this category ”v2” while tackle all foreground and background one-off as ”v1”. |
If you don't think it's making the spec too big, then I think they can be merged there. Else, I probably would keep them separate.
So to summarize, you are suggesting:
This would, however, mean that the important use case of turn by turn navigation would not be possible in v1. In that light, I would rather move all background operations into v2, which would mean a short path to v1, and then allow us to tackle v2 with all its serious privacy implications at a point in the not too distant future. Thoughts? |
|
I wouldn't worry about the spec getting too big. There are specs that are 100s of pages and counting :-) I feel that v1/v2 split is a good approximation of our F2F discussion. It should be noted we did not record any explicit resolution regarding this, just to "continue to refine use cases document" and that's what we're doing here. All - please let us know if you have concerns with the proposed v1/v2 split. Couple of related takeaways from F2F in support of the proposed v1/v2 split: (It should be clarified v1/v2 are not formal constructs, they're just buckets for ourselves to put features in to help us scope our work and set priorities. Subject to change with new information.)
(I tend to agree with that from experience with Generic Sensors. It is much easier to get early web developer feedback if you offer new capabilities and not just improved API ergonomics.)
|
|
@anssiko Please note that I proposed…
|
|
I think the concern I heard at F2F was whether such a v1 scope that does not enable new use cases over the legacy API incentivizes implementers to implement and web developers to use (and most importantly provide feedback on!) the v1 API. (This assumes some implementer wants to ship v1, not wait for v2.) If that is not a concern, the tighter the initial scope the better. Either way, we'd likely tackle the foreground use cases first, so maybe the solution is to drop the versioning and just label background use cases as "new" to communicate to the wider group our scope of work in contrast to what exists in the legacy API and defer the v1/v2 discussion to a later time when there are intents to implement. |
|
Speaking from a Chrome perspective it will be easier to bring this through the launch process if we do separate launches for the old functionality and the new functionality. That doesn't necessarily mean they have to happen serially. It's just helpful to limit the scope of any particular discussion. |
|
@reillyeon, thanks, that's valuable information. So I'm hearing we might follow the pattern established by Generic Sensors in terms of the launch process and the proposed order seems fine (noting that we can also do old and new spec feature work in parallel, and implementers can implement a subset of the spec at any time). In terms of moving this PR onwards, I'd be fine just annotating the "new" use cases somehow. I leave it to @tomayac to figure out how exactly. Second, I'd be in favor of moving these use cases to the spec so they get more attention e.g. when we do periodical Working Draft publications of the spec that is broadcasted outside this group. Also use cases are easier to maintain as the spec evolved if in the same doc, and we can do a reality check for the API against the use cases more easily. |
|
See an HTML preview via Bikeshed. |
|
@tomayac LGTM. Feel free to merge this first version of use cases assuming @reillyeon's feedback has been also addressed. Further feedback is welcome via new issues and PRs. Note: I'd like to add Marijn @mkruisselbrink who contributed to the use cases (and previously edited the Geofencing API) as another co-editor subject to his approval. Based on my discussion with him he was interested in editing this spec. Since he has valuable expertise from his earlier work I'd support his nomination. I think @reillyeon seconded that. |
|
Merging. @anssiko, can you deploy, please? |
|
Travis CI takes care of deployment. See deploy.sh for details. Since all was good, the latest spec has been deployed. |
|
What is the status? Is there a way to add location tacking within a PWA by now? |
|
@lovishagg The status is the same as for geofencing. The location tracking in the background bug to track for Chrome is https://crbug.com/898536. |
|
Sadly there does not seem to be too much movement in that issue as it's blocked by a restricted issue. If I understand right this just points to the chromium implementation. Am I right? If so: Do any of you know about progress for other browsers? Firefox maybe? |
|
Regarding the use cases: has there been any discussion of adding the cultural/museum use cases as mentioned below? https://discourse.wicg.io/t/proposal-expose-geolocation-to-service-workers/2588/42 |
|
@joshkopecek Addressed in the above commit. |
This is true (and that's arguably a good thing.) I think it'd be eminently appropriate to designate that particular use-case as unique, with a possibly-unique workflow, though I think it's also a very important use-case: e.g. it'd enable jogging/cycling tracker PWAs, as well as deeply reducing the threshold for, say, creating custom mapping apps. |
|
@JamesTheAwesomeDude thank you for reviewing this work. I'd encourage you to open a new issue with your comments, or augment an appropriate existing issue at https://github.com/w3c/geolocation-sensor/issues (The comments submitted to this PR that has been merged might get easily lost.) |
|
@JamesTheAwesomeDude "This is true (and that's arguably a good thing.)". Really? REALLY Which bit of the answer illudes you? |
Summary:
This Work In Progress Pull Request mixes the "legacy" use cases from the previous API with the new use cases.
Problems:
They do not fit together style-wise: the legacy use cases are more narrative-driven, the new use cases are more fact-driven. We need to agree on a style, and then adapt accordingly.
Also not sure if W3C Editor's Draft in a separate document is the correct format, or if we want to have them right in the spec, as is the case in the legacy API.
Background:
I will be on vacation for the next two weeks and could not dedicate as much time as I wanted before heading out, so if anyone wants to improve on where I have left things now, certainly feel free to do so. This is clearly not in a ready state yet, but I thought I would PR early and we then incubate… 🤙
Preview | Diff