3D-Accelerated Haiku Desktop

Maybe you intended to do it that way, but I think that snap-n-go should also work in vertical direction.

When snapped, the window border should disappear (not possible at the top, though). That way, you could efficiently access the scroll bars.

In order for this to work, snap-n-go should probably start when the window border is moved out of the screen area (instead of when it touches the screen border), but that's a detail we could try out.

That's what I tried (but failed :) to explain with my last paragraph.

I generally like the idea of Tab-Based Task Organization, but I'm against the proposed interface for it.

- As DarkWyrm noted the proposed interface only helps with one side of Fitt's Law (big targets are efficient). The problem with big targets in a grid layout is that most targets are far away and inefficient to acquire. This is not a big deal if you are using a mouse, but using e.g., a touch-pad can become a drag. Considering how common laptops have become, I don't think a major part of an OS can be optimized for use with a mouse.

-Another, more serious, problem is that looking trough a grid/row of icons with names underneath requires a lot of eye movements, which is slow. Unless you happen to recognize the icon of your target, you have to fixate to the name under each icon, which is very inefficient. This grid/row design puts too much importance to the icons, which are irrelevant every time you don't already know what the icon of your target is. Icons are important, but they only serve habituated use and recognition.

To improve the main idea, I would suggest using something like the Column based navigation in Tracker http://haiku-os.org/files/TrackerBrowser.png . I'm not suggesting identical, just similar as far as rational :-).

What I like about in the TrackerBrowser interface is that it shows lists that are easy to scan trough (you can fit about 4 item names to your sharpest vision area i.e. fovea on your retina). The icons in TrackerBrowser are small, but still recognizable, and as easy to scan trough as names of items. Items in the TrakerBrowser like interface are smaller than in the proposed grid/row interface, but they are also much closer to each others. I believe that reduced visual search time compensates for the time saving gained with bigger targets. Furthermore, having items close to each other, should be equally good for most input devices (e.g., only one finger stroke needed on touch-pad and only finger/wrist movements needed with tablet input).

Tasks/Applications mostly fall into neat categories, so using similar interface for navigating categories of applications and folders of files should make sense. I would think that some visual differences between file and application browsers would help to prevent confusion between the two. E.g., icons could be a bit larger in the application browser ui and other appropriate eye-candy chances.

I have some doubts about tab-based organisation as well...
1. It relies on classification of programs, which can be a bit problematic due to bad metadata. For example, in the categories you provided in the screenshot, office applications are difficult to guess. Applications come in all strange varieties, and categorising can become unintuitive.. That's what I found out when I tried to [unsuccessfully] categorise the programs in my start menu a long time ago.
2. Is it reliable when dealing with lots of programs? That's the case with many using MS Windows, of course including myself.
3. It doesn't let the user see all the programs at once.. Depends on whether he wants to see them or no.

As said by hma, something like a mini-tracker would be good; provided we come up with a good category system. Otherwise, we can implement something like vista start menu - clicking the button will show the icons, which can then be filtered to get the file/app we want.

I like this idea about window-management but I always had these two doubts:
1. While this is great for novices, won't this cause the same probs that OS X Dock has [absence of file-name makes it difficult to distinguish between plain-text files..].
2. Will this handle multiple windows effectively...?

I agree with you that over-reliance upon searching can be painful [often do I just sit in front of the PC and wonder what the name is so that I can type it into the program launcher] but the thing is, if we're to employ a categorical system it has to be extremely effective otherwise will be more of a bane than boon, that's what I felt:

>>For example, according to Hick's Law, choosing from one menu of 10 items is faster than choosing form two menus of 5 items [Dan Saffer 2006, Designing for Interaction].<<
Hick's law is applicable only for its applicable only when the user knows the name of the item he wants and the data is available in a sorted form... Nevertheless doesn't this go in favour of my view i.e., fusing audio and video as multimedia? I don't think we would have more than five in audio and video as well..

I didn't say sub-categories, i said grouping - as in, editors are on top of the menu and viewers on bottom, etc.. Dunno how effective or detrimental this can be to the user experience though. Secondly, deeply thought out doesn't imply fuzzy subjective categories; but something that's not thought over means poorly designed categories that leads to confusion and frusturation which is exactly the point we are here to address. I'm not asking for well-defined categories for each kind of data.. if that's what you understood from my post for which I apologise. But yes, if the the number of categories is overwhelming or few but rigid, I don't think it can be called effective. I'm thinking of 4~6 categories..

>>Over doing it can also mean that the organization is technically correct accordingly logic, but incomprehensible to the users.
Agreed, just that we have to make sure that vital flaws dont creep in. The design doesn't necessary have to be limited to one person, or within the hands of the developer... Before the categories are implemented we might even take opinion of the users..

Your concept certainly seems interesting, there is both grouping and foldering implemented in a neat manner..

I hope an email client will also come up in the office category, and how about a calculator, office or accesoiry?

