W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2019

Re: [mediacapture-screen-share] Specify track.label (#128)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 17 Dec 2019 18:13:25 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-566683140-1576606404-sysbot+gh@w3.org>
> For camera/microphone sources, I do not see track labels as really useful to show to users.
Do we know websites using it this way?

`track.label` has been there forever, and is merely short for
(await navigator.mediaDevices.enumerateDevices())
  .find((d => d.deviceId == track.getSettings().deviceId).label
...and is used all the time:
<img width="400" src="https://user-images.githubusercontent.com/3136226/71021127-aceec300-20cb-11ea-8847-90da2c31fb65.png">
I'd argue, to my point, that when users click above they don't yet know whether they'll get a drop-down or a selector popup window. Of course, on the back-end, if it's the former, then using `deviceInfo.label` is obvious; if it's the latter, then `track.label` is obvious.

E.g. for symmetry (more than great design) one might imagine another line in the above UX:

  __Little League Fundraiser - Powerpoint__

Of course, an application may allow any number of concurrent streams (for camera or screenshare), that's not the point. The point is: showing the current selection you've made is an enforcer in any selection model, and serves as a reminder of what you're sharing (which may not be obvious otherwise, even with a tiny self-view).

I see no inherent difference here between specs, just because one button is backed by in-content selection https://github.com/w3c/mediacapture-main/issues/652, and the other by in-chrome selection. Clearly labeling current choices seems like a good web principle to me, as an aid for the visually impaired if nothing else.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/128#issuecomment-566683140 using your GitHub account
Received on Tuesday, 17 December 2019 18:13:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:35 UTC