iPad onscreen keyboard designed for LaTeX [video](texpadapp.com)
texpadapp.com
iPad onscreen keyboard designed for LaTeX [video]
https://www.texpadapp.com/blog/ios-v1.6.3-teaser
16 comments
This is simply a great example of using the wrong tool for the job. No matter how "smooth" an iOS LaTeX tool is, it's still much less efficient than any computer. People are trying to force things into the iPad, which I understand, but I sincerely think that a radical change is needed to make it more than a consumption device.
(Disclaimer: I'm part of the Texpad team.)
I agree that a lot more needs to be understood and imagined about how we may use the touch devices, but radical changes don't have to be radical on day one. Indeed, from experience radical changes fail precisely because users can only absorb so much change in one go.
As it turns out when you take the touch interface into account as our iOS 7 app does, you can do some sweet things. My personal take is that you experiment with the interface _while_ making sure you don't break the existing ways of inputting (= generating content). If you shove a lot of change down people's throats in one big spoonful, you alienate them. Evolving the UI means you can take user feedback and adjust the course on the way. Radical changes mean you assume you know exactly what they want and need (and you don't mind breaking their workflow to impose the new way). That's a big assumption and may appear a little presumptuous to users who've developed a workflow around your app.
We may not get it right completely in one go, but we can assure our users that the app is the product of their feedback and will continue to be.
I agree that a lot more needs to be understood and imagined about how we may use the touch devices, but radical changes don't have to be radical on day one. Indeed, from experience radical changes fail precisely because users can only absorb so much change in one go.
As it turns out when you take the touch interface into account as our iOS 7 app does, you can do some sweet things. My personal take is that you experiment with the interface _while_ making sure you don't break the existing ways of inputting (= generating content). If you shove a lot of change down people's throats in one big spoonful, you alienate them. Evolving the UI means you can take user feedback and adjust the course on the way. Radical changes mean you assume you know exactly what they want and need (and you don't mind breaking their workflow to impose the new way). That's a big assumption and may appear a little presumptuous to users who've developed a workflow around your app.
We may not get it right completely in one go, but we can assure our users that the app is the product of their feedback and will continue to be.
I don't know if I agree with the notion that the iPad is good solely for content consumption. If you ever have to write in a foreign language, you will note that it is much easier to write on the iPad thanks to terrific internationalization support in the form of language specific auto-correct and virtual keyboards that do things normal keyboards can't (like pressing on a key for a second and getting several accented characters). I have always wanted to write an APL interpreter for iPad because dealing with the APL glyphs on the iPad keyboard would theoretically workout nicely. I have not tried texpad, but their use of customizable virtual keyboards certainly looks promising.
> If you ever have to write in a foreign language, you will note that it is much easier to write on the iPad thanks to terrific internationalization support in the form of language specific auto-correct and virtual keyboards that do things normal keyboards can't (like pressing on a key for a second and getting several accented characters).
Language-specific autocorrect is common in desktop software that has autocorrect at all (e.g., wordprocessors) and, similarly, good access to international characters through methods faster than press-and-hold is pretty common in lots of desktop software.
Press-and-hold is a slow, clumsy approach that's only tolerable with a virtual keyboard because virtual keyboards are already so slow and clumsy that its not a big marginal cost.
Language-specific autocorrect is common in desktop software that has autocorrect at all (e.g., wordprocessors) and, similarly, good access to international characters through methods faster than press-and-hold is pretty common in lots of desktop software.
Press-and-hold is a slow, clumsy approach that's only tolerable with a virtual keyboard because virtual keyboards are already so slow and clumsy that its not a big marginal cost.
Press and hold is slow, but the visual feedback is immensely useful.
I find myself using the Character Map (or Keyboard Viewer) all the time, because the keystrokes required aren't intuitive, and aren't labelled on my physical keyboard.
So for some users, press-and-hold on "e" to get é is far more efficient than having to open up a separate application entirely.
For that matter, I really like OS X's approach where you can use either input method.
Likewise, you can always switch to the specific language's keyboard on iOS, and press and hold is similarly obviated.
I find myself using the Character Map (or Keyboard Viewer) all the time, because the keystrokes required aren't intuitive, and aren't labelled on my physical keyboard.
So for some users, press-and-hold on "e" to get é is far more efficient than having to open up a separate application entirely.
For that matter, I really like OS X's approach where you can use either input method.
Likewise, you can always switch to the specific language's keyboard on iOS, and press and hold is similarly obviated.
> I find myself using the Character Map (or Keyboard Viewer) all the time, because the keystrokes required aren't intuitive, and aren't labelled on my physical keyboard.
I don't know, I've always found the Word keystrokes intuitive (in fact that I was able to discover most of the ones I needed for French and Spanish by learning one and generalizing from there), and my main frustration in that regard is that they aren't standardized for text input in Windows.
As for labelled -- if I have to look at my keyboard to type, that's too much of an efficiency killer to start with.
> Likewise, you can always switch to the specific language's keyboard on iOS, and press and hold is similarly obviated.
Except that its generally not; even with the Spanish keyboard, you still need press-and-hold to get to the vowel accents.
I don't know, I've always found the Word keystrokes intuitive (in fact that I was able to discover most of the ones I needed for French and Spanish by learning one and generalizing from there), and my main frustration in that regard is that they aren't standardized for text input in Windows.
As for labelled -- if I have to look at my keyboard to type, that's too much of an efficiency killer to start with.
> Likewise, you can always switch to the specific language's keyboard on iOS, and press and hold is similarly obviated.
Except that its generally not; even with the Spanish keyboard, you still need press-and-hold to get to the vowel accents.
You're correct. It's not ONLY good for consumption, it's just a low-fidelity, low-bandwidth input device. Touch does have the advantage of feeling natural, so that probably lends itself to a better input device in specific scenarios. Still, I can't help but pine for a future iPad on which I can use a pen. Whoa!
> virtual keyboards that do things normal keyboards can't (like pressing on a key for a second and getting several accented characters).
Can't, or don't? Repeating keys isn't all that useful, and a different behavior could certainly be implemented in software.
Can't, or don't? Repeating keys isn't all that useful, and a different behavior could certainly be implemented in software.
OS X actually does this now. You get a little pop-up when you hold down e(èéêëēėę) for example and press a number to choose. It's efficient enough if you don't type them often enough to remember the alternate keystrokes. (option something something)
It actually doesn't work well in TeX because it depends on having the correct input encoding set, which still breaks when you have multiple collaborators. Though \:e for ë is pretty easy to remember.
It actually doesn't work well in TeX because it depends on having the correct input encoding set, which still breaks when you have multiple collaborators. Though \:e for ë is pretty easy to remember.
A radical change like, say, innovation in the touch keyboard? Even if this is just incremental progress, it's pretty neat.
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!
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!
I 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.
When will iOS stop using the most ineffective keyboard in touch screen keyboards??
Every time I have to type in my Wifi password on someone's iOS device I cry. Not knowing if the letter is capital or lower-case is a killer and the symbol division of two screens is mind blowing; + and = is on page two!
I can't hold down on a letter to select numbers or symbols is also crazy. Not being able to slide also is crazy.
TL&DR Apple's iOS on screen keyboard is the worst!
Every time I have to type in my Wifi password on someone's iOS device I cry. Not knowing if the letter is capital or lower-case is a killer and the symbol division of two screens is mind blowing; + and = is on page two!
I can't hold down on a letter to select numbers or symbols is also crazy. Not being able to slide also is crazy.
TL&DR Apple's iOS on screen keyboard is the worst!
This app looks very nice. It actually makes me want to get started in learning LaTeX. The autocomplete is a very nice feature, and the cursor manipulation is genius. I can't emphasise how much I'd love to have the default apple keyboard have cursor controls.
And one day I might actually get started learning it. Right after all the other things on my list...
And one day I might actually get started learning it. Right after all the other things on my list...
It looks great! of course if I want to type actually in LaTex. I find it much easier to work in an environment like LyX, which you don't have to think LaTeX and focus on big picture, and if necessary get down to TeX level.
Nevertheless, the navigation/selection idea looks really handy.
If you ever need easy LaTeX generation for data generated or changed in Python. You should try out https://github.com/JelteF/PyLaTeX.
It supports tables, plots and matrices. All with sane defaults.
Could be great for note taking. Once upon a time, I used to be able to think about math in terms of LaTeX expressions pretty fluidly. It's been awhile since I've really had to use TeX heavily though.
Their Mac App is great: I've used perhaps a dozen LaTeX editors on many platforms and it is probably my favourite. Nice autocomplete, great preview pane, good navigation between files and a very clean interface.
If you are on Windows there is a slightly obscure one called InLage that is excellent (basically Visual Studio for LaTeX).
With this new keyboard I may have to try their iPad app.
If you are on Windows there is a slightly obscure one called InLage that is excellent (basically Visual Studio for LaTeX).
With this new keyboard I may have to try their iPad app.
At 0:28 when "\oplus" is inserted into the file, the key actually pressed is a filled circle. If the key you have to press doesn't look like the symbol you're trying to insert, that means you have to learn yet a new name for the symbol...
Thanks, I just checked the app, but that is a compression artefact. In the raw video it is clear, but not in that version.
We will use a more compressible symbol next time around.
We will use a more compressible symbol next time around.
Oh, that makes sense. I should have figured that was it.
That is amazingly clean! I've been using Textastic, but this looks worth a try!
Amazing and exactly what I've been looking for. Any plans for an android port?
Not in the next few months, but yes, we should start work on windows/android versions of Texpad sometime this year. We want to perfect the OSX/iOS versions versions first, abstract the common editing codebase, etc. etc. then tackle some new platforms
Their OS X app is also quite good: https://www.texpadapp.com/osx
Much nicer than the open source competition, to be honest.
Much nicer than the open source competition, to be honest.
That looks beautiful. Really nice job on the custom keyboard.
The keyboard looks great in the video. Is version 1.6.3 already on the AppStore? If not, (I only find v1.6.2) is there an ETA?
Hopefully early next week. We are fixing bugs uncovered during the beta period right now, and we hope to submit it to the App Store at the end of the week.
I actually use LaTeX on my phone quite often. I would use this if I weren't an Android kind of guy.
Really? Maybe I'm an old-skool kinda guy, but I can't fathom using a tablet or phone to do LaTeX work. I do lots of it, and I can't imagine doing it without a keyboard and vim-latexsuite.
How do you get over all the shifts- and alts- on the Android keyboard to get \ and { and all the other stuff?
How do you get over all the shifts- and alts- on the Android keyboard to get \ and { and all the other stuff?
(Disclaimer: I'm one of the people behind Texpad.)
Keyboard is designed to address precisely these kind of issues. I'd recommend watching the video.
Keyboard is designed to address precisely these kind of issues. I'd recommend watching the video.
I'm just guessing, but i can't see any way any custom app could be more efficient than a well tuned emacs.
I'm interested in seeing the same approach taken for programming.