RE: Collection of bugs for sensor api - would like new WG draft with this cleanup

Philip wrote:
> If the app doesn't know which sensor to use,
> I doubt that the user will know either --
> especially if the sensors have names like:

> Temperature-CPU1
> Temperature-CPU2
> Temperature-FAN4
> Temperature-FAN1
> Temperature-Int@248A
> Temperature-I2C@1c:LM86
> Temperature-USB/1/3/4/5
> Temperature-USB/1/3/4/7
> Temperature-USB/1/47
> Temperature-1-Wire@1f0000441e4a3d0011

> How on earth is a user supposed to make sense of this mess?

A. The UA should provide a way to preview the input.

For a sensor, the preview would definitely work better if it were able to show some historical data instead of just a "now" reading. If I have 3 sensors, one is at 10°C, one is at 12°C and one is at 19°C, I might know which sensor I want based on that information. 

B. The UA should provide a way for the user to provide pretty (for User only) names to devices.

Once I figure out what Temperature-CPU1 or Temperature-1-Wire@1f0000441e4a3d0011 means, I want to be able to give it a name that is meaningful to me, the user, so that when I look at the list, I can pick it right away without needing to use the preview. -- Bookmarks for web sites work this way...

C. The UA should provide a way for the user to see where they've used a device before (Bookmarks/History and more recently Frecency work this way). If I used Temperature-USB/1/3/4/5 for 30s five days ago, and then I spent the rest of the day using Temperature-USB/1/3/4/7, I probably want to use Temperature-USB/1/3/4/7 instead of Temperature-USB/1/3/4/5.

D. The UA should provide a way for the user to name their device while they're using it or after they're using it. You might not know what a device is when you start using it, but you'll be able to describe it to yourself ("grainy", "noisy", "poor quality", "best used outdoors") after you've used it.

E. The UA should provide a way for the user to assign an icon to their device (modern Browser bookmarks have done this for a long time and have slowly improved how they've worked).

> If you think this will never happen,
> then look at your sound input/output options on your desktop system. 

> I have twelve audio input devices:
> USB headset,
> soundcard microphone input,
> soundcard line in front,
> soundcard line in back,
> soundcard SPDIF in,
> microphone in webcam,
> bluetooth paired headset,
> external usb soundcard line in,
> external usb soundcard spdif in,
> virtual audio cables 1, 2 & 3.

Right. And if the UA let you preview your sound inputs you'd be able to quickly determine that a bunch of them are dead (silent) and then select between a few to find the one that's best picking up the audio you care about -- this is sort of how real mixers work. It shouldn't be much different for a computer.

If you look at any audio mixer, it has these green/yellow/orange/red bars indicating audio levels (A).
And typically the mixers I've looked at have at the bottom of most inputs a hand written note on sticky tape indicating "left front mic", "roaming mic", "boom mic", "pole mic", ... (B). Most of the audio people don't draw cute icons next to their sticky tape, but sometimes if you look at a computer you do have a "mic" v. "line" v. "headset" icon (E).

Note that people configuring a real audio system can label their devices at any time (D).

The only thing which is less typical for a real mixing system is to actually have audio samples from each input readily available for review (C), although I suspect that you sort of have that in professional systems.

We're using Audio mixing as the example, but this applies equally to Audio, Video, Temperature or any other sensor. If two sensors are nearly identical, then for most applications, the user won't care which one they're using. If they need to determine which is which, they can probably do something to isolate one from the other (disable a CPU, put a hand over a mic/camera), it's old fashioned, but people understand how to do this -- and as long as there's visual feedback (some wave-form for the audio case or a graph for the temperate sensor, or live video frames for the camera), doing this will seem perfectly natural to them.

> I may be unusual in that I'm a ham radio operator, but I'm not unique.

Perfectly reasonable use case. And thank you for letting me use your setup for the explanation.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 5 March 2012 18:45:18 UTC