4 ms·
This is great - I don't write much LaTeX anymore, but I'm excited by where this leads. Apple has long used customized keyboards (i.e. a custom keyboard for URLs
by newhouseb 13y ago
This is great - I don't write much LaTeX anymore, but I'm excited by where this leads. Apple has long used customized keyboards (i.e. a custom keyboard for URLs) and Microsoft is starting to introduce customized hardware Surface input covers as well. It's pretty evident that if you want high-fidelity productivity on a touch screen, you need to adapt your keyboard/input methods to be much more contextual than a general purpose QWERTY keyboard.
The real challenge here is designing OS input APIs that don't by default segment you into all-or-nothing, "use 100% of our keyboard" or "emulate 100% of the text input." Emulating 100% of the text input is fine for ASCII, but there's a bajillion ways to input other languages and you typically simply can't compete with the breadth an OS provides. Windows has some abstractions around presenting word candidates for languages like Chinese that you can render custom, but iOS (and to my knowledge OS X) is pretty miserable in this respect.
Hopefully this is just the beginning!
- coob 13y agoI think the emulating/use native problem for the keyboard is a really tricky design problem to solve. Currently the 'Apple recommended' way is to use an inputAccessoryView which is essentially a bar above the native keyboard. There could be a more elegant solution. However, as you say, the broad spectrum of inputs for different locales makes this a tricky issue.