Point #37 ("ubuntu spatial mode", where windows close if you open something from them) was forced in in the last week before the release (ignoring the freeze) by the Self-Appointed Benevolent Dictator himself...

(Reply) (Thread)

Sigh...

even with a decision like this, I still will stick with Ubuntu. Until there is a better alternative. I used to use Fedora, but was worried with Red Hat's policies. At least it was an entire company with procedures to follow before making any drastic changes. Now I have to worry about one single person's policies and mood swings. If only Gentoo didn't take so long to build...

(Reply) (Parent) (Thread)

It can be turned off, try /apps/nautilus/preferences/no_ubuntu_something in gconf-editor.

I don't think Gentoo is any more protected from this, I believe they still patch things, and you're still subject to the whim up the upstream ebuilder (or what ever they are called).

Debian has large groups of maintainers doing all the major projects, which normally prevents you from insanity. Of course, design by committee costs you 6 month delays and ever-sliding release dates.

(Reply) (Parent) (Thread)

Yup completely understood and known that it can be turned off. I was more worried about the fact that one person can push changes after freeze. This might result in a horrible 'first-time' experience for more inexperienced users especially since it wasn't tested enough, and there probably was not enough usability-study if the setting was actually right to change. It should have been 'browser-mode' by default if multiple windows were unwanted or left unchanged until Breezy. I can handle the change. People like my girlfriend, and my inexperienced colleagues, will be surprised especially after experiencing spatial in 2.8.

Gentoo was only a side comment. I just wanted to state the fact that I can customize it, but that while it is up to the maintainer of the ebuild, I can check the script, and modify it before actually compiling. I always found that I don't like modifying something that has been integrated well (like Ubuntu is).

(Reply) (Parent) (Thread)

The Ubunutu spatial Nautilus was a surprise when I first updated, but I think it works reasonably well. It's basically just an inversion of the old behavior for left vs. middle click. I agree that most of the time, people don't want to leave all the parent folders open as they browse for a file. Using the middle mouse to open a folder will leave both open.

I think the biggest problem is the inconsistency mentioned. Nautilus windows that don't map to a real folder (such as "Computer" or "Network") still exhibit the old behavior, which is very confusing.

(Reply) (Parent) (Thread)

I honestly hope GNOME never implements #1. I've always found that having a single menu bar at the top of the screen as Macs do both confusing and inefficient. Menu bars like that are leftovers from when Mac OS was primarily a single process operating system, and it should have been ditched long ago.

(Reply) (Thread)

...I've always found that having per-window menu bars is confusing (for the reasons he states) and inefficient (if you have 5 image viewers on screen, that's 4 more menubars than you need, all using precious pixels), and a holdover from the Windows 1.0.1 days where you couldn't have overlapping windows anyway (so it made some sense - but now you're as likely to need to foreground the window first anyway to get at the menubar).

#8 would be very nice to see too, mind.

(Reply) (Parent) (Thread)

Per-window menubars have been around in overlapping windowing systems before Windows 1.0.1. Having one menu bar for every application is confusing because then it is not directly connected with the application. It appears to be global, but function local to the application. If the focus is on the wrong window, for various reasons, it can lead to very confusing and potentially destructive behavior. It is not a waste of screen space because windows can overlap these days.

(Reply) (Parent) (Thread)

There are many good reasons for a single menu bar and there are some reasons against it. In any case, we should look at it objectively and weight out the pros and cons instead of arguing about our personal preferences.

Basically, the pros are:
- Less screen clutter, especially with many object windows on the desktop.
- It looks better. ;)
- Apps like GAIM and Gimp have trouble to put a menubar in those small windows, so they have to resort to ugly hacks (like Gimp) or limit the menu to just a few items (bad).
- Without it, there is no way to access the Nautilus menu for the desktop (without opening it as a separate folder).
- It also avoids inconsistencies like the desktop Places menu versus the Nautilus Places menu.
- The infinite height and consistent location, which can make it faster to use.

