It’s increasingly common, particularly among groups such as education, with students for note-taking and middle/senior managers (aka key decision makers). The CTO who reverted to email after having problems posting from tablet/keyboard ultimately opted not to take that particular pilot into full service, deeming Discourse as not fully mobile-ready.
Personally I’ve been using a tablet with keyboard for about 4 years now. Because of this issue Discourse is one of the few things I don’t use it for.
I feel like anyone truly committed to tablet+keyboard is using a laptop. Everyone else are basically … dilettantes. It’s just hard to take them seriously.
That said I’d indeed love to see better Mobile Safari support for detecting hardware keyboard, as in ANY SUPPORT WHATSOEVER.
The theme component @sam proposed is not a bad idea, either, given the rarity of the use case.
While I was just praising the support of the Discourse team, if you’re going to insult your engaged, serious customers to their face then I can’t really stand behind that anymore, can I? Seriously, this is incredibly unnecessary.
On the topic itself though: I was at the SaaStr conference in San Jose the other week, with thousands of founders/leaders of tech companies. My rough estimation was that ~20% were using iPad Pro with an external keyboard. Even if someone’s not as exclusively “committed” as I am to it, there are moments you really want to post longer things on the iPad. Like in this case, during downtime of conferences where you’ve had 200 new great ideas that you want to share with your team. Or when traveling, coffee shops, etc.
Again, I realize this doesn’t represent your typical user persona but I suspect it represents your buyer persona so it’s an interesting trend to take a look at.
Anyway, I feel a little disheartened and feel like I’ve now given you my full take here, so I’ll leave it here.
That’s the problem with telling the truth: you may offend people.
Truth is, this is a really niche and narrow use case — iPad with physical keyboard. The whole point of the iPad is that you only need the screen and the keyboard appears on demand. Giving that functionality up, and mating the iPad with a permanent keyboard … honestly you are much better off with a laptop.
As I said I am definitely interested in fixing this, but sadly Apple has been spectacularly unresponsive, and only they can truly fix this problem, by exposing the presence or absence of a physical keyboard to Mobile Safari.
My suggestion is to avoid Discourse (or any other web based app for that matter) and use only native apps exclusively if the keyboard + iPad is going to be a large part of your audience.
The other option is a theme component.
(Oh and to be clear I love my IPad Pro 12.9” and I use it literally every day with Discourse.)
It is still mega awkward because iOS has no concept of tabbing to controls and ctrl+enter to submit a reply does not work at all. But most of the keyboard shortcuts seem to work fine.
I just re-tested. There is no sane way of detecting hardware keyboard on iPad. Ziltch.
Theme component that allows user to disable our hacks is the only sane solution I can think of.
In fact @codinghorror if we play a bit of an early adopter here how would you feel about:
IF you are using an iPad/iPhone
AND you visit /username/preferences/interface
Have a checkbox for [ ] I am using a physical keyboard
Technically this should be called
[ ] Do not apply iOS specific hacks to the composer cause Apple can not get positioning fixed to work correctly
It is a safe way of disabling all the hacks, and technically we need none of these hacks in Android and the long game is that if Apple gets its act together we will not need it on Apple devices.
Long term I do see more people on iPad + Keyboard and skipping the whole laptop thing. But yeah it is quite rare at the moment.
This is a nice writeup about the problem, though I have no way of reproing that window.innerHeight works properly. Seems totally bust to me even if I set this interval. (It kind of starts working sometimes, but I can not figure out any consistency here)
setInterval(() => {
let h = window.innerHeight;
window.alert(h + "");
}, 10000);
@codinghorror I do think this setting belongs in core though, cause it only shows up on iOS and ONLY removes hacks, so it also allows us to quickly test if a new iOS is less broken (though I am not holding my breath here)
