Haiku UI Mockup

Forum thread started by iindigo on Sat, 2008-11-08 21:07

Over the past day or two I've been looking at some of the mockups posted in this section. While I think that some of them were nice, none of them really felt quite right to me, so I decided to see what I could cook up in Photoshop. After some amount of time and effort, here is the result:

It's not quite perfect (a few things are a couple pixels off, for example), but it's a fair representation of how I think the Haiku UI should look. Instead of reinventing the wheel or "stealing" UI elements and appearances from the "big guys", I've tried to focus on simply improving what was already present in R5 and bringing it up to current standards (alpha blending, shadows, HQ text antialiasing, etc).

I have another mockup that contains more UI elements in the works, but I figured I might try to get some opinions on what I already have done. What do you guys think?

Comments

Re: Haiku UI Mockup

That is something... rather nice. And hey, rounded drop-down menus... that is different. The colours are crisp. I would say that you might want to do something with the scroll bars, yet another thing that I see scream "Mac-like" to me.

But yes, not bad. I like it.

Re: Haiku UI Mockup

I'm impressed! I like it very, very much. It's really what I imagine a descreetly modernized R5 theme should look like. Not going crazy with much too rounded corners everywhere. I like how the window itself stays square.
Maybe the gradient of the yellow tab is a tiny bit too dark. And I like the scrollbar arrows on top and bottom.

One thing to consider is the possible font that Haiku can come with.

If you do a detailed list view I'd love to see how alternately white and oh-so-slightly tinged light grey rows would look. Maybe the sorted columns could also so be delicately pronounced.

Anyway, you obviously know what you're doing. I'm excited to see what you will come up with. Thanks for your work!

Regards,
Humdinger

Re: Haiku UI Mockup

I *very* much like your efforts. You've done the same kind of take on the general look of the OS that stippi and crew have done with the icons and it looks fantastic! My only gripe is the scrollbar changes. The buttons should be arranged like they currently are in Haiku and the buttons themselves have suffered from the same problem that R5's do, which is that they look disabled even when they are not. If the arrows on the buttons were somehow filled in, this wouldn't be a problem anymore, either. Your efforts have definitely paid off and I hope that Haiku's look is tweaked to resemble yours (even without the drop shadows :)

Re: Haiku UI Mockup

I love it! The font rendering looked odd, but that should be a seperate issue. The buttons could need some refreshing, and they should be placed like they are in Haiku now. Otherwise I love the mockup! It looks clean and not too "shiny", but still crisp and attractive. It has a Haiku feel I think. I really look forward to seeing more of this, keep it up!

Re: Haiku UI Mockup

Thank You for Your work John! I like it. Can we get H-Snake?

Re: Haiku UI Mockup

What's "H-Snake"? Anyway, I really look forward to seeing more of this. I can't wait to see what you do with buttons, tabs and other widgets!

Re: Haiku UI Mockup

Thanks for the praise, all! To be honest, I'm bit surprised that everyone likes it so far, because I'm nothing more than an amateur. Even though I've been doing this kind of thing for six or seven years now, I've never had any classes on it or anything of that nature; I haven't even attended college yet (just a high school graduate). But anyway...

Since so many commented on the scroll bar and its buttons, I guess I'll have to change it. I initially used the both at bottom model because 1) it was what was being used in the old R5 screenshot I based this on (well, except it was double scroll buttons on both ends) and 2) it eases scrolling for those without a scroll wheel (for example, I use a trackball without one).

The font used in the mockup is the open source Bitstream Vera Sans. I made use of OS X's font smoothing to better simulate that of an actual OS since Photoshop's antialiasing and rendering at smaller sizes is absolutely atrocious.

And forgive me, but what is H-Snake? A Snake clone for BeOS? I haven't run BeOS or any of its variants for a very, very long time now (coming up on 5+ years), so I'm a little lost. Mind providing me with a screenshot?

Re: Haiku UI Mockup

I think H-snake should really be a Z-snake which is a visualisation of current menu path implemented in unreleased builds of the last BeOS version:

