6 ms·

New browsers still don't support everything. One of my biggest questions: "Does this device have a keyboard?" (relevant for "should I show hints for keyboard sh

by Zarel 7y ago

New browsers still don't support everything. 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. Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.

jchw 7y ago
Ideally, imo, most sites should use the web platform as intended and their sites will work fine regardless of input device. 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.)
- Zarel 7y ago
  I know, that's why I said "unanswerable" and "all I can do is guess". 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 「ち」.
phkahler 7y ago
>> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc 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.
- Zarel 7y ago
  Because I still believe in the ideals of responsive web design. If a desktop user wants to use my site in a tiny window (maybe to tile it next to another window), they should still be able to use keyboard shortcuts. And if a user with a large screen wants to use touch interaction (maybe they have a Surface Studio), they should be able to. There's no reason to make multiple sites each with their own flaws, when you can just make one site that can do anything.
JoshTriplett 7y ago
> 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 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.
- shadowgovt 7y ago
  > 19-year-old advice that remains useful: https://www.w3.org/QA/Tips/noClickHere 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."
- Zarel 7y ago
  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 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!
mikewhy 7y ago
> should I tell the user to tap 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.
- true_religion 7y ago
  Mobile browsers are space constrained so although you can drag and drop, practically speaking if your drop target is off screen, it’s a poor user experience.

by Zarel 7y ago

jchw 7y ago

Ideally, imo, most sites should use the web platform as intended and their sites will work fine regardless of input device. 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.)

Zarel 7y ago
I know, that's why I said "unanswerable" and "all I can do is guess". 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 「ち」.

phkahler 7y ago

>> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc 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.

Zarel 7y ago
Because I still believe in the ideals of responsive web design. If a desktop user wants to use my site in a tiny window (maybe to tile it next to another window), they should still be able to use keyboard shortcuts. And if a user with a large screen wants to use touch interaction (maybe they have a Surface Studio), they should be able to. There's no reason to make multiple sites each with their own flaws, when you can just make one site that can do anything.

JoshTriplett 7y ago

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

shadowgovt 7y ago
> 19-year-old advice that remains useful: https://www.w3.org/QA/Tips/noClickHere 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."
Zarel 7y ago
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 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!

mikewhy 7y ago

> should I tell the user to tap 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.

true_religion 7y ago
Mobile browsers are space constrained so although you can drag and drop, practically speaking if your drop target is off screen, it’s a poor user experience.