- From: Patrick H. Lauke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Nov 2016 10:26:10 +0000
- To: public-css-archive@w3.org
> Only using any-* is a cop out: it tells the author: "there's a bunch of input devices, some of which might be ignored by the user but you can't know which". If authors start to design for the lowest common denominator, this will be an incentive for browser vendors to not report under any-* some of the less used the devices that users, because it dumbs down the UI unnecessarily. You talk of lowest common denominator and "dumbing down", so clearly you have a value judgement here that having large targets and no hover is intrinsically a bad thing. The main tension I see is this: assuming I as a user have both a fine/hover-capable input and a coarse/non-hover-capable input at my disposal, and I am able to switch equally between them - a UI that relies on larger targets and foregoes hover-specific functionality will work for all my input modalities - a UI that relies on small targets and is based on hover-specific functionality will *only* work if I explicitly only use the fine/hover-capable input So, given multiple input types, designing for the lowest common denominator isn't "dumbing down"...it's adapting the interface to ensure that all available inputs can be used. This is a user-friendly move, a positive. It feels like your (perhaps not you personally, but the working group's?) own value judgement of "non-hover/coarse interfaces are dumbed down" influence the spec. The "this will be an incentive for browsers..." part seems rather a conjecture on your part. Would browsers take a user-hostile move, really? Would browsers willfully hobble their functionality because they share the belief that "if there's both a mouse and a touchscreen, surely the user will be happy if we just pretend there's just a mouse"? I'd like to hear statements from browser vendors to that effect... > When you take the surface studio horizontal in drawing-desk mode, you quite possibly have a device which is primarily used both with pen an stylus. So maybe it could be described with `coarse` and `fine` matching at the same time on pointer. But because the spec currently forces the idea of a single *primary* input, this wouldn't work, would it? > But the way I think of it this finger+stylus interaction is able to make accurate clicks, thanks to the stylus. So when designing a UI for it, you do not need to forgo small clicking targets. So in a finger+stylus scenario, you still contend that stylus is then the *primary*. But take your own example later on of the accurate pointing device under the sofa cushions...what if yes, I have finger+stylus, but my stylus is currently under that same sofa cushion? > Just like not every click target is tiny on desktop screens, pointer responding to fine does not mean you have to make everything tiny, But by its very definition that's what you're saying though. Are you suggesting that authors would check for `pointer:fine` but then ignore it? What's the point of that, then? And if so, the spec needs a clear note in the `pointer`/`hover` section which is essentially says the same thing as the note you have in the `any-*` part. So if you have ``` Designing a page that relies on hovering or accurate pointing only because `any-hover` or `any-pointer` indicate that an input mechanism with these capabilities is available, is likely to result in a poor experience. ``` you also need the same to be said for `pointer`/`hover` ``` Designing a page that relies on hovering or accurate pointing only because `hover` or `pointer` indicate that (whatever the OS/UA decided is) the primary input mechanism has these capabilities, is likely to result in a poor experience (as it ignores the fact that secondary input mechanisms may be available that lack these specific capabilities). ``` > just that you can when you want to without making everything unusable. But you are making it unusable if the user is using that input you/the OS/the UA deemed "rare". You're saying "hey, it's not unusable...just stop using the input you're using just now, because we know best, so you should switch from that input to what we decided is the primary one". Again, a user-unfriendly (bordering perhaps on patronising) approach. > Here's the way I think about this: > > - If `(pointer:fine)` is true, it is ok to use small click targets. Doing so will not inconvenience the user either by asking them to do fine movements with a device unsuited for that, nor by forcing them to reach out for some optional peripherals. It will inconvenience the user if they're currently not using what is deemed as the one true primary input mechanism. You're forcing them to stop using whatever "optional"/secondary input mechanism they're currently using for whatever reason (maybe because they dropped their stylus behind the proverbial sofa? or because their RSI kicked in and instead of using their mouse they're using their laptop's touchscreen, or ... any other scenarios that you/the OS/the UA has no way of determining). > - If `(pointer:coarse)` and `(any-pointer:fine)` is true, the above "should generally stay away from small click targets" is right, as accurate clicking will be doable even if it is an inconvenience. True, but this is based on the intrinsic value judgement of this mythical *primary* input. The more robust and user-friendly rationale/conclusion in my mind would be: "If `(any-pointer:coarse)` and `(any-pointer:fine)` are true, the user has at their disposal both coarse and fine pointers. I have no way of knowing which one they're using just now, which one they may switch to, which one they prefer, which one is actually more convenient for them in their current situation (sofa/RSI/etc), so the safest option is to make sure my interface works for all possible input types the user has currently at their disposal". > - Same logic for `(pointer:none)` vs `(pointer:none)` and `(any-pointer)`. `(pointer:none)` tells you to design something that works without clicking, and (any-pointer) tells you whether that's a should or a must. This is a strong outlier, which depends on what you envisage happening when `(pointer:none)`. Are you expecting authors to, when that evaluates to true, remove any form of "clickability" (and instead do something like just listening to `keydown`/`keyup`/`keypress`)? And can this not be also addressed by simply doing checks for just `any-pointer`? - if `(any-pointer:none)` evaluates to true and both `(any-pointer:fine)` and `(any-pointer:coarse)` evaluate to false, there's no need for "clickable" things - if `(any-pointer:none)` evaluates to true and `(any-pointer)` also evaluates to true, make sure your interface works both for pointers and for non-pointers No need for a value judgement of "but what is the *primary*?". You're ensuring that if the user does have a non-pointer input at their disposal, an author can query for that and make a judgement on whether or not they want to also include non-pointer input functionality (such as listening explicitly to `keydown`/`keyup`/`keypress`). > Similarly, `(hover:none)` tells you that the user is unlikely to discover that things can be hovered and even if they knew, they may have a hard time interacting with them. `(any-hover)` tells you whether they have a way to bypass that. Assuming I'm on a device which does have both a hover-capable mouse and a non-hover capable touchscreen, and I land on your site/app while I'm using the touchscreen. My mouse is by my side, but I am currently purely interacting with my touchscreen because...well, because I want to. How am I now more "likely to discover that things can be hovered"? Unless I actively switch back from my touchscreen to my mouse (and mutter something under my breath about "[expletive] designer making assumptions that mouse is my primary input..."), I may never actually "discover" that there's hover-specific functionality. I may in fact find that the site/app simply isn't working properly for me, and leave. And again, this is due to the intrinsic value judgement of *primary* input and that my using the touchscreen is somehow a rare quirk. Instead, just as with the above reframing of `(any-pointer)`, as an author I can make a judgement myself: - if `(any-hover:none)` evaluates to true but `(any-hover:hover)` also evaluates to true, I know that the user has at least one means of invoking hover. Now I as an author can make a choice...do I take this information and decide that my site/app should forego any hover interface (which will still work just fine for mouse etc users, so covers all input modalities)? Or do I politely put a notice up on my page saying "This functionality requires you to pick up your hover-capable device, sorry about that"? Or do I offer the user an explicit switching mechanism, the same exact way that for instance Microsoft Office does when on a touch-enabled laptop? (see file:///D:/github/patrickhlauke/getting-touchy-presentation/index.html#137) The decision making is still with me, the author, but I can make the exact same value judgement myself, and not rely on the OS/UA to somehow magically work out that one of the inputs is *primary* and therefore *better*/*more likely to be used*. - if `(any-hover:none)` evaluates to false, great...I can rely on hover-based functionality to my heart's content (until a user attaches a secondary input, e.g. using a KVM switch to flip over to their touchscreen monitor, at which point a good site/app would detect this change and offer a dialog a la "it seems you've added a non-hover capable input..." and then follow any of the approaches outlined in the previous bullet point) > So in my mind, it's the any-* variants we may be able to do without, as they are expressing a nuance over the more generally useful information. Again, "nuance"/"generally useful" is an value statement that, in my mind, is simply not there anymore in a multi-input world. You're still trying to boil all possible inputs at a user's disposal down to "well there's the *primary*, and then lots of other stuff which is possibly nice to consider but maybe not, and even if we ignore it it's fine users are likely to just use *primary* anyway". > The continued disagreement on this topic makes me wonder > > - Does spec do such a poor job of explaining the logic between this primary / secondary input mechanism that people tasked with implementing it misunderstand what they're meant to do, and instead are at risk of implementing something different that's not nearly as usable? > > - Are the WG or Tab and I oblivious to the fact that the way we want these features implemented is not possible, and that what can be implemented isn't nearly as useful? > > - Are the WG or Tab and I oblivious to some use cases or some devices where the feature as designed falls short of what authors need to do a good job? In short, my disagreement is quite fundamentally with the fact that the spec makes a hard distinction between *primary* and "rare" input mechanisms. As increasingly we're seeing multi-input devices, this hard distinction is becoming hazy. This results in ever-increasing need for somehow rationalizing things back down to a single input as being primary (see for instance how you had to somehow interpret the "finger+stylus" scenario in order to arrive to your personal conclusion that "stylus" is this really the primary). Beyond that, there's language such as "rare" which is rather loaded terminology. You're making a judgement here in the spec which you (nor the OS or UA) is in any position to make. This is further compounded by your apparent value judgement (for instance your "dumbing down" comment) in explaining why the spec steadfastly insists that one input *must* be the *primary*. And then there's the assumption that because one input is *primary*, it will never be inconvenient to require the user to use that, regardless of which input mechanism they're currently using. Again, the spec, the OS, the UA, and the author/developer are in no position to make that particular assessment, and it is user-hostile to assume that it's ok to ignore the input mechanism the user might be currently using because it's not the "right" (primary) one. > I am suspecting 1, but you sound like you're on 3. Which is why I think that a few concrete examples would help sort things out. If you can show a few concrete designs, what you would like to do on particular devices, how you'd try to code them up, why it fails to do what you'd hope, we should be able to sort out whether it doesn't work due to a unclear spec leading to misunderstanding about how `pointer`, `hover`, and `any-*` are supposed to work, or because the way they're supposed to work does overlook some key situations. I believe the spec is perfectly clear in expressing your intended approach, and I simply disagree with the underlying principle of your approach. My scenarios are, as mentioned throughout, the situations where a user has multiple inputs at their disposal, that they choose for whatever reason to use a particular input, and that because it's not what the OS/UA deems to be *primary* it's ok to ignore them. Couple this with the fact that I don't believe that if an interface is adapted to `pointer:coarse` and `hover:none`, it's "dumbed down". It works just fine even if a user has another input with is fine/hover-capable. Whereas the opposite is not true. -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/690#issuecomment-259100457 using your GitHub account
Received on Tuesday, 8 November 2016 10:26:16 UTC