http://www.osnews.com/img/632/zsnake.png

Re: Haiku UI Mockup

Hmm, that's an interesting idea, but I don't really like how it overlaps all the other menus with its own "layer". My implementation would probably put it on the background level of the menus underneath the menu borders.

Re: Haiku UI Mockup

Well, show us your idea then. :D And no need to worry about you not having education. The result of your efforts are still the best I've seen so far! Ok, I am too impatient, sorry..

Re: Haiku UI Mockup

I think this is really beautiful and it'd be amazing if Haiku was like this.
+1

Re: Haiku UI Mockup

Bulls Eye, John!
110% good stuff!
Except the menufont your mockup looks like a worthy replacement for the UI of the patriarchal BeOS™!

greets,
prOSy

Re: Haiku UI Mockup

It's really nice! I wanted to see a similar mockup which retains the same crisp nature as the original Be theme but modernized with TrueColor palette..

I agree with others - something must be done about the buttons and scrollbars. In the original BeOS interface, scrollbars and buttons had a "flat" look to them - this made them quite clean to my eyes; can you try something along those lines?

Re: Haiku UI Mockup

Generally I like the direction. But at the moment I think it feels a bit too "sharp"... this probably stems from the 1px black borders and the small font (which also has severe usability issues).

Don't let hat dissuade you though. But it might be something to take into consideration for your next revision. :)

Re: Haiku UI Mockup

Gavin wrote:

Generally I like the direction. But at the moment I think it feels a bit too "sharp"... this probably stems from the 1px black borders and the small font (which also has severe usability issues).

Don't let hat dissuade you though. But it might be something to take into consideration for your next revision. :)

Well I could see maybe increasing the font size of the menu items, but I don't think doing the same to the actual menus would work very well for two reasons:

1) The menu section of each window would be taking up far too much real estate. I personally dislike having a menu attached to each and every window and prefer the Mac menubar model for its reduced redundancy and guaranteed location, but I'm not so sure others would feel the same.

2) If it's the same size or larger than the titlebar text, it will feel unbalanced and look odd.

I'll definitely play around with it and see what I can change, though.

Re: Haiku UI Mockup

IMHO all the font sizes could do with a nudge upwards, including the titlebar/tab text.

I wouldn't be overly concerned with screen real estate. With desktop (and laptop) resolutions continually on the up it's a highly available commodity these days.

Re: Haiku UI Mockup

Gavin wrote:

IMHO all the font sizes could do with a nudge upwards, including the titlebar/tab text.

I wouldn't be overly concerned with screen real estate. With desktop (and laptop) resolutions continually on the up it's a highly available commodity these days.

I see what you're saying, but even so, it's a good idea to wisely spend your pixels. It's the same as programming; having memory, CPU, and HD space in no shortage is no excuse for being a lazy programmer and not optimizing as much as possible before shipping the product.

That said, I'll see about slightly increasing font size in the next mockup.

Re: Haiku UI Mockup

Wow!! Looks very impressive

it's too hard to implement this in the actual source code.. :(

Re: Haiku UI Mockup

michaelvoliveira wrote:

it's too hard to implement this in the actual source code.. :(

Can you expand on this notion - I'm curious to hear what exactly you're referring to exactly... (perhaps you replied to a specific post in the thread?)

Re: Haiku UI Mockup

I refered to the current developers.. your mockup is brilliant, something nice like this had to be done

Zsnake Re: Haiku UI Mockup

John, you should IMHO use the blueish colour from the zsnake screenshot http://www.osnews.com/img/632/zsnake.png for the menu highlighting, this default BeOS Desktop background colour IIRC fits very nicely with the yellow and the gray of the tab and window. I too would be very pleased if you used the zsnake, I like the concept a lot and it nicely highlights the directory-tree-concept which could be very nicely used in menus as well.

Furtur more I'd change the grayed-out buttons to more active-looking ones.

And for the plain scrollbar I'd put a grayed-out button-like triangle facing the window inwards on the scroll bar, maybe combined with a handle like this ascii symbol

