6 ms·

I'm surprised the conversation here is focused on whether Dvorak is useful on mobile (with - unsurpisingly - many differing opinions) rather than the issue of o

I'm surprised the conversation here is focused on whether Dvorak is useful on mobile (with - unsurpisingly - many differing opinions) rather than the issue of openness. Why don't iOS and Android allow plug-and-play layouts with their built in keyboards? It would be low complexity and put power/accessibility back into the hands of users.

scaredginger 4y ago
Most of us agree that we like open systems; it's also well established that certain companies have a tendency to design closed systems. What do you think needs discussing here that hasn't already been discussed in hundreds of other HN threads?
- jobs_throwaway 4y ago
  Why is OP expected to have participated in or read hundreds of other threads?
danpalmer 4y ago
I think it's much higher complexity than you may be giving it credit for. Each of the keyboards is likely "hand-positioned", or there must be a very complex rules engine to cope with the myriad screen sizes, layout row and column count, the fact that columns are staggered, plus the hover behaviour for extra symbols, and that's not even counting things like Pinyin inputs or swipe inputs for symbol based languages. Oh and then there's the ML models for predictive text, spelling correction, key hit box detection, and swipe typing. All this complexity means that you essentially need UI and logic to implement keyboards in the general case, and both platforms allow for third party keyboards, albeit with tight security controls given their privileged position.
- jenny91 4y ago
  There are so many keyboard layouts for different countries and variations thereof. I very much doubt it's hand-positioned. The layout is not that hard, you can use a fairly straighforward linear constraint solver to lay it out on various different screen sizes. Surely at this level of localization it's more than an afternoon's worth, but I it's not hard in the grand scheme of things.
  - danpalmer 4y ago
    Maybe it's not quite hand-positioned for every screen, but with the level of detail necessary in the constraints for a constraint solver to be able to do it, I think that might as well be considered hand-positioning in some sense. Also, it's only anecdotal, but in ~10 years of installing day-1 betas of iOS, I've yet to see an autolayout bug on the keyboard. Admittedly I'm using British English which I'm sure sees a lot of QA testing, but incorrect constraints would probably be a hot spot for issues, and I've seen autolayout bugs in a ton of other software, so my guess is still that it's not really that automated.
    - azinman2 4y ago
      What makes you assume the keyboard is built with auto layout? It’s optional and adds overhead.
- snazz 4y ago
  I think this is it. There are a bunch of tiny details in the iOS soft keyboard that make typing more accurate and I bet a lot of the behavior is hard-coded. For example, if you use the split keyboard layout on the iPad and you try to hit the Y key with your left thumb even though it’s on the right side keyboard, the software will fudge it to make it work anyway. If you shift your thumbs while you’re typing and suddenly you’ve crossed the border onto another key, it seems like it shifts the hit boxes slightly to compensate (I’m not sure how to reproduce this one 100% of the time though).
- beebmam 4y ago
  It's not THAT hard. The problem is that very few people use alternative keyboard layouts. In proprietary software/hardware, there's just not a lot of incentive to satisfy the needs of small minority of users. In the open source world, at least there's the possibility that individuals in these minority communities would be willing to make changes.
WirelessGigabit 4y ago
They do. You can build custom keyboards for both. It’s just that this is native iOS, which is important because iOS allows disabling custom keyboards in certain contexts (passwords) or completely.
- spiffytech 4y ago
  I've tried several 3rd party Dvorak keyboards for iOS and they all feel subtly broken. It gave me the impression that making a 3rd party keyboard feel good must take a lot of work, effort which doesn't get put in when the goal is just enabling a single layout.
deleted 4y ago
[deleted]
bjelkeman-again 4y ago
I just want simple things as having the keyboard layout on iOS and iPadOS to actually be the same. On 15.6.1 on both devices, the international keyboard key and the shift key has switched place in the different OSs. So I always end up hitting the wrong key for shift/change keyboard. This is a fairly basic and stupid design bug.
paxys 4y ago
Isn't allowing third-party keyboards with any layout they want the definition of openness? You could always have Dvorak on iOS. Why does it need to be natively supported?
tadfisher 4y ago
Android does! The API is quite esoteric, but I've built a custom layout before for the Pixel C, way back when. You ship a special XML layout file in your APK that gets picked up by the input framework.
- ledauphin 4y ago
  it seems like this is a per-application setting rather than a per-user setting? which would almost entirely negate its usefulness in my opinion.
  - tadfisher 4y ago
    Nope, the input framework picks up the layout XML from all packages that export a BroadcastReceiver with an Intent filter for the android.hardware.input.action.QUERY_KEYBOARD_LAYOUTS action. However, it looks like I am wrong, and this is only for hardware keyboards, not software IMEs. It looks like there is an API to pass extra data about layout via InputMethodSubtype, but it's basically a key-value map and thus is completely not standardized across IMEs, if any IME even supports redefining the layout through this API.
dmitrygr 4y ago
> Why don't iOS and Android allow plug-and-play layouts with their built in keyboards? It would be low complexity and put power/accessibility back into the hands of users. The worry that said app would find some way to exfiltrate what the user types, perhaps? What with passwords being typed with keyboards and all that.
- jeroenhd 4y ago
  Both platforms have supported custom keyboards for years. I much prefer SwiftKey over the native Android keyboard (with network access disabled, because Microsoft). Sure, password stealing is a potential problem, but you accept that risk the second you decide to download a soft keyboard.
  - dmitrygr 4y ago
    And my grandmother might not know of that risk. Nor do 99% of people out there.
