Hey, Haiku on a phone has been discussed severall times on the IRC, sometimes on this forum.
I think it might be usefull to start some UX discussion about how a Haiku-stack powered UI could look like, by investigating previous UI/UX of other Systems, current and historical.
If this is done It would be a good idea to only do this with explicit code support of applications, that way nobody “just recompiles” stuff and complains that a desktop UI does not work on a phone, and only properly ported/written applications will be available.
I have a PSION series 3c I’d write a bit of a UI overview on, it might be usefull to do this for Android < 4 vanilla, android 4 htc, android “modern” (samsung UI, and the google one, maybe vanilla too), salifishOS, iOS, and maybe some of the linux on phone OS projects.
I’d tentatively call this effort project maple, like the brown leaf in the haiku logo : )
There should be a clear delineation between phone and desktop modes:
Phone mode - only has a limited selection of apps for basic phone functions and settings
Desktop mode - activated when an external display is detected, will only be used there, and is just regular Haiku
The most important thing here is to be extremely focused on a small but highly polished experience and just get the essentials right, before moving on to anything else.
What the essentials will be, is certainly up for further discussion.
I have thought about haiku on a very screen-space-constrained computer (like a gemini psion 5 clone, or pinephone with keyboard, or just a netbook) lots of times, but I’m not sure how it would look on a phone.
On a small-screen computer I’d roughly base it on EPOC R5 (OS of psion 5/5mx/revo/7/netbook/netpad etc), with a global menu bar that can be hidden or called up with a shortcut (which was also used on psion 3/sibo OS), and applications start full screen and can be stacked or tiled with simple shortcuts. I’d also change tracker so that the desktop turns into a file manager that can be navigated in, just like in EPOC. The deskbar can stay where it is. So, not big changes overall.
I would also point out that the security demands are likely much greater with mobile phones as your desktop.
In another thread it is mentioned that a framework is being developed to allow Haiku software to be easily ported to Genode, a safer operating system. Genode in turn has been ported to run on the Pinephone handset. Perhaps this could be a plausible way to achieve a Haiku-like experience - run our familiar apps at least - on a mobile phone.
This thread is about something entirely different, creating a UX/UI that would work with Haiku to run on mobile phones, not some ports to frameworks or whatever.
A states goal is to /not/ run familiar apps as they are. This has to be well thought out and experimented with.
iOS/iPadOS use Springboard.app instead of Finder.app, but ultimately it’s the same OS. Perhaps replace the tracker app with something finger-friendly. It would be great if the user could switch between finger UI to full desktop to have convergence early on.
But is this premature since Haiku don’t run on ARM yet?
Ditto. It would be also beneficial to discuss the post-R1 API changes with mobile compatibility in mind. Instead of going the NSKit/UIKit route, designing a single framework with both platforms in mind would save some hassle.
I am not sure convergence would work on a Haiku-like platform. Converged platforms always have some kind of compromise from the desktop side of things. Something more like SwiftUI would be better, say, design once-adopt twice instead of working from a single UI code base.
Anyway, still too early but nice to have some ideas around. Let’s first have some decent power management, then we’ll talk.
Edit: Now that I think about it, this would require at least a dozen full-time employees to ship this in a time period that would make it still in-line with the competing software.
I think that planning for this would be a good idea for a number of reasons:
New area of experimentation
Potential staging ground for future innovations
Haiku would likely run better on low-end HW like the PinePhone than existing options
Opens up new class of affordable, portable, and documented hardware to use and develop Haiku on
Attracts new users and potential developers from related communities
Provides a unique experience for users of these hardware
Motivator for ports
That last bullet point is also why it’s a good idea to plan for this now. Without any sort of planning or ideas on how Haiku will operate on these hardware platforms, there will be far less motivation to try and get it working on them. UX prototyping can happen before hardware enablement and may even become a reason for it.
I think it is pointless to try and hang up UX work on whether random hardware is supported, we need to know why and how we want to support it first : )
I’ve been thinking about some
basic interaction model: both android and iOS use a kind of view stack, where each app internally has previous and next cards, I don’t think it makes sense to copy this for two reasons, for one it is needlesly complex and for another Haiku has no applications that even do this on the desktop.
My idea this far would be: Have a “tab” on the bottom of the screen with the app name, above it is the application content. Dragging the tab/splitter up would bring up the application list, as a kind of tree view, selecting one changes the active application. One still needs to drag the splitter back down to see the view. Applications should be able to open severall views, if needed. For example for a channellist, and a view in the hierarcy for each channel.
I remember reading that the focus of the Haiku project is strictly limited to personal computing (and not mobile devices), which makes sense to me: such a small project should limit its scope to what can be reasonably accomplished by its developers. Extending Haiku’s scope to cover mobile computing would probably result in the catastrophic diffusion of development resources and momentum.
I’m really not sure if this is a good idea…
Yes,I also have a PinePhone laying around and collecting dust because there’s no operating system for it that makes me happy (recently tried Maemo Leste again,it’s quite good but it’s too early for everyday use).
And I think a lightweight and consistent OS like Haiku could make me happier with that phone.
My desktop computer is much more important for me,however,and I don’t want that my desktop experience gets worse because things begin to be optimized for the phone or both,instead of just the desktop.
Convergence just sucks.
It might be a nice idea to bring many apps to multiple platforms without much work,but it never ever worked nice so far.
The biggest companies already tried it and the result was always an epic fail,so please don’t repeat that.
May I remind you of Windows 8,Ubuntu Unity,Android Apps on Chrome OS and nonsense like that?
I still think that a mobile operating system on top of Haiku technology could work nice,but only if you take measures to prevent it from messing up the desktop experience (or both).
For that reason I would recommend the following:
Give it a different name.You already did this (Maple),but I mean not only for development but forever.That should never be a core part of Haiku,so that Haiku still focuses 100% on the desktop.
Fork the Haiku codebase and keep everything related to phones only in your fork,while syncing kernel and library work with the main project
Make it binary-incompatible to Haiku
Rename the BeAPI to something else,so that applications can’t be just recompiled to make desktop apps mess up the phone experience.It could be MobAPI or something like that probably
Don’t add convergence features.It’s a phone,not a desktop.And 99% of the users will never connect a big screen with it,so it makes zero sense to ship a second UI with it,plus it increases the risk that someone will use the additional desktop code to bring desktop programs to the phone.Just entirely remove the desktop UI from the codebase of the mobile OS.
I know,my suggestions will bring much additional work.
Porting existing applications does now basically mean a complete rewrite of the UI part.
But I think that’s the only way to make both the desktop and the mobile version nice to use.
Haiku is the only OS that still makes me happy,because it doesn’t have all the convergence shit that even GNOME,KDE and Unity have nowadays,making the Linux desktop horrible to use.
Please don’t copy them,but learn from their mistakes.
Don’t really think that it’s a good idea to have convergent apps, since the paradigms of mobile and desktop are quite different. The premise of Haiku/Maple on phones should be a good, basic phone OS that turns into full-fledged Haiku when an external display is connected.
As said before:
Regular Haiku apps should only run in Desktop mode and never in Phone mode, since they are designed for desktop use. Only a few, dedicated apps designed for mobile should run in Phone mode. There shouldn’t be any crossing between the two modes, other than data and settings.
For people who will not connect an external display, it will just be a reliable and fast basic phone OS. That’s yet to be filled in a satisfactory way. For those who will plug in an external display though, they get the full Haiku desktop experience without it being compromised by attempts at making convergent interfaces.
Well,that’s basically what I said,except that I would completely remove the Desktop mode from Maple.
I know it’s trendy in the Linux community to connect big screens to a phone,but I don’t think a majority of non-Linuxers would ever do that and it’s nonsense to ship a whole desktop UI just in case one of 100 users actually needs it.
That’s the thing though, people who buy these kinds of open mobile devices are already far from the average user. They are technology enthusiasts, much like the current Haiku userbase. However, this demographic will still want a phone that can do the basic stuff well, reliably, and quickly when they’re on the go.
FWIW I also don’t think that this will divide resources too much, as a lot of the prerequisites will also benefit regular Haiku on desktops as well.
As a member of the Haiku team, I have more than enough work to do already to get the desktop part mostly right, and I wouldn’t want someone to add phone stuff to my workload.
If “Haiku on phone” would happen, I’d advocate for it to be a completely separate project (a fork of Haiku), with a different name and a different (but possibly intersecting) developer team.
A key point of Haiku is that the OS is specifically designed for desktop computers. This allows us to make compromises that would be completely unappropriate for an OS doing more things (like Linux). The constraints of a phone OS are very different, not only in terms of UI, but also in terms of powersaving, multitasking, security, … Well, basically everything is different.
Also, if I was to design an OS for phones, I’m not sure I would start from Haiku at all, for the same reason. Probably I would look at Symbian, Epoc, PalmOS, and see what improvements Android/iOS did to that (and what they got wrong). And I would also look at Tizen, FirefoxOS, WebOS, … before I even start to think about a plan for this.
However… for now I’m busy with the desktop part and I don’t plan on running out of work there for the next few decades.
Yes, that could work - both projects could also share the legal stewardship of Haiku Inc and Haiku Inc can collect donations on behalf of both projects.
Maybe we could use Haiku’s kernel as a foundation and then build up an entirely new mobile UI from there - presumably visually consistent with what Haiku’s UI currently looks like but optimised for mobile devices?
Yes, that’s prolly how it’ll happen. Don’t think Tracker would or should be used in a phone mode, since it might not even be necessary there (a file manager especially). It’ll most likely be used in a desktop mode.
I see no point in this exercise if you remove the desktop. Anyhow I don’t see a problem with working on this, whether other developers work on or do not is fine either way. It certainly makes no sense to fork the haiku codebase over this, especially when the vast majority of code would be shared.
The “different but intersecting” part is already true for most parts of Haiku, developers can work everywhere, but that does not mean they have to or that they do.