Re: Haiku UI Mockup

Wow, that's really beautiful, excellent work.

Re: Zsnake Re: Haiku UI Mockup

Just upload to an image upload site, like imageshack.us, and link to it in your message ;)

Re: Haiku UI Mockup

Very, very nice John, thank you.

One of the many great things that got me interested in BeOS in the first place was how much "bigger" my desktop felt with it.

I think that's a highly valuable aspect of this mockup too.

Although screen real estate for desktops and laptops may not be for many a big concern nowadays, the same does not apply for a whole new generation of subnotebooks and netbooks like the Libretto and the new NB100 from Toshiba or Asus' eeePC for instance.

These and other small devices, with small displays and limited hardware capabilities, actually offer an environment where Haiku has a great chance to shine, for the developer as well as for the daily user.

It would be great if Haiku had this upgraded look by the Alpha Release.

Do you already have an idea for the Menu/Deskbar, John?

Best,
jdf

Re: Haiku UI Mockup

Free Image Hosting at www.ImageShack.us

I changed 3 things of John's mockup in MS paint, just take the menu highlight colour as an example, the arrow symbol on the scroll bar is just a copy paste from the original image but should illustrate the idea that the scroll bar can be seen as a pointing device which moves the inner window to point to a different line/part (arrow/triangle symbol)

Re: Haiku UI Mockup

Small screen devices pose their own UI issues. Reducing font size and making UI elements smaller and harder to click isn't the solution IMHO.

Re: Haiku UI Mockup

IMHO windows on small-screen-devices should be fullscreen, with their tabs alined at the top, or tabs being hidden and shown only when the user points to an edge of the screen, similar like when you hide the (Windows) taskbar.

IIRC this is used in the OLPC's (one laptop per child) sugar? UI as well

Re: Haiku UI Mockup

I like this a lot. The suggested arrow on the scroll bar grabber actually looks quite nice, but the h-snake idea seems superfulous; something Be stayed away from. It would also be a pain to implement the snake and I personally don't like the look of it at all. To each their own I suppose.

Something I, but others might not like would be to have the title bar a shiny gold with silver close and fit-to-contents buttons. It's hard to get to look quite right and may make text hard to read, so don't feel you need to appease my love for shiny things. :P

Also, I'd like to see if you have any different plans for the path input box. I use it quite often so I would certainly have it on. I dislike the bread-crumb approach because I can't navigate to hidden folders with them.

Keep it coming, you clearly have a great feel for what the next UI should be.

Re: Haiku UI Mockup

Something I, but others might not like...

You sure got that right :p

Re: Haiku UI Mockup

The hidden approach from Be Inc. is certainly flawed IMHO. I suggest Haiku to stick to the Unix approach: hidden are files and folders which have their file name starting with a dot, like .bashrc or .ssh

For the arrow on the scroll bar, I always liked the purple Java scroll bar look, not the purple colour but more the tiny dots which seem to indicate a certain roughness of the scroll bar and by that the grabable-ness seemed clear :-)

Re: Haiku UI Mockup

> For the arrow on the scroll bar, I always liked the purple Java scroll
> bar look, not the purple colour but more the tiny dots which seem to
> indicate a certain roughness of the scroll bar and by that the
> grabable-ness seemed clear :-)

I'd say, re-use Deskbar's knobbly grabber that you use to drag it around. Also use it for split-panes and similar things so when the user sees knobs he automatically wants to grab'em. Uh, that came out wrong... oops, did it again... :)

Re: Haiku UI Mockup

Couple of thoughts:

- I don't share the 'round corners' -fascination, it looks little better (to some) but what I understand, is much harder to implement and takes CPU (or GPU) time and toll on responsiveness. IMHO in the end it's not worth the aesthetic effect it offers (to some). What would You use these 4-5 free desktop pixels in the window corner for, what usability would they present?

