According to his own tweet, Elon musk mooted developing his own mobile phones as an alternative to existing ones should the main vendors lock Twitter out of their software distribution services. Whilst there are abandoned mobile systems Twitter could buy or fork such as Blackberry, Windows mobile or Palm’s webOS (I think it was called), or they could roll their own thing round a linux kernel, thins might be an opportunity for Haiku.
The question is whether Haiku would want the particular honour of enabling a rogue service since, if it is banned from google and the like, by definition twitter would have reached the point that nobody reputable wants to touch it?
I would not be in favour of Haiku or even a fork of it associating itself with a character like Elon Musk. IDC if his mobile OS would use Haiku code or an interface based on concepts posted here, it will be poorly managed and made while such a person is in direct control of it.
In the end we couldn’t stop him, the system is open source. But it would be too much work to rework the system for phones, if only in terms of networking.
Open your own development branch, give your own name and off you go. The question would be whether you would then accept any improvements and drivers that might be offered.
But thankfully, haiku is built for desktops, not phones.
With recent discussions about running Haiku on phones starting up again, I’d like to bring up this recent blog post on text editing UX: https://jenson.org/text/
It’s a rather small yet fundamental aspect of mobile UX that has gone mostly neglected. It also shows how current mobile interfaces are still to some degree locked into decisions made years ago, rendering them somewhat inflexible to positive UI changes befitting the form factor. Perhaps this is something that we can do, experiment with mobile UX to an extent not afforded to larger mobile UIs. Currently re-evaluating previous designs here, see which aspects to reuse and discard.
After all, Haiku’s GUI was designed explicitly for the desktop form factor. If there is to be a mobile variant of Haiku or a mobile fork, it would only be appropriate that its interface was also specifically designed with its target form factor in mind. Except for when an external display is plugged in; the current Haiku UI is perfectly fine for that usecase.
It’s interesting that this whole article on text editing does not consider… the keyboard.
On my phones I used MessagEase and recently I migrated to ThumbKey. This keyboard has only 13 keys, but uses gestures to allow entering more characters, and also for copy, paste, and moving the cursor. Since it has fewer keys than the typical QWERTY keyboard, the keys are big, and there is currently a lot of space left around the keyboard for more things.
I imagine some things could be integrated there, like making the keyboard into a kind of “touchpad” for moving the text cursor. Because what they did with the magnifier looks like on the screenshots and animations, but it doesn’t take one thing into account: while you’re dragging the cursor, your finger is on top of the text. How then do you see what you’re doing?
For me the problem is made worse by the fact that I use very small text on my phone (as small as my eyesight allows it). Certainly I’ll not be going anywhere by putting my finger on top of the text. It will cover 5 or 6 lines of text, how is the system going to tell which one I wanted to select?
iOS solved this nicely imo.
holding space makes the keyboard into a touchpad that moved the text cursor, also if moving the cursos on the text there is a bubble above it mirroring exactly where it is moving.
A less keys more swipe/touch keyboard is defineteöy interesting to develop though… rather than the “qwerty because typewriters got tangled” layout
yes, but the proposal (using various level of pressing the screen) seems a bit awkward to me. Sometimes I type a destination on my GPS app while riding my bike, and such things would be hard to do. I imagine there are other cases like that where it’s hard to maintain a precise level of pressing the screen. Maybe it’s not at the times where you need to write and edit big chunks of text, however, so it could be fine.
Guessing that the intent was to propose a systemwide and keyboard-agnostic solution.
I did notice in the demo that there’s some distance between the text cursor handle after it is grabbed and the touch cursor, suggesting possibly a large-enough inaccuracy allowance to avoid the finger covering the text. Gotta wonder how that’ll impact the feel of dragging, though. Perhaps by making the text cursor handle bigger?
The post does address this, criticising the magnifier method for being difficult to parse in large text fields.
That’s a visual bug of android though.
in iOS the “real” one is always hidden under my finger so there is no ambiquity, and it looks better and is directly above my finger.
The proposal was originally about Android and iOS, both of which allow third-party keyboards. Suppose that a mobile interface for Haiku/Haiku-derived mobile fork would not have that, then?
Just to be sure, I asked the post author about this and he actually responded:
But if you ask me, I’d say that yes, on a phone, the keyboard input is a central point of the user interface and not something that should be left to 3rd party devs. That fits well with our “consistent, all-in-one system” approach in Haiku (Desktop edition). But people deciding to work on a mobile fork/version of Haiku could do whatever they want.
Oh yes of course, was just asking for your opinion!
Guess it does make sense indeed, especially since part of the last Maple System idea here was to only have a limited selection of first-party apps on the mobile side.
I find that the “teardrop” inconveniences when selecting one of the auto-correct suggestions, and also just learned it could be moved after having read the article you linked.
In termos of simplification, removing the teardrop, making the cursor move to the point of touch, and allowing to select text when dragging the finger seem simpler and more effective. The suggestion of using different pression levels seems hard to implement, hard to teach people and also not all phones have the requisite sensor.
