ApplicationMenuBar for a More Cohesive, Consistent, and Pleasant Experience

Well, I think a whole lot has changed, and we can point to lists and lists worth of stuff (for example: using Haiku as a daily driver on bare-metal is, for a lot of users, actually viable!). But the biggest thing is something indeed that hasn’t changed at all, and that is:

Haiku is still here.

Two decades ago, there were a lot more “alternative OS” or even “hobby OS” projects: Syllable, SkyOS, etc. Most from that era have long since gone, and nowadays, there’s far less, and mostly the “hobby” kind. Haiku, meanwhile, has survived, and continues on over two decades after it began. And as you can see by the fact that this forum thread got 80 replies (most quite long and thoughtful!) in a week, a still very active community.

Is progress slow? Yes. Are we very focused on consensus, and figuring out details of things before we implement them? Yes. Does that require patience? Oh, yes. Does it get frustrating? Oh, most certainly yes.

But clearly something’s working, because we’re still here, and we’re still at it. Other projects that forked Haiku because people were frustrated with the development speed, or thought things would go better with a different kernel, or just wanted the toolkit running on Linux, have come … and then they’ve gone again. (To be fair, some have come back again later, as with Cosmoe making a re-appearance after over a decade of dormancy. But this is rare, and Cosmoe is mostly just a UI toolkit, it’s not even aiming to be a whole desktop environment and much less a “distribution”.)

UI/UX changes, in particular, are hard to do. They affect absolutely everyone in the present and (until we change something again) in the future, so everyone has a stake in them, so everyone has thoughts about them. That’s natural. But we are not Linux: if an idea really is an improvement, then chances are, we will eventually agree, and when we do agree, and change direction in favor of that idea, then the whole ecosystem will (slowly, but eventually) realign around it. That’s a much, much better model than “sure, we’ll add a 15th way to do that” or “go make your own patches if you don’t like it” as Linux tends to follow. It comes with downsides, obviously, as I’ve already noted. But the end result is worth it; or at least, I think so, and I think the long-time “Haikuvians” who’ve stuck around through thick and thin think so, too.

I think Haiku’s relative “conservatism” then isn’t a ‘bug’, but rather a ‘feature’. We are slow, but we’re steady, and two decades later we’re still here. It appears to me that a great many respondents in this thread like your idea, and think it’s a good one. The “ayes have it”, so far at least. There are objections, yes, and there are problems people are throwing up to be solved. But they’re not throwing them up to try and kill the idea completely, at least not for the most part, I think, but rather to try and parse out what exactly the idea will look like, and whether it really is something we want to implement and can live with.

12 Likes

I think Haiku is probably the only project that really associates simple users to decisions. It seems nothing but wasted time at first. But, because of the discussion, people are understanding why it must be done this way and most are adopting the solution naturally.
So once a decision taken, unlike other projects where devs gods decide in obscure chats room, you don’t need to enforce it. That explain why we are seeing the useful and handy side of your proposal but not the need for it.

2 Likes

Other people have replied already, but:

  • This thread is barely a week old. I put on my TODO list to look at making the icon menu part of libshared so applications can reuse it. I had other tasks to finish up first.
  • I think being cautious about changes is actually a good thing. Change isn’t inherently good, and we like to be sure of what we do. Linus Torvalds once said: “talk is cheap, show me the code”. I believe he was wrong. The talk is the more valuable part
  • Forks are allowed and I’d say encouraged. Have fun experimenting with your ideas. Maybe we’ll adopt some. Maybe we’ll refine it and do our own version of it. But if you lose patience after a week, working with people who can at best put a few hours of work on Haiku every weekend is surely going to be frustrating. Don’t let us stop you, then
7 Likes

Now, for a proper bike-shed: Dude! I thought we were “Haikunauts”!!! :stuck_out_tongue:

4 Likes

