Live data from Hacker News

Text editing on mobile: the invisible problem

jenson.org

501–510 of 693 posts

Re: Text editing on mobile: the invisible problem

#501
post #2

- Take laptop, remove the keyboard, nerf the OS, call it "mobile" - Wait for someone to point out that text editing is no longer practical - "I am not anti-mobile. My goal is not to return back to the desktop, but to move mobile forward." Why? Why should we privilege an intentionally nerfed computing experience as the inevitable future? Almost every trend "mobile" is pioneering is bad.

Because using my phone while lying down in bed or sitting in my couch is so much more comfortable than using a bulky laptop or personal computer while sitting in a chair. I've written way too much code inside Termux. It's gotten to the point I only use my laptop to edit open street map now. I'm looking for a way to build new Android apps inside Termux itself. Wonder if anyone here's managed it.

I wrote programs on my calculator in high school, an ostensibly narrowly focused device with computing power generously estimated at well under 1% that of your phone, made by a company that didn't really give two shits about their device's programming community.

Therefore, it's hard not to come to the conclusion that if someone as dedicated as you is struggling to write programs for your phone, on your phone, it's because you're being actively discouraged from doing so. Demand better! As a consumer the only voice you have is your wallet. Can you not find a real computer that's comfortable to use in bed?

Re: Text editing on mobile: the invisible problem

#502
post #238

Earlier quoted context omitted.

It’s literally the market that created the BlackBerry, one of the most influential devices of the last 20 years, so yeah it’s a big group.

and yet blackberry went away…

I mean, yeah — because it was replaced by the iPhone. Not because that market shrank or was otherwise invalidated.

Re: Text editing on mobile: the invisible problem

#503
post #497
post #349

The vast difference in editing things on a MicroPC with its touchpad and physical keyboard versus a phone is immense . I'm pretty sure I can legitimately type faster and usually navigate UIs faster on a capacitive touch phone, but the frustration of typing and targeting the cursor is unbelievable even after having used smartphones for over a decade now. It's just bad. It is amusing that it's hard to convince people t…

Every time I pick up my pinephone I feel immense disappointment in what forms of interaction most devices are stuck with today, despite how easily alternatives can be implemented in an open platform as the pinephone has shown. But for just editing text, I find vim and emacs surprisingly usable with a touch keyboard, as long as numbers and needed symbols and modifiers are on the base layer. Precise pointing / fat fing…

I really wish I could bring myself to get into sxmo more. It seems like something I'd like, but I mostly find myself confused when I try to use it. Even if it's not perfectly suckless, maybe it's a bit more in the "suckless" dimension than I can bear--I did like dwm for a while, but I switched to i3wm and later Sway and never really looked back.

There's obviously a lot of small little projects that implement cool ideas, but one thing that is a little bit of a bummer is that there's really no obvious solution that you can flash onto a Pinephone and call it daily-driver ready. It would really be nice if standard-ish Linux desktop environments could be adapted to work well on phones; I mean, at this point, the proof-of-concepts are enticing enough for me to believe that it'd be worth the effort. That having been said, I've been wondering if maybe to get the Pinephone to a working state, if it'd be better to actually go for a very minimal base system and try to build a more or less non-standard usermode. Something like, musl, pipewire, eg25-manager, a custom wlroots compositor that implements most of the actual phone features directly, and some simple system software to go under it (file browser, terminal, etc.) The main thing I really want is to get the absolute best possible battery efficiency, something that can manage rtcwake to occasionally check for notifications and handle some basic alarm clock functionality, and intelligent enough system software to e.g. restart the EG25 when it seems to be stuck. (Usually on Phosh + Debian, restarting the eg25-manager systemd unit is enough, so apparently it'd be good enough to just find a way to detect when it's stuck and restart eg25-manager.) It's a lot of work, and I admit that it feels like you'd be going a tad in the direction of Android by ditching most of the standard userland. But on the other hand, there's so many damn projects involved with most functionality in the device that it is a bit difficult to even know where to start when it comes to troubleshooting, and in my opinion it'd still be nicer than Android if the userland was "standard" enough to still run typical desktop apps and run more-or-less stock kernels.

Then again, for now, I feel my frustration would be better spent trying to debug what's already there. I'm wondering if maybe it would be possible to improve the wake times, for example... I have a sneaking suspicion that most of the resume time is taken before the Linux kernel gains control, but maybe it'd be worth trying to get something like pmgraph running to see if there's any room for improvement.

Re: Text editing on mobile: the invisible problem