- if I remember correctly then BeOS deskbar had 3 'modes' - menu, semi-collapsed menu and taskbar-like. I always missed an option to switch 'start button' (grr...) and tray/clock locations in taskbar-mode. I'd say that having the sequence of theses three objects (1.'start button', 2. running tasks, 3. tray) freely configurable would be really a big plus. It would maybe come also handy considering left-handed people...

- there should be a way to add additional objects to deskbar beside the default three. Like replicants extend desktop, these deskbar-replicants could extend deskbar. One could show weather other maybe present something like quicklaunch in Windows. Tray is no place for all this stuff.
quick mockup (ugly as hell): http://myyr.restkeskus.ee/gallery/haiku_deskbar_addon.png

- (most)objects that can be manipulated in application window (and desktop) should react on mouse over (change color, shadow, size, make noise etc) or mouse should react to them (change cursor color, shadow, size etc). It usually already is like that but I think it should be uniform. The level of what brings the response should be configurable so if I already know what does what then I could turn it down a 'bit.

- window/task-grouping should be optional on the deskbar

- there should be a way to replace or extend beos GUI to implement hw 3D (like Beryl/Compiz or similar...)

- there should be multi-monitor support (not some hack) but true implementation with configurable options

- shadows are functional element and should be implemented

more coming... (beware!)