And the cons are:
- You have to focus a window before you can see and access the menu.
- Slightly more mouse movement especially after moving back from the menu. The weight of this issue depends a lot on how long your input device takes to travel the screen.
- It forces application-based thinking on the user. Then again, menus are already very application-based (preferences, help menu, etc), so this is not a huge loss.
- It takes away space from the upper panel and it would force us to incorporate the current desktop menu in the application menu.
- More effort required to implement it, many legacy applications won't ever support it.

In any case, to implement this properly we need a standard and we need a fallback for desktops which don't support it. I assume that on the desktop it would be implemented as a special applet (probably as a replacement for the current desktop menu), so not using it should be as simple as to remove the applet. It would generally be very similar to the current notification tray.

Daniel

(Reply) (Parent) (Thread)

As I said:
Having one menu bar for every application is confusing because then it is not directly connected with the application. It appears to be global, but function local to the application. If the focus is on the wrong window, for various reasons, it can lead to very confusing and potentially destructive behavior.

(Reply) (Parent) (Thread)

and I say: bullshit

mac users had the single top menu for ages without such 'destructive behavior', google for 'fitt's law' to have a clue why it is more usable (despite what you think is 'more usable') sure this guy is mac biased...

otoh, many gnome users will be alienated by this change, and that menu type is patented (?), so i'd prefer both options available... wait... don't we have this NOW?

(Reply) (Parent) (Thread)

So, mpt is working for Canonical? That last part of his blog was a surprise to me, and why is nobody else mentioning it. Most points of his post I'd agree with, although I think that many of them are showing some Apple bias (integrated music suite, no icons on buttons, etc) and some others are arguable. In any case, I have been a bit disappointed with Ubuntu's lack of attention to details of the interface (and the non-accidental Nautilus breakage made me seriously question if it's still the right desktop for me), so I'm very curious what this exactly means for future Ubuntu development. And if they'll listen to him. :) It would be great to learn more about this.

Of course many of his points are independent of Ubuntu and should be looked at by the GNOME community. For example, he mentions some Clearlooks issues, which we are mostly aware of already and will hopefully fix soon (mainly the rendering of prelighted pressed buttons).

Daniel

(Reply) (Thread)

Many computer users double click on UI elements when they only need to single click - I have seen people with 20 years' experience of computers double click on hyperlinks and menus. Which is why Ubuntu/Gnome should detect double clicks on menus and ignore the second click. ie Double clicking on the "Applications" menu should open the menu and leave it open. Currently (Gnome 2.10) the menu is closed again.

BTW - try it in Windows on menus and on the Start button. Microsoft observed users double clicking instead of single clicking on menus and modified Windows' behavior accordingly. Also notice that Windows has a bug on the IE/Explorer Favorites menu. It is the one place which does not abide by these rules.


ps I don't agree with all of the points in Matthew's post

- RichB

(Reply) (Thread)

I have felt for a while now, when connecting click signals to widgets, there should be a very simple add_click_debounce call for when you really don't want double clicks. From when I was trying recently, it seems very hard to currently implement debounce.

Obviously you would want a call to unimplement this too, but that's just an implementation details ;)

(Reply) (Parent) (Thread)

I must agree that there's some valid points I strongly agree with.

But the vast majority are just "What Ubuntu does different than Mac"

Take 1., for example :

Do you feel consistent to have the menu of an application in the border **outside** the windows of this application ?
If you want to be 100% rational, you would say no, a Mac user would say yes because he's used to this behaviour.

I agree that this is wasting screen space but :
- if your window is not in full-screen, you don't care about it
- if your window is in full-screen, then, IMHO, the title bar from the window manager must disappear, not the menu one ! (It's an idea to think about, it can be really good if we find a good use of it).

Also, take the 27 :
Everytime I shutdown, my computer ask me if I want to save the session. It seems very easy for me. If not, try it one time, you will understand.
But this guy come with a folder to put in a trash..WTF ? Come on !
When you quit, you can save or not your session. It can't be easier. No need to know what a folder is and so on.. Also, why would I put a "session" in the trash ? I can well imagine what putting a file in the trash is, but a "session-detail" ? What will be deleted ? Maybe all my icons and settings will be deleted. I can't say.

This is just one more example of people used to Mac and who can't imagine another logic.

But, for example, 19 or 37 are fully relevant !

I think that he's got it for all little details that we never see because we are used to it, or because nobody took the time to fill a bug report about it (I see the bugzilla entry : "Same-gnome must be spelled Same Gnome" ;-) )

But for the generality, he just didn't understand that he was using another system, not MacOSX.


(Also, I wonder if I use the same Ubuntu : 46 works for me)

(Reply) (Thread)

Totally agree. Most of the complaints seem to be subjective and biased to an OSX user and some seem to be just plain wrong.
Take 33 for example, while I agree shutdown is somewhat slow, the dialog that is displayed on Gnome logout has a shutdown option available. No need to wait for the GDM screen to do the shutdown.
Or 36... I've read other "reviews" that praise the right click to rename instead of a double click/click and type.

Then of course many of the other nits are perfectly valid.

(Reply) (Parent) (Thread)

I take issue with number 3.

3. By default, many – but not all – push buttons and menu items have an icon as well as text. As well as making the interface more cluttered, this slows people down by misleading them into thinking that they can decipher a transient control's icon faster than they can read its text, which is rarely if ever true.

Maybe I am just more visual than the author, but I find that I can scan for an icon almost instantly, O(1), whereas I have to read each item on OSX, O(N).

(Reply) (Thread)

I should add that, in general, he has a lot of really good points that Gnome would be wise to follow.

(Reply) (Parent) (Thread)

I don't like the idea of applying O-notation to human pattern matching. We're just too complex for that.

For example, when sorting papers I have found myself thinking, this is O(n²), I could do this in O(n.log n). I then found that implementing an O(n.log n) algorithm was significantly slower.

Wetware is fantastic at things we have a lot of trouble teaching computers to do, and really bad at doing things computers do in seconds. I guess that's the point though, isn't it?

(Reply) (Parent) (Thread)

It's true that big-O notation doesn't tell the whole story, but for me the two constants are similar.

I can't find it now, but I know I've seen a reference somewhere about the ability of the visual system to find colored words in a block of text far faster than finding words by text alone. I think it applies here, too. That is, if I'm looking for a “save” option, it will be something with a blue square to the left of it.

(Reply) (Parent) (Thread)

I would say that there is little-bit truth in using O-notation, if you only separate problems into classes O(1) and O(n).

The reason is that human brain does some processing in parallel and some serial. So the tasks that can be done in parallel processing are fast and can be thought as O(1). Serial tasks require access to working memory and thus cannot be fully concurrent and therefore can be thought as O(n). Of course the actual story is more complex. It seems reasonable that simple picture recognition/matching is done pretty much in parallel in the brain, and text matching requires access to working memory. The processing used depends certainly on the picture, text, search context, user (and how accustom the text/picture is to the user and how easy it is to separate them from the current context).

Actually cognitive scientists separate brain processes two 3 systems:
S1, S2, S3.
S1 being the parallel one; S2, S3 serial ones (each having subsystems of their own).
If you're interested in more theory behind the UI design and human cognition, take a look at this article:
http://patsula.com/usefo/episodicmodel/index.shtml

Although the article only has examples about UI design of gas ovens :), it contains lot of interesting insights about learnability of UI designs.

Best,
Jaak

(Reply) (Parent) (Thread)

Although I didn't plan to go into such detail I made a fairly long response going through his comments almost point by point.
http://livejournal.com/users/alanhorkan/1213.html

(Reply) (Thread)