I think categorizing is just old thinking. Like trying to reduce much information by dividing it more into pieces which are not common to everyone. And because there are obviously programs which fullfill more roles and to make it even harder will get more roles as they get developed more (Google talk getting VOIP for instance)... you get what I mean?

I think the only *sure* way to categorize is to do that by applying a logical standard like can it edit or just view or both, which file types can it edit or view or playback or none (IRC), can it send and receive in that direction I'd go.

My mom will tell me she needs internet when she actually needs email but you can also have webmail so which one is it, the browser or the email program? Therefore I think it is important to realize that some people have an abstract goal and need to find the right way to get there.

Back to BeOS: with R5 it was obvious the Applications menu was too small to contain many many apps installed during the lifetime of an R5 install but 1 thing was divided very well; apps and prefs... Except for workspaces which is again a proof of how difficult it is to categorize IMHO! But back to R5, I would leave it like it is just change it's purpouse in that it should be a *prefered* or better, custom short list for users and adding buttons for Viewing all apps, categories View, search and perhaps category or search by file type it can open/edit and more...

When I installed Zeta and Phos I can tell you I spend more time finding apps and trying to remember in which category it was.

I seriously would not want that eventough I did experience bad behaviour which would have been solved by contraining window movement.

I believe that you came up with this also because of another 'problem', namely that the borders of a BeOS window are quite thin, and thus hard to grab (or even raising a different window beneath thus obscuring the window the user wanted to grab!).

A better sollution IMHO would be pressing the 'menu-key' found on modern MS Windows-branded ;-) keyboards while the particular window has focus and having a menu pop up with options to move, close, resize etc, the window.

And...I'd honestly like to know how you would combine "Window Movement Constraints" with your "F11, show desktop"-behaviour... ;-))

"I agree with you with one exception: progress indicators, like the throbber in the top right of a browser window, for example. The reassurance that my fellow codemonkey who wrote a program didn't hang the app is worth the extra visual distraction IMO."

OK so you come up with one example, well that's not enough. I strongly believe that when you're are using some programs long enough you don't need to see all of it or don't need them to be on top. Why couldn't you have a tiny instant message window on top for example? Maybe a an RSS feed too. And a weather indicator. And perhaps, stock info? Winamp?
You see I think multitasking is about having more than one window open, I see no need for maximized windows unless you want to concentrate on that particular window alone or need all the space you can have. Yes I read a about a program which could be made full screen on Mac OS X, yes I think it's a good idea but why should it always be the upper most?
Come on people, isn't it just that it has always been so that you think the program you are working with has to be the topmost window?

Maybe if the 'lower-window' function (right click tab) wouldn't lower a window to the bottom but just one below (-1). Like before you would have 4 windows, 1,2,3,4 and lowering the topmost (4) would do 1,2,4,3 instead of the now 4,1,2,3.

Going further I think a lot of newcomers will think "Oh where has that window gone?" Not realizing it is obscured below all the others. I think we'd need an animation for that too, like maybe temporarily make the window it has gone underneath transparent and opaque again so that one can see were the lowered window has gone too?

I found out that I can do everything concerning different (esoteric) window behaviour with KDE. I was playing with it right now and I see I can make it almost BeOS-like. (KDE even does a minimize animation like Windows does)

If you go to Control Center choose Desktop and after that Window Behaviour. In the Focus tab I set the Focus policy to Focus Follow Mouse (I dislike too much clicking, we can commence discussions about advantages/disadvantages elsewhere) and deactivated(!) Click to raise active window for testing how it is like when the window won't be raised when you click inside it. If you prefer click to focus set it to that.
In the Actions tab I set Titlebar double click to Minimize, and in section Titlebar & Frame, Left button to Raise, Middle button to operations menu and Right Button to Lower.
For section Inner Window, Titlebar & Frame I left the Modifier key to Alt, and then for the mouse buttons (in order): Raise, Resize and Move. The other tabs I left like they were before IIRC. Note that if you use Click to focus in the Focus tab, you might want to experiment with Activate/Rais/Pass click options in the Inactive Inner Window section and the Inactive section of Titlebar & Frame.

I must say I find the Control Center not the most intuitive piece of SW but it gets the job done. Funny is that the section Inactive Inner Window is useless for users which use Focus Follow Mouse same applies for the Inactive section.

If you want even more BeOS fun set Window decorations in Appearance and Themes to B II and set the colours in Colors to BeOS.

I agree.

It occurs to me that the idea of having an application exclusively placed in one category seems wrong. If, when working on task A, I think of a program as one category, but during task B, it's another, well, why not both?

I don't see why one would want to chain a user to any preset categories, either. Providing a very efficiently selected set makes things easier, and can demonstrate the power of the mechanisms provided, but there is no universally "correct" list. Some people will want to do very different things with their box than others.

On a different note, I'd like to point out that it would be nice to consider some mechanism for keyboard selection for this element. The Tracker Browser model seems to be an easier fit for that, as well.

Subcategories could be used to narrow the field in the case of overlapping categories, actually. That may bear some consideration as well, but I can't think of a good way to use that.