EDIT: Just remembered - I was never really fond of the way BeOS' windows were minimized, by double-clicking. To me it felt cumbersome and wasn't really intuitive, alternatives should be maybe discussed, configurable option would be best I think. I would personally use right-click (but it's also not intuitive).

Re: Haiku UI Mockup

Personally I really like John's mockup. It is still simple but updates the look of BeOS. I love the fact that he really didn't change how it worked, lots of the mockup's from the past completely re-designed the OS. Bravo +1

Re: Haiku UI Mockup

@martin on the subject of round corners:

If the UI drawing system is done correctly, a few round corners will have zero impact on speed. Mac OS X is an excellent example of this - it employs rounded corners in menus and windows along with full alpha transparency and shadows, yet has no trouble at all running on a (now ancient) 1ghz iMac G4 with a puny 32MB GeForce4 MX graphics card and 768MB of RAM.

I do agree that they shouldn't be used --everywhere--, but in the right places they really add a lot of polish.

Re: Haiku UI Mockup

Regardless of what anybody else says, I think it looks absolutely fantastic, font sizes are fine and you got all the rounded corners right (especially the one corner that's NOT rounded on the menu). The colours are great too. The only thing I'd suggest doing some more work on is the scrollbar. Maybe adding some colour to the arrows (a blue gradient to fit the menus would be perfect) and maybe adding those pips on the bar itself.

+1

Re: Haiku UI Mockup

I like it.

Re: Haiku UI Mockup

martin wrote:
"EDIT: Just remembered - I was never really fond of the way BeOS' windows were minimized, by double-clicking. To me it felt cumbersome and wasn't really intuitive, alternatives should be maybe discussed, configurable option would be best I think. I would personally use right-click (but it's also not intuitive)."

I think right click should always bring up a context menu. And one should be able to easily move the app to any workspace from that context menu.

Re: Haiku UI Mockup

Right-clicking on a tab to send the window to the back is probably the number one feature I miss in other OS. Don't touch that right-click behaviour! :)

Here's my suggestion for minimizing: While keeping the current double-clicking trigger, also accept a gesture: grab a window and throw it into a configurable corner for minimizing.

For sending to a workspace: I always have the Workspaces applet as Replicant in a corner. You can grab the windows representation in the applet and drag it to another Workspace. That's OK, but needs a bit of careful aiming.
Suggestion: When you grab a window and drag it over the Workspaces applet, shrink the window to a symbol so you can easily drag&drop it over a Workspace.

Also, when you drag a window and the mouse pointer hits the screen's edge, you could switch workspaces by keep pushing a bit "uphill" (a force-feedback device would be cool for that little resistence). Or you throw the window instead and only send the window to the adjacent workspace without switching to it.
All these gestures need careful algorithms to always correctly guess your intentions, of course.

Re: Haiku UI Mockup

I dont just like the doubleclick minimize function. I LOVE it! Its something i need in all OS i use. I can set it to work when using KDE and gnome, BeOS and OSX does it by default. And windows can do it with windowblinds. If that feature was removed i would definitly be sad.

Re: Haiku UI Mockup

I really like this mockup. It still has the BeOS spirit, but offers a nice and updated derivative.

Re: Haiku UI Mockup

@Humdinger: The best way to move to another workspace is to drag to the edge of the current workspace towards the next one. No careful aiming, no hard programming, just switch to the adjacent workspace when the mouse reaches an edge. Moving using CTRL+ALT+ArrowKey when a window is focused is a good one. Dragging windows to a replicant, no so spiffy.

I don't like gestures all that much (except for the [right mouse hold] + [left mouse click] navigation in Opera). It's hard to program, ugly, and having configurable corners would conflict with any future gestures we would want to do.

Re: Haiku UI Mockup

I like it -- very modern, still I think we should also keep a "classic" look for those that appreciate nostalgia.

Re: Haiku UI Mockup

BTW, there's also a thread on this thread on the mailing list:
http://www.freelists.org/post/haiku/Haiku-UI-Redesign

RandomInsano wrote:

@Humdinger: The best way to move to another workspace is to drag to the edge of the current workspace towards the next one. No careful aiming, no hard programming, just switch to the adjacent workspace when the mouse reaches an edge.

I had this back when still using compiz in Ubuntu. I often accidentally changed workspaces this way. Quite disorienting and annoying.

Quote:

Moving using CTRL+ALT+ArrowKey when a window is focused is a good one. Dragging windows to a replicant, no so spiffy.

Well, it'd be a feature of the Workspaces applet that wouldn't hurt anyone not wanting to use it and would help everyone else.

Quote:

(Gestures) It's hard to program, ugly, and having configurable corners would conflict with any future gestures we would want to do.

Well, yeah. Naturally you can't assign the same gesture for different things... Keep I mind that we are the masters of Haiku's API. Gestures wouldn't be an afterthought that's here in one distro and not in another.

And I can't see how gestures are inherently ugly. Can you elaborate on your concerns?
As long as gestures are not the only means for a function (think motorically challenged people) and, in the best case, there's also keyboard control, I don't see what's wrong with it. Plus, touch screens could be used increasingly in the future, which would make gestures even more desirable.

Re: Haiku UI Mockup

"Right-clicking on a tab to send the window to the back is probably the number one feature I miss in other OS. Don't touch that right-click behaviour! :)"

what about middle click instead? because it is very important to have a context menu to be consistent with the rest of the OS. In KDE it is really easy to move an app to another workspace from the context menu...you don't need to drag a window to a tiny sliver in the workspace app.
There are arguments for maximize as well as zoom. If we had maximize, we don't need another button. It would also be another option on the context menu.

Re: Haiku UI Mockup

RandomInsano wrote:

I dislike the bread-crumb approach because I can't navigate to hidden folders with them.

First of all, why do you need to visit hidden folders so often?
Ideally a system should be elegant enough to cope without hidden stuff. Hidden folders are typically used to hide cruft from the end user, and hidden stuff is typically used from within applications' UI. (Remeber navigating to c:\windows and seeing "You shouldn't see stuff here"?)

However in real world developers and other tech staff often need to tackle with the cruft and I understand your problem. But things can be done nicely as well. For example in the Windows world there's a nice piece of software called Explorer Breadcrumbs which also provides a nice editable path.

Re: Haiku UI Mockup

Humdinger wrote: "Well, yeah. Naturally you can't assign the same gesture for different things... Keep I mind that we are the masters of Haiku's API. Gestures wouldn't be an afterthought that's here in one distro and not in another."

Gestures. lots of Opera users love them and it's also a popular firefox extension. Why not push this idea into the OS so that every app can benefit from it? Otherwise, every app will come up with their own way of doing it and it could be a big mess.

Indeed, there are a lot of things found in specific apps that make sense as universal features such as spellchecking, Office Clipboard or the way firefox saves all your windows so you can go back to them after you restart the computer.

Re: Haiku UI Mockup

Humdinger wrote:

And I can't see how gestures are inherently ugly. Can you elaborate on your concerns?

My experience with gestures comes from a game by the name of Black and White and also a certain Firefox extension.

In Black and White there were all sorts of different things you needed gestures to do, and for this they had all sorts of odd ones (draw a star, swirl, box) so that they were not confused for standard movement many were rather grand or complex.

In the case of All-in-one gestures, there is a lot of up-down-left-right configuring for gestures. To add a page as a bookmark for example you must move "Down, Right, Down, Left, Up" which to be fair is one of the longer ones. The average is about 3. I'd rather just push some [alt]+[key] combination since my left hand is always on the keyboard like one of them fast twitch gamers! Hoo ha!

As far as OS ubiquity (being everywhere-ness) of gestures, it's true that it would be better to unify everything and have a kit, but how many applications out there actually use gestures? How many people even know what a gesture is? (Though dragging and dropping a file I suppose counts as a gesture).

Honestly, I just don't like them. But with any functionality, if someone is out there willing to do it, they're also willing to have an enable-disable checkbox, so my complaint isn't really a big deal. I just feel there's other frivolous things to invest time in. Spell-check would be the top of my list.

Hey, maybe if it's done elegantly enough it could even win me over :)

Now onto the breadcrumbs...

I use the address bar a heck of a lot. Whether it's changing directories with Copy+Paste from a website, getting to my favorite folder without a mouse, or changing the directory in the terminal to point to whichever folder tracker has open (there's a tracker add-on for that, but this feature is already built in!). I still use my keyboard a lot and use my mouse a little less. It all comes down to what feels natural to you, and for me it's certainly having that bar of text always at the ready. It's just something I can't live without. I've tried.

How do you paste a folder path with breadcrumbs? I use [alt]+[v].

Re: Haiku UI Mockup

I think I need to try this Explorer Breadcrumbs thing :P

Re: Haiku UI Mockup

RandomInsano wrote:

My experience with gestures comes from a game by the name of Black and White and also a certain Firefox extension.

Ah, so you've been traumatized by a bad example. :)

I have to admit, that I don't use gestures in other applications. Partly, because of what you say: You have to memorize arbitrarily set movements.
So, IMO, gestures of the OS must be kept to an absolute minimum (can't do much against apps going overboard with a feature; "natural" selection will weed them out) and those that are implemented have to have a non-gesture alternative and have to come naturally.
By naturally I mean, for example "throwing" a window in the direction if an adjacent workspace or into a corner where it crumbles to minimization.
Or maybe also "rubbing" a wind against another to stick them together.
None of the "right-right-up-left-down-squiggle-move-left-right" routine to maximize a window...

As you've pointed out, the implementation has to be perfect or it won't be used. Maybe the GUI could even learn the specifics of the user by going through a "fun training program" that would also serve as a tutorial for new users.

In any case, it's an interesting topic that's worth further investigation after R1 is out. Maybe our friends at Auckland University find it a worthwhile research project.

Re: Haiku UI Mockup

- I like the mockup (Haiku R1 default theme could come from that).
I didn't say the previous just because You all said so...;)

- if rounded corners bring no overhead or compromises in design (eg Windoze-like skinning...bah) then - I like them (a lot). I really do.

- ircc BeOS R5 had no RMC on window borders, so nothing to lose.

- button is faster then menu. Most used functions should be either buttons, corners, clicks or something like that...
mouse gestures shouldn't be the default way to do stuff (they are 'invisible' eg '0' on intuitiveness and they are marginally used so they have no meme-base (eg traditions?)...)

- all GUIs (so far) have shortcomings - mainly because they fall short in configurabilty.

- more than two ways to do a same thing (simultaneously) gets confusing (eg moving window to another desktop from a)workspaces app, b) RMC-menu, c)keyboard shortcut, d) dragging across edge etc). Best is to have one method per input eg for example