Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.
Mobile devices have keyboards. If you mean "does this device have a physical keyboard", you don't need to know that. If you mean "does this device have modifier keys like ctrl and alt", someone might have hooked up a bluetooth or USB keyboard to their mobile device.
If you're on a large screen, show hints if you have room. (You might also show such hints in tooltips, as devices with a concept of "hover" correlate well with devices where keyboard shortcuts make sense.) If you're on a small screen, provide a way for people to get those hints anyway via a help option.
> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.
19-year-old advice that remains useful: https://www.w3.org/QA/Tips/noClickHere
You can't tell from the user-agent if, for instance, someone might be using a screen-reader or other assistive technology, or otherwise using an interface you don't expect. Tell people what option/link to use, not how to activate it. Help them out with things like highlights, or tours, or sample videos.
I'll take the liberty to say yes, that is what they mean, and that is their point: there is no way to detect whether those keys are available, so the best we can do is guess.
And yes, I might actually need to know whether there is a physical keyboard or not. For example, do I auto-focus the input field? For devices with OSKs, the keyboard will pop up right away and obscure most of the site on mobile. For devices where the OSK won't pop up, I want the focus to land there immediately for usability.
A time entry input is a good example: on the PC you can accept valid [0123456789:.APMapm] characters as the user types, and have the HTML page do something sensible and show something sensible. On Android you either have an ugly time picker (they are all ugly!) or use hideous workarounds to try and detect keypresses.
Android and iOS have `inputmode=` but it is very restricted and there are wierd and sometimes incompatible differences between browsers or browser versions or OS versions. Custom data entry (e.g. time, date ranges, etc) is super ugly in HTML.
I have found many browser version and device specific bugs with virtual keyboards or PC keyboard entry that cannot be "feature detected" (browser version must be sniffed).
Ah, my favorite aspect of the w3c process: responding to the need for perfectly reasonable UX discoverability for users unaccustomed to using browsers with "You don't actually want to do that."
There's a reason so much of the web development world considers the documents they make to be "take with a grain of salt and do what works for your users."
The problem isn't that I don't know these things, it's that I'm beyond those things and trying to add subtle things to improve quality of life.
> Mobile devices have keyboards. If you mean "does this device have a physical keyboard", you don't need to know that. If you mean "does this device have modifier keys like ctrl and alt", someone might have hooked up a bluetooth or USB keyboard to their mobile device.
Yes, and this makes the experience on mobile devices worse!
On a laptop, if you open Discord, click on your friend's name, and start typing, you'll send your friend a message.
On an iPad with a keyboard, if you open Discord, click on (tap) your friend's name, and start typing, nothing will happen.
You say "there's no way to detect an iPad with a keyboard" like it's a good thing, but it's clearly a bad thing!
I go over a similar problem here: https://news.ycombinator.com/item?id=22047246
> If you're on a large screen, show hints if you have room. (You might also show such hints in tooltips, as devices with a concept of "hover" correlate well with devices where keyboard shortcuts make sense.) If you're on a small screen, provide a way for people to get those hints anyway via a help option.
This is clearly a worse experience for the user because it means hints are shown to users for whom they make no sense.
Like, yes, that's what I currently do, and it sucks.
> You can't tell from the user-agent if, for instance, someone might be using a screen-reader or other assistive technology, or otherwise using an interface you don't expect. Tell people what option/link to use, not how to activate it. Help them out with things like highlights, or tours, or sample videos.
There aren't ways to detect if someone is using a screen-reader, but there are plenty of W3C ARIA tags screen-readers understand, which, if used correctly, can improve quality of life for them. I get a lot of feedback from screen-reader users that they love my graphical online video game, because I went out of my way to improve quality-of-life for them.
And now, I want to improve quality-of-life for users on iPads, and you tell me "no! everything must be the same on everything!" No! I refuse to accept that!
GitHub has a hint in their comment boxes that you can attach files by drag/drop or pasting. That's the sort of thing I'm talking about. It's miles away from a button labeled "click here". There's no need for this smarmy "don't tell the user how to activate a feature". Some features are subtle and need hints!
I was not suggesting you didn't, but more than one person will read this conversation.
> This is clearly a worse experience for the user because it means hints are shown to users for whom they make no sense.
Or to users for whom you don't know that they do make sense. If you guess incorrectly that a device doesn't have a keyboard when it does, you'll prevent users from discovering your keyboard shortcuts.
I would also suggest that web standards need to improve, to make it easier to help figure out which hints to offer. For instance, I think it would be perfectly reasonable to offer a mechanism to detect "should I show hints for keyboard shortcuts", which desktop browsers would always enable, and mobile devices would enable if they have an attached keyboard or if the user is using another mechanism that might allow for shortcuts. And one day, perhaps we'll have a standard for keyboard shortcuts that will allow users to remap those shortcuts and allow the browser to provide "native" hints that those shortcuts exist.
I'm not trying to suggest that the current state is ideal, or that it can't be improved. I'm suggesting that user-agent-based detection is in some ways worse.
> no! everything must be the same on everything
That's not what I said. I'm suggesting that everything should be accessible on every platform. You might well make adaptations and hints based on screen size, or based on whether the user has previously typed keys directly at something other than a text box; just don't make assumptions the user can't work around or change if you've detected them incorrectly. I've dealt with sites that force the use of mobile if they catch the slightest whiff of "this might be a mobile device", and the mobile experience is far less capable. (That's leaving aside the anti-pattern of "are you sure you want to use a web browser instead of our app?".)
Personally, I would suggest detecting if someone "types at" the page without being in an input box, and offering to not only focus the input box but set a device-local preference to automatically do so in the future.
If you are using UA sniffing to determine if the device has a keyboard it will be wrong a lot of the time; you can’t tell if a Microsoft Surface has the keyboard attached or an iPad doesn't. you’d probably be no worse off trying to detect it by screen width, which is already a defacto way to detect mobile devices anyways, for better or worse.
(The right solution is probably a new kind of API or media query.)
The specific feature this came up recently is whether or not a chat app should autofocus the input box. Ideally, the answer is "yes" if you have a keyboard (lets you start sending messages faster) and "no" if you don't (the on-screen keyboard would cover up the conversation and be distracting).
There's, of course, no way to detect an iPad keyboard, so currently iPads miss out on autofocus.
Discord, incidentally, uses an alternate solution: "don't autofocus the textbox, but instead detect keypresses outside the textbox and manually insert the corresponding letters in the box". This, of course, completely fails for various non-Latin keyboards, such as Japanese: if you type "chi", it will insert 「cひ」 instead of 「ち」.
I always use the term "tap". MacBook / Magic trackpads literally have an option called "tap to click".
> should I tell the user to drag-and-drop
Both mobile and desktop support drag and drop, so not sure why you'd want to disable it for either.
Why are you doing all that? Just offer the desktop version or Mobil version and be done with it. You dont need to figure out dev_caps in such detail.
There's no reason to make multiple sites each with their own flaws, when you can just make one site that can do anything.