- 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
> 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 ```js (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: Presentation __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