Ideas on Haiku Interface

Well, first of all, this is my first post to this forum so: Hello, everyone!

I’ve been following the news over Haiku for a while now, but I’m not actually an user. I used BeOS R5 PE for a while a loooooooong time ago (I think it was around 1999, but I can’t actually remember), and been playing with a pre-alpha build for a few weeks now, though with little time dedicated to it.

Anyways, this post is about sharing a few of my ideas on Haiku’s theme and interaction with the interface. I believe that, not being a regular user like some of you on this list, a few of the things I think of discussing in future posts may sound a little heretic. Please don’t get your pitchforks and torches just yet, ok? :slight_smile:

To start I thought of talking about Haiku’s current theme. When I first tested it around a month ago, I got quite impressed about how modern some of the interface elements feel and behave, and at the sime time how dated some of the interface elements look. Most of all it’s a pleasant interface to look at, but I guess it could improve.

So, before showing a small work of editing of mine (mind you, I’m no designer, I’m actually just another programmer who happen to like playing with The GIMP) I have to say I quite liked the menus and the window tab posted by John Wells here:

Then I started thinking what I didn’t like about Haiku’s interface. Or, to be more precise, what I felt that looked aged in Haiku’s interface. I came up with a mock up that is far from John’s quality, but which I think shows my ideas somewhat well.

And here is a comparison, so you can see the changes in a different tab and switch back-n-forth to see the exact changes:

Well, pretty much the work was a mix of simplifying and adding complexity to different parts of the window. I decided to drop most of the gradients, and only use them where they are supposed to make some element stand out:

  • The window tab still retains it’s gradient (though it’s there really just to take the space, John’s would be a better option).

I also took off most of the separating lines, which makes the window look (to my eyes) less cluttered. Then, with most of the gradients and lines out, I decided to add a little bit of complexity to balance it all:

  • Some less-flat scrollbars, based on those used by KDE on it’s Oxygen theme, but much simpler, with a sunken look.

  • And a higher degree of bevel added to the inside of the contents pane with the icons, together with a tiny shadow projecting to the inside of it.

I still dislike how the item-count looks in this interface, but I didn’t have the time or ideas to make it better. It blends quite well, in the original Haiku theme, but stands out too much with my mock-up: does anyone have an idea of how to make it better?

Well, anyways, that is it for this post. I have quite a few ideas on interface objects behaviour in general, but I’ll save it for future posts when I have more time and thought more about them.

All comments are welcome, and I’d really appreciate your opinions on the few ideas presented here. It’s useful as a guide when cooking more ideas.

The problem with removing the line on the window border is that the window border serves a purpose: it can be used to grab and move the window.

Also while I do like the look of the sunken scrollbars you are impairing usability by making a smaller usable area for the scrollbar thumb, making it harder to click and move.

GUI interfaces are more than just looks, they need to be usable too.

With that said we certainly appreciate any efforts to improve Haiku’s looks, as long as they don’t impair usability. So please post more ideas!

  • Ryan Leavengood, Haiku developer

I can see the problem with the scrollbars and yeah, I never thought of that. It must be because I use them more as a visual feedback than active pieces of the screen: I usually scroll or do anything else with the keyboard anyways.

About the borders, I thought about that and I’m quite surprised I didn’t put it on the previous post: What I wanted to propose on that is using everything that’s “Window” and not covered by useful stuff as draggable to move the window. See all that space between the menu items and the icon? Why waste all that while it can be perfectly used to drag a window? With that concept in mind, it still is pretty straightforward to imagine the border is useable as dragging. It’s still there and no changes were done to it’s size, but maybe it would be a problem for new users, I don’t know.

I agree with the lesser usability of your scrollbars, alex.
Also, the scroll arrows aren’t recognized as buttons. What happens when they are pressed. Do you invert their colour or do the lines of the button appear just then?

I also like the gradients that are in the current Haiku theme. They are not too pronounced and keep pretty much in the back. I also don’t like your inner drop shadow; it’s blurring too much.

Now, what I do like, is how you eliminated the upper window border. I dared to fake that (badly) into the current theme:

Oh, now images in comments? Try this link.

The menu bar could now even be a few pixels less high.

I also agree with your suggestion to have any non-active part of the window be grabbable for moving.

See, even if not everyone likes all of your suggested design, it provokes thought and some parts may hopefully end up in the official theme. :slight_smile:
Thanks for your efforts. Please do continue.


There’s a potential problem with the eliminated-upper-window-border version, though it looks nice (read: even more minimalist).
The visual message of that version is that the entire menubar doubles as ‘window dragging area’.
That means when you click on it (to drag it), you run the risk of having clicked on a menu-item area, since menu-items have no borders.
So you might see a menu expanding instead, and once this happens no dragging is possible.
The solution to add menu borders brings visual clutter and even consistency clutter in the user experience.

The visual message of that version is that the entire menubar doubles as ‘window dragging area’.
That means when you click on it (to drag it), you run the risk of having clicked on a menu-item area, since menu-items have no borders.
So you might see a menu expanding instead, and once this happens no dragging is possible.[/quote]

I don’t see this problem. The user will soon learn that to drag a window you can’t click on a menu label, as that - no surprise here - will open the menu. Since the active menu area only extends a few pixels to the left and right of the label, it’s easy to judge where it’s save to click-to-drag.


The bottom line is that you sacrifice certainty for esthetics: The ‘less is more’ shouldn’t prevail over ‘form follows function’, IMHO.

IMO we’d sacrifice improved aesthetics to avoid a theoretical problem. Does really anybody think he can move a window by clicking on a widget that every other time opens the menu?

Besides, there’s still the big yellow title tab which is even in the current theme much easier to hit than the tiny window border.


It’s not a theoretical problem.

Humdinger, I hope you’ll see by the following examples that it isn’t a purely theoretical thing, nor is it a holy principle of some kind.

Case 1:
Developer A comes up with his Haiku application X, that happens to have a menu bar with so many items in it, that the clickable part of it stretches all the way to the right border.

The user that has gotten used to move windows around by dragging them from the menu bar does now what?

Case 2:
User A likes -for some reason- to have his/her windows shaped rather narrow and high. Combined with windows that have more than a few menu-items the ‘dragging by menu bar’ gets precarious or impossible.

Once the user is given a way of doing things, he/she has to be able to rely on it to be system-wide the same, in whatever situation (in other words, in whatever possible application or user preference setting).
When the user’s workflow hits even the slightest glitch (as happens in the cases above), the OS should never be to blame for that. Consistency is really something to be anal about.

Remember, we have the ‘grippy’ in the lower right hand corner that gives users the freedom to shape windows in the way they want.

We also have no limit on how many menu items a window may have.

I am definitely with Meanwhile on this. Besides potential usability issues, I just don’t like how the borderless window looks :wink:

Also you can move a window by clicking anywhere if you hold Ctrl+Alt.

Well, if you start to get anal about it, it would be of course a massive desaster! :slight_smile:

I still think it’s not that bad, when you consider how many will aim for the few pixel wide border when there’s the huge, yellow tab only a few pixels above it…
But, be my guest, forget the moving-with-menubar.
Now a window can be moved by all borders - left, right, bottom - and the big yellow tab on the top.
If there’s no menubar, there’ll be a border at the top.
If there’s no title tab but the window has a menubar, it’s the same consistent rule: grab one of the thee borders.

Losing the upper border is a visual preference. I feel it’s less “noisy”. But I see, that at least you two don’t agree. Just remember that one can adjust to things and everything new is fought at first. :slight_smile:

You two have the advantage that probably only very few of the coders who could be interested to try this thing out are aware of this thread. :slight_smile: