

Stripes: A Conceptual Operating System User Interface - ptomato
http://ignorethecode.net/blog/2009/11/23/stripes/

======
sjf
I thought we had moved on from Window's adaptive menus. Moving menu items
around inhibits the user, you can work more quickly if you know where the item
is going to be.

That said, I love the way you can search menus, this is a feature that every
toolkit should support. I don't know how long I've spent searching Gimp's
erratically organised menus.

I don't see how this is innovative though, he would want to have some very
convincing results from his usability tests.

~~~
thwarted
You find Gimp's core menus erratically organized or the extension/plugin menus
erratically organized? I've had issue with the more recent incarnations of the
preferences window, but the core Edit, Layer, Image menus I've had no problem
with. If you're often using a plugin, which have traditionally, for some
reason, been sorted into menus based on the language they're written in
(thankfully this has been getting attention in the 2.x releases, now a few
years old), then I can definitely sympathize.

Some filters and plugins might really be better if integrated into the core
menus, but then you run into problems with a plugin seeming to override a core
menu item (maybe this is desirable) producing a confusing interface for the
user. In this regard, Gimp had taken a play from the likes of KPT, where all
those cool filters were available as a separate (and guh, inconsistent)
menu/UI to call them out as separate (although, in the case of KPT, it seemed
to be more of a branding thing).

I think a lot of the problems stem from the need for a consistent UI being
incompatible with a tool that is infinitely extendable by the user via
installable plugins. You end up with something like the Windows 95 Start menu,
where all vendors were effectively encouraged to put things wherever they
wanted in the hope that you'd find them the easiest and/or associate the
application with their brand (all Adobe products being in the Adobe subfolder,
for example).

------
nekopa
It seems very interesting, but there is one thing I do not like, and that is
having the menubar on the side. I always feel as though I'm losing so much
screen real estate to it. (This is also the reason why I stopped using iGoogle
as my homepage) Does anyone have any links to usability research that shows
that having menus on the side vs the top is better? It looks like a few people
are going this way in their designs, and I am wondering if it is just to make
their product look different and new, or if there is actually sound logic
behind the changes.

------
pavlov
Some good ideas and a very well executed prototype are presented.

The window management concept seems very similar to recent mobile operating
systems, specifically the "card" concept in Palm's webOS and the tiled window
view in Nokia's Maemo 5.

It seems to me that the Stripes menu design presents too much information to
be applicable to small mobile devices with low-res screens (e.g. iPhone), but
it might be very effective on the new generation of mobile phones with higher
screen resolutions (Motorola Droid/Milestone, Nokia N900).

------
xtho
Stripes is also the name of a Java web framework. The world would be a much
better place if people did some research before naming their software.

I guess you won't drag and drop elements from one window to the other with
such a GUI.

~~~
LukasMathis
While the prototype does not implement it, the concept includes the ability to
show two windows at the same time.

~~~
xtho
I didn't mean to imply that it would be a bad thing if dnd from one window to
another wasn't possible. I personally hate the dnd metaphor, which IMHO is an
example of GUI designers gone wild, and would love to see it replaced with
something else.

------
cmelbye
This seems like it would be really nice on a small tablet/netbook. Although,
Moblin already exists and it's got a great user interface.