#504

This is absolutely a problem, but I'm not convinced the author has found a solution. I'd have to try it to know for sure, but from the description, it still sounds finicky. I believe touch screens are fundamentally a bad interface for productivity. Consider the range of actions provided by a mouse: You can hover without clicking, you can left click, or you can right click, all with nearly pixel-level precision. Add i…

"A smartphone is like a computer with a one-button mouse " Not quite. A touchscreen can detect many fingers, that can do many gestures. The problem is, exept zooming (pinching with 2 fingers) and moving around (swiping with 2 fingers) the potential is pretty much unused.

I have trouble imagining that more than 2-3 fingers can be realistically used for input at once. For one, you normally have to use one hand to hold the phone, which uses up 3-4 fingers. And to enable frequent multi-touch gestures you'd have to hover your hand awkwardly over the phone, which is fine for the occasional pinch-to-zoom but not if you have to do it all the time.

Re: Text editing on mobile: the invisible problem

#505
post #244

Earlier quoted context omitted.

> A few months ago on HN I used text editing as an example of how iOS wasn't ready for "business" use. I can't find the comment now Was it this one? https://news.ycombinator.com/item?id=36536203 >

Yes! -- I'm curious if you had some efficient way to find that?

Front page of HN (or any story page), search box at bottom of page. Enter “gcanyon iOS”. Click on “Stories” and change it to “Comments”. Click on “Popularity” and change it to “Date”.

(Actually I first entered “gcanyon iOS business”, but did not find it.)

Re: Text editing on mobile: the invisible problem

#506

I typed 55wpm on my blackberry without looking. The fact that you have to constantly look at the screen keyboard and correct it is a huge attention suck and kills my input speed On blackberry, a mistake was one wrong character. On screen keyboards with swipe and autocorrect, a mistake can be inserting 1 or 2 random words Screen keyboard doesn't work in the rain while we're griping: - on an older android device the bu…

I think autocorrect is overrated and actually makes the typing process much more annoying. Also I’m not sure if 55wpm is supposed to be fast or not? I just did a typing test (monkeytype.com) on my iPhone and got 80 wpm with 0 mistakes, and I don’t use autocorrect.

1) impressive, 2) try without looking

Re: Text editing on mobile: the invisible problem

#507

So I read this article with my iPad and of course that made me immediately start exploring the text selection within the article - it appears that it has changed in iOS 17 Safari and applies several ideas from the article. * Immediately start dragging. When you pause it immediately enters text selection. If you move slowly you get the loupe otherwise it starts jumping word by word in the text * When you release you g…

I'm the author of the paper. That first one though you called out is VERY interesting (the others seem quite close to what is already done today)

We tried pause-to-select and it user tested very poorly as users were thrown into selection far too easily. It was very irritating. However, I can't really criticize it until I've tried it. I'll upgrade my iPad and check it out. Thanks.

Re: Text editing on mobile: the invisible problem

#508

Earlier quoted context omitted.

Or just shaking your iPhone for undo.

I tried that with an iPad once - if there's a way to do so without looking faintly ridiculous I'm all ears. But I'm an Android person as far as phones go, lack of a standard system wise undo command isn't quite enough to send me back to Apple.

My solution to this would be to enable the Assistive Touch button and set its double tap action to 'shake'. If you don't want the button all the time, create a personal automation shortcut which runs when a specific app opens and closes, setting Assistive Touch on and off as you wish.

Alternatively have Voice Control enabled and say "undo that".

There is also a three finger gesture: https://appleinsider.com/articles/19/06/27/new-ipados-button...

Re: Text editing on mobile: the invisible problem

#510
post #408

Earlier quoted context omitted.

I know about it, but that's a second action (moving it after tapping), or a more difficult one (moving it all the way there via the spacebar touchpad). Most of the time if a tap would put the cursor where I tapped, it'd already be there. Edit: I just discovered now that if you long-press on the text to place the cursor, you get a little magnified view and it does let you place the cursor in the middle of a word. So t…

> Edit: I just discovered now that if you long-press on the text to place the cursor, you get a little magnified view and it does let you place the cursor in the middle of a word. So that's probably the most efficient method currently available. I chuckled a little at this as this is one of the oldest features of iOS, probably even from back in the pre-iPhone 4 days.

> probably even from back in the pre-iPhone 4 days.

The first iPhone I got was a 3GS and it had the feature. The person at the apple store helpfully demonstrated it to me when I went to pick it up.

Post reply on HN