I refered to the current developers… your mockup is brilliant, something nice like this had to be done
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 <O to note that a scrollbar is actually a pointing device; it points to a line which can be moved.
But TBH I never really liked scrollbars, I like PDF like grabbing much more. Scrollbars are good for quick jumping though. Middle click and drag in Haiku’s Playground demo app to get the Adobe Acrobat feel.
R2 time!
PS: I’ve done a rough update, with MS paint :-/ can I upload somewhere?
Wow, that’s really beautiful, excellent work.
Just upload to an image upload site, like imageshack.us, and link to it in your message 
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
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)
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.
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
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. 
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.
Something I, but others might not like...
You sure got that right 
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 
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… 
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).
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
@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.
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
I like it.
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.
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.
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.