dbbk 4y ago
> Why don't iOS and Android allow plug-and-play layouts with their built in keyboards? If you surveyed 1000 people if they would like to switch from a QWERTY keyboard... I imagine you would get one person say yes. If that.

scaredginger 4y ago

Most of us agree that we like open systems; it's also well established that certain companies have a tendency to design closed systems. What do you think needs discussing here that hasn't already been discussed in hundreds of other HN threads?

jobs_throwaway 4y ago
Why is OP expected to have participated in or read hundreds of other threads?

danpalmer 4y ago

I think it's much higher complexity than you may be giving it credit for. Each of the keyboards is likely "hand-positioned", or there must be a very complex rules engine to cope with the myriad screen sizes, layout row and column count, the fact that columns are staggered, plus the hover behaviour for extra symbols, and that's not even counting things like Pinyin inputs or swipe inputs for symbol based languages. Oh and then there's the ML models for predictive text, spelling correction, key hit box detection, and swipe typing. All this complexity means that you essentially need UI and logic to implement keyboards in the general case, and both platforms allow for third party keyboards, albeit with tight security controls given their privileged position.

jenny91 4y ago
There are so many keyboard layouts for different countries and variations thereof. I very much doubt it's hand-positioned. The layout is not that hard, you can use a fairly straighforward linear constraint solver to lay it out on various different screen sizes. Surely at this level of localization it's more than an afternoon's worth, but I it's not hard in the grand scheme of things.
- danpalmer 4y ago
  Maybe it's not quite hand-positioned for every screen, but with the level of detail necessary in the constraints for a constraint solver to be able to do it, I think that might as well be considered hand-positioning in some sense. Also, it's only anecdotal, but in ~10 years of installing day-1 betas of iOS, I've yet to see an autolayout bug on the keyboard. Admittedly I'm using British English which I'm sure sees a lot of QA testing, but incorrect constraints would probably be a hot spot for issues, and I've seen autolayout bugs in a ton of other software, so my guess is still that it's not really that automated.
  - azinman2 4y ago
    What makes you assume the keyboard is built with auto layout? It’s optional and adds overhead.
snazz 4y ago
I think this is it. There are a bunch of tiny details in the iOS soft keyboard that make typing more accurate and I bet a lot of the behavior is hard-coded. For example, if you use the split keyboard layout on the iPad and you try to hit the Y key with your left thumb even though it’s on the right side keyboard, the software will fudge it to make it work anyway. If you shift your thumbs while you’re typing and suddenly you’ve crossed the border onto another key, it seems like it shifts the hit boxes slightly to compensate (I’m not sure how to reproduce this one 100% of the time though).
beebmam 4y ago
It's not THAT hard. The problem is that very few people use alternative keyboard layouts. In proprietary software/hardware, there's just not a lot of incentive to satisfy the needs of small minority of users. In the open source world, at least there's the possibility that individuals in these minority communities would be willing to make changes.

WirelessGigabit 4y ago

They do. You can build custom keyboards for both. It’s just that this is native iOS, which is important because iOS allows disabling custom keyboards in certain contexts (passwords) or completely.

spiffytech 4y ago
I've tried several 3rd party Dvorak keyboards for iOS and they all feel subtly broken. It gave me the impression that making a 3rd party keyboard feel good must take a lot of work, effort which doesn't get put in when the goal is just enabling a single layout.

deleted 4y ago

[deleted]

bjelkeman-again 4y ago

I just want simple things as having the keyboard layout on iOS and iPadOS to actually be the same. On 15.6.1 on both devices, the international keyboard key and the shift key has switched place in the different OSs. So I always end up hitting the wrong key for shift/change keyboard. This is a fairly basic and stupid design bug.

paxys 4y ago

Isn't allowing third-party keyboards with any layout they want the definition of openness? You could always have Dvorak on iOS. Why does it need to be natively supported?

tadfisher 4y ago

Android does! The API is quite esoteric, but I've built a custom layout before for the Pixel C, way back when. You ship a special XML layout file in your APK that gets picked up by the input framework.

ledauphin 4y ago
it seems like this is a per-application setting rather than a per-user setting? which would almost entirely negate its usefulness in my opinion.
- tadfisher 4y ago
  Nope, the input framework picks up the layout XML from all packages that export a BroadcastReceiver with an Intent filter for the android.hardware.input.action.QUERY_KEYBOARD_LAYOUTS action. However, it looks like I am wrong, and this is only for hardware keyboards, not software IMEs. It looks like there is an API to pass extra data about layout via InputMethodSubtype, but it's basically a key-value map and thus is completely not standardized across IMEs, if any IME even supports redefining the layout through this API.

dmitrygr 4y ago

> Why don't iOS and Android allow plug-and-play layouts with their built in keyboards? It would be low complexity and put power/accessibility back into the hands of users. The worry that said app would find some way to exfiltrate what the user types, perhaps? What with passwords being typed with keyboards and all that.

jeroenhd 4y ago
Both platforms have supported custom keyboards for years. I much prefer SwiftKey over the native Android keyboard (with network access disabled, because Microsoft). Sure, password stealing is a potential problem, but you accept that risk the second you decide to download a soft keyboard.
- dmitrygr 4y ago
  And my grandmother might not know of that risk. Nor do 99% of people out there.

dbbk 4y ago

> Why don't iOS and Android allow plug-and-play layouts with their built in keyboards? If you surveyed 1000 people if they would like to switch from a QWERTY keyboard... I imagine you would get one person say yes. If that.