Hacker News new | past | comments | ask | show | jobs | submit login

> One of my biggest questions: "Does this device have a keyboard?" (relevant for "should I show hints for keyboard shortcuts?") is still straight-up unanswerable, and all I can do is guess from the UA.

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.






> 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.

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.


Agree. Also with a physical keyboard (PC) you can filter keypress events in an <input>, but with a virtual keyboard (Android) you cannot (keycode is always 0 due to IME).

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).


Please stop trying to do the browser developers' job. If focusing the input field opens the keyboard, that's the correct behavior, whether you agree with it or not.

> 19-year-old advice that remains useful: https://www.w3.org/QA/Tips/noClickHere

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."


I'm moderately annoyed you think I don't already know all these things.

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'm moderately annoyed you think I don't already know all these things.

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.


I think the thrust of GPs argument is "Before they take away the UA string (the one clumsy tool that I can use to half-accomplish my goals) I wish they'd add official APIs to detect these kinds of things".



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: