Webxr: The Great WebXR Feature Name Bikeshedding Thread

Created on 5 Jun 2018  ·  9Comments  ·  Source: immersive-web/webxr

Gather round everyone, it's time to ~argue~ constructively discuss names in the current API that we'd prefer to be different. Here's how I'd like this to work:

  1. Create a new comment on this issue containing the current name in the API and your suggestion for a new one. Make the suggestion bold so that it stands out in the comments. I'll seed a few examples.
  2. In that same comment, provide some reasoning for the change. _"My aunt was abducted by a pack of wild Sessions, so I feel strongly we shouldn't use that word."_
  3. If you have multiple alternatives to suggest, make a separate comment for each so that votes can be tallied cleanly.
  4. If you agree with a change suggestion, use the "add reaction" button for that comment to add a :+1:
  5. If you disagree with a change suggestion, use the "add reaction" button for that comment to add a :-1:, and please also add a comment to this thread stating, respectfully, why you disagree. _"I'm sorry to hear about your aunt, but I just don't think XRDanceParty is going to be intuitive for most developers?"_
  6. On future calls we'll do a final sanity check with the group on changes with largely positive sentiment before making them official.

If you have suggestions that go beyond a simple renaming, those should continue to be separate issues so that we can discuss the functionality in more detail. Happy Bikeshedding, y'all!

Most helpful comment

APPROVED: “exclusive” :arrow_right: "immersive"

Change approved on the June 12th call.
Context: XRSessionCreationOptions

This was suggested by @speigg ins #320 and then sorely neglected, but after some consideration (and finding myself explaining "exclusive" repeatedly) I do feel that "immersive" is a more intuitive term. I don't think the exclusive behavior of the session should change at this point, so "immersive" should imply exclusivity for now, but it does allow implementations to shift on that in the future without grinding against the chosen terminology.

All 9 comments

APPROVED: “exclusive” :arrow_right: "immersive"

Change approved on the June 12th call.
Context: XRSessionCreationOptions

This was suggested by @speigg ins #320 and then sorely neglected, but after some consideration (and finding myself explaining "exclusive" repeatedly) I do feel that "immersive" is a more intuitive term. I don't think the exclusive behavior of the session should change at this point, so "immersive" should imply exclusivity for now, but it does allow implementations to shift on that in the future without grinding against the chosen terminology.

APPROVED: "headModel" :arrow_right: "head-model"

Change approved on the June 12th call.
Context: XRFrameOfReferenceType

Turns out that this is the web platforms preferred casing for enums.

APPROVED: "eyeLevel" :arrow_right: "eye-level"

Change approved on the June 12th call.
Context: XRFrameOfReferenceType

Turns out that this is the web platforms preferred casing for enums.

DENIED: ~onblur/onfocus :arrow_right: onobscured/onunobscured~

Change rejected on the June 12th call. Nobody particularly liked the obscured/unobscured verbiage
Context: XRSession events

focus and blur events have existing connotations on the web (primarily keyboard focus) that don't match cleanly with what I think these events are trying to convey. "Obscured" seems like a good term that communicates the behavior described in the explainer, which is a scenario where the content may still be visible in some capacity and might still request occasional frames be drawn but makes it clear the session isn't the primary thing being interacted with.

APPROVED: XRPresentationFrame :arrow_right: XRFrame

Change approved on the June 12th call.

With the addition of the input API we're now using frames in places where there's no expectation of rendering or presentation involved. As a result, a more generic name like XRFrame feels appropriate, and happens to be easier to type. :)

onblur/onfocus :arrow_right: onobscured/onunobscured

  • visible/hidden :+1:
  • active/inactive
  • activate/deactivate
  • foreground/background :+1:
  • attached/detached
  • attach/detach
  • primary/secondary
  • focusstart/focusend

I've found Bloch's How to design a good API and why it matters useful when pondering API design, be it naming or other. This paper has stood the test of time well and it's so short it fits in the abstract, thus you can read it without an ACM subscription.

Beside the TAG's Client-side API Design Principles, there's also the HTML Design Principles that also (despite its name) has guidance that applies more broadly to web features. E.g. "Priority of Constituencies" principle is a good example of that. And to not be OT, e.g. the "Pave the Cowpaths" principle is relevant to this naming issue.

Hope you'll find these useful!

Looks like the last issue left is regarding onblur/onfocus. @cvan is this still something you're looking for feedback on or are you ok with the current state of things?

Given that this has been quiet for a month, I think it's safe to close now.

Was this page helpful?
0 / 5 - 0 ratings