My .02 cents:

  • having a more cohesive, consistent and pleasant experience is a very valid UI/UX goal. Thanks OP @575 for your effort to try doing that.
  • Mac top menubar paradigm rely on being at a fixed top screen position, for the current app, menubar. What works within this UI/UX paradigm won’t necessary works great when applied to menubar in windows when multiple apps and multiples windows with menubar within are visible, at least partially. BeOS and Haiku don’t have a top screen, current app menu bar but menus in windows. Beware of that major difference.
  • Using an icon to access de-facto/standard/default menu items like quit, about and use less graphical space for that is a good idea, I think.
  • But, quite ironically, having a different icon in menubar depending on the app makes it less cohesive and consistent: people don’t necessary identify perfectly the app icon. The more apps are available, the less they will. Some icons are very similar. Worse, an app developer is free to change its app icon in a next version.
  • A more consistent icon, always the same whatever the app, will bring more consistency in fact. The hamburger icon can be ugly as much as you may feel it is (or not), what it does bring *functionaly* is that: it’s consistent, cohesive and compact, everybody now knows it’s where to clic to open and access the main app/web app menu, without wasting mush space or posing naming, i18n potential strong issues. At worse, it’s ugly BUT effective.
  • Dont place such icon all over to the right side of a menu bar.
    It will make it far away from other menus in that bar, and make even more confusion with Tracker icon which is NOT a menu but a dragable icon for the current path of the displayed folder.
  • For me, it’s the whole concept of a permanent menubar which is quite looking somehow out-dated. Maybe, to bring a more modern look to Haiku, it’s the whole concept of a permanently visibile menubar which should be re-design as a whole instead. Migrating to a collapsable left or right menu panel design could also be explored, for instance.
    I consider wasting valuable display space for a permanent menu a waste of pixels for people knowing their keys shortcuts, in particular generic ones valids whatever the app. And for those who don’t they will have anyway to do some action to explore the available actions (menu items) from a UImenu, which mean displaying permanently only the “groups” of menu items is, alone, not enough for that, making the space used for that a low ratio of functional effectiveness.
  • it’s not bike-shedding, it’s collaborative effort to change things not for the sake of changing things but to make them better. Not all changes are good automagically. And it’s hard to make good change in UI/UX (while it’s easy to make bad and worse changes in UI/UX !)
  • therefore, may I suggest this thread should trigger an initiative to:
    • explore possible changes to bring a more modern looks regarding menu items/actions to all apps under Haiku.
    • share a playground code and screenshots to help the community to experiment instead of just rely on their own strong believes regarding this topic. UI is fine, but without UX, its not enough and can be easily lead to stylish/trendy over functional.
    • plan for some open vote some days, as we did to select the new Stippi somehow flatter look and feel style and set of Haiku vectors over previous ones from BeOS era.

Aka let’s open a “competition” for UI/UX changes in Haiku, as it was already done in the past, and let the community select what they likes or not.

1 Like

Haikuphiles?

1 Like

Further developing this idea about the program icon in the right corner of the menu.

The additional proposal is that it should have the following standard menu entries:

About, Help, Close, Preferences (?) (the order of these entries should still be considered).

Also, the icon should take action, when grabbed and dropped somewhere, it should create a link to that program to launch it, with Shift holding it could be a relative link.

I would also suggest making such an icon function in the tracker in the same way, perhaps with a slightly expanded menu: creating links to that folder, copying, moving that folder.

This would be a somewhat more conservative redesign-supplement of the current app menu, and Haiku programs would also get their own icon in their own window for faster recognition. In addition, such a design would not be just blind imitation of other systems.

About, Help, Close

While a generic About action can be done using info from app’s ressources, not needed every app developers to implement this action by themselve until they want to, it won’t be anymore possible for Help action. And not apps have help text, or even actually need to have some.

Close action can be misleading. If it’s quitting the app, and therefore close all of its window(s), it should be named Quit, not Close.
If it’s closing just this window, not quitting the app if other window(s) of this app are still opened, is redundant with the close button.

I would also suggest making such an icon function in the tracker in the same way, perhaps with a slightly expanded menu: creating links to that folder, copying, moving that folder.

I disagree here.

The current icon at right of Tracker menu bar windows is already allowing that via drag and drop, making in fact far more explicite where to create or copy or moving action should be done, via the drop target.

Please don’t confuse users by proposing same actions related to what is visible in the window being accessible but via the app icon itself.

Haiku programs would also get their own icon in their own window for faster recognition

I’m not sure people really care to recognise the app icon, and there is already the Deskbar for that.

But I agree that in Windows all windows from an app will show its app icon in the window title bar, on macOS the top screen menubar is automatically switched according to current active window (but when menubar of two apps is very similar, as they often are, it’s not an easy way to recognize the app from the menu).

Maybe using Deskbar to give some feedback, by highlighting the app entry when user activate one of its windows when it was another app before, so a quick look at Desbkar could help user to know which app hold currently the window focus ? After all, Deskbar is already a space used on the screen to track and interact with opened apps, right?

1 Like

Unless you use the AutoHide setting, or it isn’t set to Always on Top and there is another window on top of it. People’s preferences differ.

I’m not saying this wouldn’t be a good idea, but it doesn’t necessarily solve all problems.

1 Like

You’re right. I forgot that as I’m using Always on Top indeed, it’s a trait I kept from my NeXTStep old era.