Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Fri, 2011-03-18 at 23:38 -0300, Conscious User wrote: I should mention, though, that in my opinion the fact that Unity merges the titlebar with the panel makes the dragging slightly more intuitive: you drag the titlebar to the thing it's going to be merged to. Perhaps *too* slightly to make a difference, but does help. that's one hell of a point there ;) now how do you know how best to drag it back out of there? drag handles should help us find draggable areas on objects more easily.. is there any spec on how and where such handles should be used in design? And altogether.. moving away from GNOME more and more, is there a HIG for Ubuntu Unity design at all? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On 28/03/11 11:44, Vishnoo wrote: We really need to collect mass user data as to how people are using their application windows, at what sizes they use the app and how often they are resizing. While I absolutely agree on collecting user data, I am concerned with the idea that we then try to find a highest common multiple and force everyone to use it. FOSS is about choice, not conforming to predefined norms. David ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Mon, Mar 28, 2011 at 6:25 AM, David Stevenson da...@avoncliff.com wrote: FOSS is about choice, not conforming to predefined norms. Users are more than welcome to choose to use something else, you know. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Mon, Mar 28, 2011 at 1:25 PM, David Stevenson da...@avoncliff.com wrote: On 28/03/11 11:44, Vishnoo wrote: We really need to collect mass user data as to how people are using their application windows, at what sizes they use the app and how often they are resizing. While I absolutely agree on collecting user data, I am concerned with the idea that we then try to find a highest common multiple and force everyone to use it. FOSS is about choice, not conforming to predefined norms. David This is incorrect and I wish if that particular meme died. FOSS isn't about choice. It is about providing source code and a set of accompanying freedoms to all users in the case of Free Software. The choice one has is simply a byproduct of the availability of the source code. It does not give the user any legal, moral or ethical right to force the developer to provide options for some user's UI perceived problem. In fact I believe that the whole FOSS is about choice meme is damaging to providing high quality user interfaces on Linux, simply because FOSS developers have historically been coders with little (in)formal education in the problem of user interface design and it was easier for them to simply add an option in the GUI every time a design choice confronted them. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Monday, March 28, 2011 5:44 AM Vishnoo wrote: However, for app like Web-browsers, main window of email clients,inkscape,..., they should probably open at maximum screen size. Eventhis depends on the hardware. If someone has a 24 monitor, they mightnot need the window at that size. While for laptops/15 monitors amaximum window size might be good for these apps.A couple of problems come to mind with fixed window sizes. In all cases one must consider that I have very poor visual acuity. 1) For quite some time 'gcalctool' has followed a fixed size principle which has prompted me to use 'galculator' which allows me to grab one corner and expand the window to a usable size for my own needs. 2) Another good example of fixed window size being problematic is in ubiquity and described here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/628097 please notice in post #12 I reference bug 715401 which is a different example (one of several) describing how the fixed window size results in some ubiquity windows running off-screen (aka: not fitting) with certain small screens. 3) Due to my aforementioned poor visual acuity I bump the screen resolution of my 22 widescreen from it's native 1680x1050 to 1440x900, and I still need to run most apps, like browsers, text editors, word processors, etc in a maximized window. But if one of my children or grandchildren uses the computer I set the resolution back to it's norm and they quite often work in the same workspace with 2 or 3 apps displayed at the same time. I did the same before my eyesight began to fail :^) I'd hate to see us remove so much of the ability to customize Ubuntu that we drive people to a different DE, or worst yet, a different distro. If we want to make any improvements we need to collect a large pool ofuser data like how Firefox did to reduce its menu (yea, I know you hatethat FF menu ;p )We really need to collect mass user data as to how people are usingtheir application windows, at what sizes they use the app and how oftenthey are resizing.I can't totally disagree with that but we shouldn't let the majority decide to eliminate functions or the ability to customize as may be needed by various small corner groups such as the visually impaired. Thanks to all for the great work on Unity so far, Lance ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Mon, 2011-03-28 at 06:27 -0700, Lance wrote: A couple of problems come to mind with fixed window sizes. In all cases one must consider that I have very poor visual acuity. Hmm? I did not mention that the windows need to be a fixed size only or to remove any feature. :-) What I was replying to MPT is that a maximized state is not a feature to be rooting for. And as a consequence we should look into having a good default for apps (including those which need a maximum size window). I just mentioned what the default size could be, and how to get to an ideal default size for most users. (of-course we should be able to resize the windows, and we need to put more effort and thought into tiling ). -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Monday, March 28, 2011 09:18:35 am zekopeko wrote: On Mon, Mar 28, 2011 at 1:25 PM, David Stevenson da...@avoncliff.com wrote: On 28/03/11 11:44, Vishnoo wrote: We really need to collect mass user data as to how people are using their application windows, at what sizes they use the app and how often they are resizing. While I absolutely agree on collecting user data, I am concerned with the idea that we then try to find a highest common multiple and force everyone to use it. FOSS is about choice, not conforming to predefined norms. David This is incorrect and I wish if that particular meme died. FOSS isn't about choice. It is about providing source code and a set of accompanying freedoms to all users in the case of Free Software. The choice one has is simply a byproduct of the availability of the source code. It does not give the user any legal, moral or ethical right to force the developer to provide options for some user's UI perceived problem. In fact I believe that the whole FOSS is about choice meme is damaging to providing high quality user interfaces on Linux, simply because FOSS developers have historically been coders with little (in)formal education in the problem of user interface design and it was easier for them to simply add an option in the GUI every time a design choice confronted them. Personally I wish the alternate meme, that it's possible to create one magically wonderful design that will work for everyone so we don't need options would die. The truth is somewhere in between and different projects have been too far to one or the other extreme and we need to find balance. Balance is particularly difficult to achieve through low bandwidth communication mediums we normally use in distributed development. Scott K ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Spike Burch wrote on 28/03/11 12:38: ... Users are more than welcome to choose to use something else, you know. ... Yeah, but if you keep saying that often enough, they will. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Qt7MACgkQ6PUxNfU6ecrGwwCgvnEGLHGfu4TxcFnK0vqhWp1f UIoAn1oy4C3Ymr68ia5QpGZHs/GISE51 =HCBy -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
One possible option is to split the desktop into 9 sections (rule of thirds) and use combinations of those sections as the only size options available. This would allow easy modulation of existing windows and would be largely backward-compatible with existing software. Browser windows usually already take up an area that would be about a 4 block square when we use them on a typical desktop. GIMP could even rotate one palette to horizontal and fit the canvas into the upper 4x4 square and the palettes into the 3x1 and 1x2 spaces left over Or you could have the option to split one box into 9 boxes if needed, providing 81 possible boxes. This would allow GIMP to remain in its current default window config. Resizing isn't dead, it is definitely useful, we just want to drastically reduce the amount of time we spend doing it. Modularized window sizes and positions would limit your choices drastically, and make choosing a window size and position no longer a time-wasting task as well as be visually more pleasing, based on an already known rule of composition. On Tue, Mar 22, 2011 at 7:08 AM, Matthew Paul Thomas m...@canonical.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vishnoo wrote on 19/03/11 04:31: On Fri, 2011-03-18 at 16:24 +, Matthew Paul Thomas wrote: I think the Gnome Shell designers are badly underestimating the use cases for minimize. No, they havent. I take it you havent read Owen's Mail on the Shell ML.. :-) I had. He listed some use cases for minimize but not all, he identified workspaces as an arguable substitute for some of those use cases, his user data was from two geeks at work, and he was honest in admitting that he didn't really know whether it was a good idea. ... And anyone who thinks dragging is a replacement for a maximize button probably hasn't done any user testing recently. Maximize is not a feature we should be encouraging, *anywhere* ! It is a workaround for a broken window management. Why in the world does the *user* need to constantly maximize/restore? Nobody is suggesting that. Apps need to open the windows with the right size. And any app which requires the user to constantly resize is broken. Sure, but I don't see how that's relevant. Maximization and constant resizing are very different things. For apps requiring a maximum size, window should just open so. Right now, for any alternate *custom* size one would require to either: 1- restore a maximized window and - then resize to custom size or 2- resize a window from the normal state to custom size Maximize just makes it harder to get to custom sizes. Why even have it Because the lack of maximize (or something like it) would make it harder to focus complete attention on something. ? (I hope maximize just gets killed, only then will apps fix at their end. ;p) Do you have a specific suggestion? What should a text editor program do, for example? I seriously dont understand why this fascination for resizing/resize grips exists. I'm not saying that resize feature should not even exist, but Resize is something user should not even care about, and should spend less time doing. Resizing grips are not the only way of allocating screen space between tasks. Tiling is another well-known mechanism, but it is less visually stable and requires a greater investment of time. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2IkUsACgkQ6PUxNfU6ecqJRwCgozTllk3DawsxHV3Nz8mh4r8e ilIAnjfdI8Z2ks8PbMZff2pLh3dsab6J =ikoJ -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Menu hiding is one of the risky moves we are making. Initial tests on unsuspecting users have shown they find 'em quickly and easily enough. I agree with you, though, that a hint to their existence and anchor (left-of-the-File-menu) would be nice. That can come in a refinement, mockups and patches welcome. - Mark Shuttleworth, 20 hours ago. I guess there is no point in discussing this anymore, the man has decided. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Hello guys! If there is no menu item in the hidden menu bar, on mouse over there should be no action (the title of the application should not be shorten). ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Fr, 2011-03-18 at 19:15 +0100, Mitja Pagon wrote: I agree with you, though, that a hint to their existence and anchor (left-of-the-File-menu) would be nice. That can come in a refinement, mockups and patches welcome. Please forgive me if I provide no link, but there's either a bug report in LP where the right people participated, IIRC including the SABDFL, or it was some blog post, in which it was stated that the actual plan was to fade-in the menus when the mouse moves in their direction. It was described as similar to the Notify-OSD bubbles (but becoming *more* visible on approach, obviously). However, X does currently not want to play this game. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Matthew Paul Thomas wrote: ... (I pretty much agree with the paragraphs before, so I'm simply omitting them...) I think the Gnome Shell designers are badly underestimating the use cases for minimize. Maybe... but the problem is, so is Unity, at least currently. It didn't remove minimization but made it... weird. And anyone who thinks dragging is a replacement or a maximize button probably hasn't done any user testing recently. Ok, admittedly I'm biased on this one because Aero Snap is one of the things I went faster from discovering to using all the time... And even before that I was fond of the double click. In guess in my mind the max button is already useless... I should mention, though, that in my opinion the fact that Unity merges the titlebar with the panel makes the dragging slightly more intuitive: you drag the titlebar to the thing it's going to be merged to. Perhaps *too* slightly to make a difference, but does help. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Fri, 2011-03-18 at 16:24 +, Matthew Paul Thomas wrote: I think the Gnome Shell designers are badly underestimating the use cases for minimize. No, they havent. I take it you havent read Owen's Mail on the Shell ML.. :-) They know what use-cases they havent fixed (or dont have a better solution for). Minimize just doesnt fit their design. And anyone who thinks dragging is a replacement for a maximize button probably hasn't done any user testing recently. Maximize is not a feature we should be encouraging, *anywhere* ! It is a workaround for a broken window management. Why in the world does the *user* need to constantly maximize/restore? Apps need to open the windows with the right size. And any app which requires the user to constantly resize is broken. For apps requiring a maximum size, window should just open so. Right now, for any alternate *custom* size one would require to either: 1- restore a maximized window and - then resize to custom size or 2- resize a window from the normal state to custom size Maximize just makes it harder to get to custom sizes. Why even have it ? (I hope maximize just gets killed, only then will apps fix at their end. ;p) I seriously dont understand why this fascination for resizing/resize grips exists. I'm not saying that resize feature should not even exist, but Resize is something user should not even care about, and should spend less time doing. -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Why in the world does the *user* need to constantly maximize/restore? Apps need to open the windows with the right size. And any app which requires the user to constantly resize is broken. Maximize does have a lot of very nice use cases, as it can help a user focus on the task they're trying to complete. I want to work in my web browser, and I don't want to have to think about other things. It's tied to why resizing a window is an important feature as well. It allows me to have control over my workflow, and I can set up a sort of ratio. I want 50% of my work directed towards my browser, 25% towards monitoring my social networks with gwibber, and 25% towards watching my contacts for someone I want to chat with. And, I can set them up how I want, not how the system thinks I want them. Computers aren't good at guessing what users want; any Microsoft convert can tell you that. This case is simple, but it should serve to demonstrate the basic idea. Could the automatic sizing be implemented? Sure. Is it a good idea? Why not? But the user should be able to change the size of the window after they've started it, either because their preference at that moment differed from the system's guesses, or because the focus of their work has changed, and they want a different setup. On Fri, Mar 18, 2011 at 22:31, Vishnoo v...@ubuntu.com wrote: On Fri, 2011-03-18 at 16:24 +, Matthew Paul Thomas wrote: I think the Gnome Shell designers are badly underestimating the use cases for minimize. No, they havent. I take it you havent read Owen's Mail on the Shell ML.. :-) They know what use-cases they havent fixed (or dont have a better solution for). Minimize just doesnt fit their design. And anyone who thinks dragging is a replacement for a maximize button probably hasn't done any user testing recently. Maximize is not a feature we should be encouraging, *anywhere* ! It is a workaround for a broken window management. Why in the world does the *user* need to constantly maximize/restore? Apps need to open the windows with the right size. And any app which requires the user to constantly resize is broken. For apps requiring a maximum size, window should just open so. Right now, for any alternate *custom* size one would require to either: 1- restore a maximized window and - then resize to custom size or 2- resize a window from the normal state to custom size Maximize just makes it harder to get to custom sizes. Why even have it ? (I hope maximize just gets killed, only then will apps fix at their end. ;p) I seriously dont understand why this fascination for resizing/resize grips exists. I'm not saying that resize feature should not even exist, but Resize is something user should not even care about, and should spend less time doing. -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Ian Santopietro CEO - Prodigy Games Eala Earendel enlga beorohtast Ofer middangeard monnum sended Pa gur yv y porthaur? Public GPG key (RSA): http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x412F52DB1BBF1234 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luke Benstead wrote on 15/03/11 21:53: ... Erm, I hate to point out the obvious, but why don't we just put the menu back in the windows and abandon appmenu as a failed experiment? Keep the title and window controls in the panel for maximized windows only (at least just for Natty). I can already imagine the replies to this email, so let me save you guys the trouble: 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I don't think it should be used as an overriding reason to squash, overlap, and generally complicate a UI and shove it into an edge. I especially don't see why Fitt's law is so important for menu bars, when users get on perfectly fine with buttons, sliders, window resize grips and icons, and well, everything else. That's looking at it backwards, I think. Screen edges are efficient target areas for whatever is put there. Given that, what should they be used for? Menus are used a lot, ergo, they're a good candidate to be made more efficient. 2. Someone will likely bring up the space saving of the global menu. Firstly, the global menu only saves vertical space on a maximized window, on non-maximized windows they only save on chrome. It also saves space whenever two or more windows are stacked vertically. By keeping the title in the panel for maximized windows, we are still saving 22px on Gnome 2, with the removal of the bottom panel that brings it up to 44px. It's about finding a balance of space saving vs usability and I really think we have shot past that balance point with the global menu. Space saving vs usability is a false dichotomy. Space saving reduces scrolling and memory load, which is part of efficiency, which is part of usability. So, the question again raised is why exactly are we using a global menu? Benefits: * Much faster to use. * Saves vertical space. * Menus no longer need to be cramped by, or overflow beyond, the window width (e.g. Empathy, Gimp, Inkscape). * Menus no longer surprisingly open upwards when the window is near the bottom of the screen. * Allows the desktop to have the same menus as any other folder (which, in turn, will reduce the complexity of context menus). * In future, will allow dialogs to have Edit, Help etc menus consistent with other windows. * In future, will allow visual unification of title bars and toolbars. I know I've brought it up before, but alongside the issues we are having fitting it into the panel with the title, it also brings issues with dual monitors, large resolutions and focus-follows-mouse. It doesn't fit all use cases. ... Dual monitors are not a problem (though if they're stacked vertically, the bottom one loses its speed benefit). Large screens make the menus a bit slower, but not nearly as slow as they would be inside windows. The loss of focus-follows-mouse is a real tradeoff, though. (I've specified how it could be made compatible, but no-one has been interested enough to work on it yet.) - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2B7wIACgkQ6PUxNfU6ecr/hgCfQmwbIB8XbywmWUL6zHOJRAI8 nMkAmwbgxluzK5tYZjwp0HOM9Ssl+xFR =PTeU -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman wrote on 16/03/11 12:42: ... A bug is a bug no matter who files it. If we're down to it's only a real bug if certain people file the bug, then that's a real problem. ... I totally agree. I don't think my bug reports should get special treatment because I work at Canonical. But I do think bug reports are more likely to be valid if they're from the person who maintains the specification for the relevant feature, no matter who they work for. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2B8HcACgkQ6PUxNfU6ecqdUACguwvgaUg4DFIfy0QKpWY6y3lH iv8AnjnXwZVVolknhchlF/TYmioPazJ7 =tmJG -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Ian Santopietro wrote: What about flashing the menu with the title for the first, say, five seconds that the window is open. That gives an indication as to where the menu is, reduces visual clutter, and allows the user to get a quick preview of what menu headers are available (File, Edit, etc.) without losing the supposed benefit of the global menu. Perhaps a nice quick fading animation would help keep this from being jarring. Frankly, this sounds like the kind of heat-of-the-moment workaround that brought Unity to its current state in the first place. The impression I have is the current design is a pile of workarounds: + Let's merge the titlebar and the panel when the window is maximized and show the menubar. The title is not that important. - Oops, now the menubar position differs in maximized windows because of the buttons. - Ok, then let's fix it on that position. - Oops, ugly gap for non-maximized windows. - Ok, let's put the title there. - Oops, titles can have different sizes. - Ok, let's truncate it. - Oops, this is ugly. - Ok, let's show the entire title by default and the menu on hover. - Oops, now it's inconsistent with maximized windows. - Ok, let's do the same for maximized windows. Hey, this brings the title back for maximized windows. Win! With admittedly some poetic license, this is how I picture it: a series of local optimizations losing track of global optimization. Instead of trying to fix the current situation, I prefer going back to when the menubar was fully visible and the titlebar didn't merge with the panel, and restarting to think from there. My personal suggestion would be dropping the title in the panel as mpt suggested, but keeping the idea of merging the titlebar and the panel. This means dropping the title entirely in the maximized case, yes. I don't think anyone would really care. For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. This would leave only the space of a single close button to worry about and this could be addressed by something with a fixed size that does not need to be truncated: AN ICON. Matter of fact, I WOULD suggest placing this icon even when the window is maximized and storing a menu with window management options in it, just like you already have depending on your metacity settings. Close *is* a destructive function you don't want near File, after all... But I won't seriously support this second suggestion for the moment, because I suspect that would make closefests of maxmized windows too inneficient, and this is bad for netbook users. Thoughts? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Thu, Mar 17, 2011 at 17:14, Conscious User consciousu...@aol.com wrote: My personal suggestion would be dropping the title in the panel as mpt suggested, but keeping the idea of merging the titlebar and the panel. This means dropping the title entirely in the maximized case, yes. I don't think anyone would really care. For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. This would leave only the space of a single close button to worry about and this could be addressed by something with a fixed size that does not need to be truncated: AN ICON. Awesome. Just awesome. This fixes everything, doesn't it? Matter of fact, I WOULD suggest placing this icon even when the window is maximized and storing a menu with window management options in it, just like you already have depending on your metacity settings. Close *is* a destructive function you don't want near File, after all... But I won't seriously support this second suggestion for the moment, because I suspect that would make closefests of maxmized windows too inneficient, and this is bad for netbook users. Thoughts? I do see a problem with that last one: how is a user going to figure out how to close the window? An (X) button has familiar meaning, but an application specific icon is probably not the first place a user would look. Also, now your icon menu and File menu are located next to each other and have the same item at the end: Close. -- Remco ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Hello, My 2 cents also about global menu, as just a normal and daily user (both personal and professional use of Ubuntu), not a developer nor a designer. I like it very much as it is right now, because : - It allows space saving and is very nice - For me it is not a problem that window title hides the menu at first until we go with mouse on it. Apart new users - but those will also have to learn Unity, Dock, Linux... we know it and it is very common, easy after to get at the right place to see the menu. Often, there are buttons for most common actions in the soft that replace it. - there is homogeneity (I could say Unity !) between all applications, even Firefox, Thunderbird, LibreOffice and all things related to menus are in panel at top of the screen. It does not work for the moment for softs like Videolan but as it is not a native Ubuntu application, I understand it is not a top priority. On the contrary, for Videolan, it's better because most often I use it un-maximized, so I have menus near the window. That's the second point, the only thing I would change to Global Menu IMHO : Keep window title over-riding menus and see them when mouseover, but for un-maximized window, as the title is displayed in the window, put also the menus on mouseover in this place in the window, it allows less mouse move to activate them. Some apps, like Videolan, Empathy... are commonly used in small size and placed everywhere in the screen, not always at top. Keep maximized and minimized buttons please, it's perfect like that. Remember position of a window : with Tomboy for example, even if I maximize a note, at next startup, it re-launches reduced in top left corner... By the way, it will be impossible to satisfy everybody, so we'll see what it's decided, the less we can do is to explain our choices and their consistency. It's just surprising that such an important discussion is not solved and takes place 1 month before final release ! I also hope that, perhaps not for Natty but for 11.10, Ubuntu will allow us a little configuration as it was fully possible in Gnome panel - for example dash, apps and Places shortcuts, order on the windows in the screen for switch between different instances... Best regards, Xavier ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Thu, 17 Mar 2011, Xavier Guillot wrote: - For me it is not a problem that window title hides the menu at first I bet there's a possible solution somewhere with blurring/transparaceny. The model used with the notification pop-ups is that they are transparent to click-events and blur/fade when moused-over, which is effectively what the window-title/menu also does on mouse-over. -Paul ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. I can see getting rid of the maximize button, as Gnome has a point there. However, I don't feel their argument for getting rid of the Minimize button applies to Unity. It works great for Gnome, but we still have somewhere to minimize windows to in Unity, thus the Minimize button has a point. And, three buttons provides a natural feel and is aesthetically pleasing. You can't get that unless you go down to one; two won't work. And, like I said, we need to keep the minimize button while it does something. On Thu, Mar 17, 2011 at 10:14, Conscious User consciousu...@aol.com wrote: Ian Santopietro wrote: What about flashing the menu with the title for the first, say, five seconds that the window is open. That gives an indication as to where the menu is, reduces visual clutter, and allows the user to get a quick preview of what menu headers are available (File, Edit, etc.) without losing the supposed benefit of the global menu. Perhaps a nice quick fading animation would help keep this from being jarring. Frankly, this sounds like the kind of heat-of-the-moment workaround that brought Unity to its current state in the first place. The impression I have is the current design is a pile of workarounds: + Let's merge the titlebar and the panel when the window is maximized and show the menubar. The title is not that important. - Oops, now the menubar position differs in maximized windows because of the buttons. - Ok, then let's fix it on that position. - Oops, ugly gap for non-maximized windows. - Ok, let's put the title there. - Oops, titles can have different sizes. - Ok, let's truncate it. - Oops, this is ugly. - Ok, let's show the entire title by default and the menu on hover. - Oops, now it's inconsistent with maximized windows. - Ok, let's do the same for maximized windows. Hey, this brings the title back for maximized windows. Win! With admittedly some poetic license, this is how I picture it: a series of local optimizations losing track of global optimization. Instead of trying to fix the current situation, I prefer going back to when the menubar was fully visible and the titlebar didn't merge with the panel, and restarting to think from there. My personal suggestion would be dropping the title in the panel as mpt suggested, but keeping the idea of merging the titlebar and the panel. This means dropping the title entirely in the maximized case, yes. I don't think anyone would really care. For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. This would leave only the space of a single close button to worry about and this could be addressed by something with a fixed size that does not need to be truncated: AN ICON. Matter of fact, I WOULD suggest placing this icon even when the window is maximized and storing a menu with window management options in it, just like you already have depending on your metacity settings. Close *is* a destructive function you don't want near File, after all... But I won't seriously support this second suggestion for the moment, because I suspect that would make closefests of maxmized windows too inneficient, and this is bad for netbook users. Thoughts? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Ian Santopietro CEO - Prodigy Games Eala Earendel enlga beorohtast Ofer middangeard monnum sended Pa gur yv y porthaur? Public GPG key (RSA): http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x412F52DB1BBF1234 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I don't feel their argument for getting rid of the Minimize button applies to Unity. It works great for Gnome, but we still have somewhere to minimize windows to in Unity, thus the Minimize button has a point. Several problems here: 1) The somewhere to minimize to was only *one* of the arguments, and not even the main one. The Shell has always been designed without taking minimization into consideration, for encouraging the use of workspaces to organize clutter. The fact that the Shell didn't have such place in its final form was more of an argument to forget about bringing minimization back, for legacy purposes, than to actually removing it in the first place. 2) Gnome could've used the Shell Dash perfectly to hold minimized applications if this place argument was the only one. In fact, ever since the Unity launcher got autohide there isn't much difference between the two with respect to this purpose. 3) The somewhere to minimize windows in the Unity launcher is a single icon for multiple application windows that uses Expose for switching. Fitting minimization in this would imply a) not including minimized windows in the Expose, creating situations where either Expose gets in the way of restoring or vice-versa b) including minimized windows in the Expose, effectively either annoying people who minimize windows to temporarily remove them from the workflow or making you question what was the purpose of minimizing in the first place This could be solved by showing minimized windows in the Expose with less priority, like miniaturized or in icon form. OSX does this. However, Mark said once in this list that he wants minimized windows to appear full-fledged in the Expose, so we are dealing with (b) Unity will ship a form of minimization that is unfamiliar and with questionable usefulness. I'm not sure if this is better than not shipping at all. :) And, three buttons provides a natural feel and is aesthetically pleasing. You can't get that unless you go down to one; two won't work. This is largely irrelevant since I'm still defending killing minimization but... what? From where this remarkable certitude on such a subjective matter, that does not even require any kind of justification, came from? :) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
This is largely irrelevant since I'm still defending killing minimization but... what? From where this remarkable certitude on such a subjective matter, that does not even require any kind of justification, came from? :) No Problem: http://en.wikipedia.org/wiki/Composition_(visual_arts) http://en.wikipedia.org/wiki/Composition_(visual_arts)Basically, in visual composition, when there are multiple objects involved, it becomes pleasing to have one item surrounded by an even number of objects (Thus an odd number). Five, IMO, brings clutter, particularly to window buttons, and one would be fine, but two lacks balance. On Thu, Mar 17, 2011 at 16:08, Conscious User consciousu...@aol.com wrote: I don't feel their argument for getting rid of the Minimize button applies to Unity. It works great for Gnome, but we still have somewhere to minimize windows to in Unity, thus the Minimize button has a point. Several problems here: 1) The somewhere to minimize to was only *one* of the arguments, and not even the main one. The Shell has always been designed without taking minimization into consideration, for encouraging the use of workspaces to organize clutter. The fact that the Shell didn't have such place in its final form was more of an argument to forget about bringing minimization back, for legacy purposes, than to actually removing it in the first place. 2) Gnome could've used the Shell Dash perfectly to hold minimized applications if this place argument was the only one. In fact, ever since the Unity launcher got autohide there isn't much difference between the two with respect to this purpose. 3) The somewhere to minimize windows in the Unity launcher is a single icon for multiple application windows that uses Expose for switching. Fitting minimization in this would imply a) not including minimized windows in the Expose, creating situations where either Expose gets in the way of restoring or vice-versa b) including minimized windows in the Expose, effectively either annoying people who minimize windows to temporarily remove them from the workflow or making you question what was the purpose of minimizing in the first place This could be solved by showing minimized windows in the Expose with less priority, like miniaturized or in icon form. OSX does this. However, Mark said once in this list that he wants minimized windows to appear full-fledged in the Expose, so we are dealing with (b) Unity will ship a form of minimization that is unfamiliar and with questionable usefulness. I'm not sure if this is better than not shipping at all. :) And, three buttons provides a natural feel and is aesthetically pleasing. You can't get that unless you go down to one; two won't work. This is largely irrelevant since I'm still defending killing minimization but... what? From where this remarkable certitude on such a subjective matter, that does not even require any kind of justification, came from? :) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Ian Santopietro CEO - Prodigy Games Eala Earendel enlga beorohtast Ofer middangeard monnum sended Pa gur yv y porthaur? Public GPG key (RSA): http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x412F52DB1BBF1234 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On this subject I'd like to reiterate and support a suggestion previously made on this list: https://lists.launchpad.net/ayatana/msg04555.html ☮♥☯ Greg K Nicholson http://gkn.me.uk ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
No Problem: http://en.wikipedia.org/wiki/Composition_(visual_arts) Basically, in visual composition, when there are multiple objects involved, it becomes pleasing to have one item surrounded by an even number of objects (Thus an odd number). Five, IMO, brings clutter, particularly to window buttons, and one would be fine, but two lacks balance. Those are way too subjective and general to justify the degree of certitude your tone had. There are many ways to question it. But since now you added an IMO to your statement, there is no point in discussing this further. Feel free to drop me a private email if you want to, though. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
+1 On Thu, Mar 17, 2011 at 6:30 PM, Greg K Nicholson g...@gkn.me.uk wrote: On this subject I'd like to reiterate and support a suggestion previously made on this list: https://lists.launchpad.net/ayatana/msg04555.html ☮♥☯ Greg K Nicholson http://gkn.me.uk ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Le mardi 15 mars 2011 à 16:37 -0700, Dylan McCall a écrit : After several weeks of trying, last week I finally succeeded in installing Natty to test Unity. I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. I reported a bug about this, but John Lea marked it as Invalid on the grounds that this change request contradicts the design. He requested that I discuss it here. […] I have a simple proposal to fix these problems: The application title should be removed from Unity's menu bar. I'm reliably informed that this would be extremely low risk, in that it would involve changing two lines of code. - -- mpt Today I have been working on my fix for bug #716177: https://bugs.launchpad.net/unity/+bug/716177 Right now, the panel acts like the titlebar for the current maximized window, but only if it's in focus. That leaves a big hole where a maximized window is visible and it isn't in focus, but the top panel still looks like it should correspond to that window. (The tldr version: try using GIMP, maximized, without frowning). My patch makes the top panel's draggable area relate to the front-most maximized window regardless of who is in focus. For your information, I hold this merge request specifically on that discussion outcome and added some information one the bug report as well. (what is funny is that I was thinking how many false positive I trigger everyday closing the wrong application). Didier ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
And what may those advantages be? Not every application is a web browser and not all applications are the same, so this "trend" Chrome supposedly started does not automatically apply to all and every application. Also this quest for abolishing menus is complete nonsense propagated by people who mostly know nothing about user interface design / interaction design, user experience design , and this place (ayatana list) is, despite an occasional good idea, littered with people like that. Sometimes it makes me feel like most people use Ubuntu to just to surf pr0n.Different people have stated multiple issues with this hidden menus integrated title/controls and many more issues arise when trying to tackle those issues while the benefits are almost non existent, and that is a dictionary example of bad design.Cheers,MitjaMitja PagonInueni d.o.o., Pot pod Gradiščem 4, SI 4202 NakloTel.: +386 41 521 729e-naslov: mitja.pa...@inueni.com, url: www.inueni.com- Original Message -From: "Marc Lajoie" manorap...@gmail.comTo: appi2...@gmail.comCc: Ayatana@lists.launchpad.netSent: Wednesday, March 16, 2011 3:20:51 AMSubject: Re: [Ayatana] Design problem: Menus hidden by default in UnityI, for one, love the integration of the menu and titlebars into the panel in Natty. The decluttering of the workspace, or the "chromifization" (as in Google Chrome, which started the wonderful trend of minimal interfaces and the hiding of visual clutter) of Ubuntu is the main reason I am looking forward to Natty. So while I understand the concerns about the hidden menu, I agree with the logic of not treating the menu as an indicator, and hiding it up in the panel. Yes, there are a couple of small problems with this approach (mostly discoverability for new users, people using Natty for the very first time), but my opinion is the benefits outweigh the disadvantages. My vote, for what it's worth, is to keep it the way it is!That said, I would not oppose having the menu in the panel being shown by default, instead of the title, in the case of non-maximized windows, with the title/menu overlap occurring only for maximized windows. Marc LajoieOn Wed, Mar 16, 2011 at 8:59 AM, appi2...@gmail.com appi2...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.com wrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible.The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear.#3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too.Although this is a problem, a title is necessary for maximized windows, so it has to be shown for them.I proposed a solution to this earlier on this list, but unfortunately, it got no replies. However, I still believe that it can solve the problems brought up here. My basic idea is: https://lists.launchpad.net/ayatana/msg04555.htmlHowever, I have a change: The Application Title should only be shown for maximized windows, where it is necessary. Otherwise, only the menu should be visible. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___Mailing list: https://launchpad.net/~ayatanaPost to : ayatana@lists.launchpad.netUnsubscribe : https://launchpad.net/~ayatanaMore help : https://help.launchpad.net/ListHelp___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
You can drop the ad hominem attacks. The everyone's-stupid-but-me attitude is not very productive. Advantages to current setup: Increases free vertical space; removes visual clutter; creates a disincentive to use the menu as an indicator conveying useful information for which it's not suited (more standardized and consistent menu headings across different applications is definitely something to be encouraged, taking the guesswork out of menu hunting). Disadvantages: Menu is disconnected from unmaximized windows, potentially causing confusion; Menu is not discoverable for first-time user (new user won't know where the menu is unless he/she accidentally hovers over the panel) To say there are no advantages is disingenuous. You believe the disadvantages outweigh the advantages. Fine, good. I believe the reverse. You are entitled to your opinion. So am I. The community will decide. Peace, man. Marc Lajoie On Wed, Mar 16, 2011 at 4:48 PM, Mitja Pagon mitja.pa...@inueni.com wrote: And what may those advantages be? Not every application is a web browser and not all applications are the same, so this trend Chrome supposedly started does not automatically apply to all and every application. Also this quest for abolishing menus is complete nonsense propagated by people who mostly know nothing about user interface design / interaction design, user experience design , and this place (ayatana list) is, despite an occasional good idea, littered with people like that. Sometimes it makes me feel like most people use Ubuntu to just to surf pr0n. Different people have stated multiple issues with this hidden menus integrated title/controls and many more issues arise when trying to tackle those issues while the benefits are almost non existent, and that is a dictionary example of bad design. Cheers, Mitja Mitja Pagon Inueni d.o.o., Pot pod Gradiščem 4, SI 4202 Naklo Tel.: +386 41 521 729 e-naslov: mitja.pa...@inueni.com, url: www.inueni.com - Original Message - From: Marc Lajoie manorap...@gmail.com To: appi2...@gmail.com Cc: Ayatana@lists.launchpad.net Sent: Wednesday, March 16, 2011 3:20:51 AM Subject: Re: [Ayatana] Design problem: Menus hidden by default in Unity I, for one, love the integration of the menu and titlebars into the panel in Natty. The decluttering of the workspace, or the chromifization (as in Google Chrome, which started the wonderful trend of minimal interfaces and the hiding of visual clutter) of Ubuntu is the main reason I am looking forward to Natty. So while I understand the concerns about the hidden menu, I agree with the logic of not treating the menu as an indicator, and hiding it up in the panel. Yes, there are a couple of small problems with this approach (mostly discoverability for new users, people using Natty for the very first time), but my opinion is the benefits outweigh the disadvantages. My vote, for what it's worth, is to keep it the way it is! That said, I would not oppose having the menu in the panel being shown by default, instead of the title, in the case of non-maximized windows, with the title/menu overlap occurring only for maximized windows. Marc Lajoie On Wed, Mar 16, 2011 at 8:59 AM, appi2...@gmail.com appi2...@gmail.comwrote: On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.comwrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible. The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear. #3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. Although this is a problem, a title is necessary for maximized windows, so it has to be shown for them. I proposed a solution to this earlier on this list, but unfortunately, it got no replies. However, I still believe that it can solve the problems brought up here. My basic idea is: https://lists.launchpad.net/ayatana/msg04555.html However, I have a change: The Application Title should only be shown for maximized windows, where it is necessary. Otherwise, only the menu should be visible. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Peace indeed. I'm not implying that you or anyone else is stupid, I'm stating, and as irritating as it might be to you, the fact, that most people on here (most, not all) don't understand what interaction design is about (and that implies lack of understading, not supidity), and you just proved my point, interaction design is not about personal opinions, it's a science backed by facts. Issues raised are backed by actual science your advantages are mostly a personal opinion (you are more that welcome to prove otherwise with actual facts). And this is an issues that can hardly be resolved by a community, just like nuclear plant can't be built by bakers, they simply lack the knowledge. Cheers, Mitja - Original Message - From: Marc Lajoie manorap...@gmail.com To: Mitja Pagon mitja.pa...@inueni.com Cc: Ayatana@lists.launchpad.net, appi2...@gmail.com Sent: Wednesday, March 16, 2011 10:23:48 AM Subject: Re: [Ayatana] Design problem: Menus hidden by default in Unity You can drop the ad hominem attacks. The everyone's-stupid-but-me attitude is not very productive. Advantages to current setup: Increases free vertical space; removes visual clutter; creates a disincentive to use the menu as an indicator conveying useful information for which it's not suited (more standardized and consistent menu headings across different applications is definitely something to be encouraged, taking the guesswork out of menu hunting). Disadvantages: Menu is disconnected from unmaximized windows, potentially causing confusion; Menu is not discoverable for first-time user (new user won't know where the menu is unless he/she accidentally hovers over the panel) To say there are no advantages is disingenuous. You believe the disadvantages outweigh the advantages. Fine, good. I believe the reverse. You are entitled to your opinion. So am I. The community will decide. Peace, man. Marc Lajoie On Wed, Mar 16, 2011 at 4:48 PM, Mitja Pagon mitja.pa...@inueni.com wrote: And what may those advantages be? Not every application is a web browser and not all applications are the same, so this trend Chrome supposedly started does not automatically apply to all and every application. Also this quest for abolishing menus is complete nonsense propagated by people who mostly know nothing about user interface design / interaction design, user experience design , and this place (ayatana list) is, despite an occasional good idea, littered with people like that. Sometimes it makes me feel like most people use Ubuntu to just to surf pr0n. Different people have stated multiple issues with this hidden menus integrated title/controls and many more issues arise when trying to tackle those issues while the benefits are almost non existent, and that is a dictionary example of bad design. Cheers, Mitja Mitja Pagon Inueni d.o.o., Pot pod Gradiščem 4, SI 4202 Naklo Tel.: +386 41 521 729 e-naslov: mitja.pa...@inueni.com , url: www.inueni.com - Original Message - From: Marc Lajoie manorap...@gmail.com To: appi2...@gmail.com Cc: Ayatana@lists.launchpad.net Sent: Wednesday, March 16, 2011 3:20:51 AM Subject: Re: [Ayatana] Design problem: Menus hidden by default in Unity I, for one, love the integration of the menu and titlebars into the panel in Natty. The decluttering of the workspace, or the chromifization (as in Google Chrome, which started the wonderful trend of minimal interfaces and the hiding of visual clutter) of Ubuntu is the main reason I am looking forward to Natty. So while I understand the concerns about the hidden menu, I agree with the logic of not treating the menu as an indicator, and hiding it up in the panel. Yes, there are a couple of small problems with this approach (mostly discoverability for new users, people using Natty for the very first time), but my opinion is the benefits outweigh the disadvantages. My vote, for what it's worth, is to keep it the way it is! That said, I would not oppose having the menu in the panel being shown by default, instead of the title, in the case of non-maximized windows, with the title/menu overlap occurring only for maximized windows. Marc Lajoie On Wed, Mar 16, 2011 at 8:59 AM, appi2...@gmail.com appi2...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.com wrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible. The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear. #3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Tue, 2011-03-15 at 21:17 -0300, Conscious User wrote: Remco wrote: The thing I find jarring is that we have this mysterious design team that basically discusses things behind our backs here at Ayatana. I understand that a small team with face-to-face meetings can be beneficial to design, but a problem lies in communication and collaboration between the team and Ayatana. Yeah, the current situation is... weird, to say the least. I've always heard rumors that the design team worked far from the rest, but at the same time always felt comforted by the fact that at least *someone* from the team (Matthew and, before, David Siegel) was active here. Apparently, that doesn't mean much. Is it a coincidence that the two of them worked in Open source projects _before_ joining Canonical design team..? ;-) This topic has been hashed, re-hashed over-n-over again several times.. I, for one, definitely see a huge improvement in communication from the design team. Several members have replied here to questions that are being asked. And IMO, recently, this has ceased to be a problem.. We have to realize that this mailing list is *very* high volume and you really can not expect everyone in the design team to read each-n-every mail and reply to every idea that is being thrown out at them.. I'm always amazed how Mark is able to keep up though, and at MPT too but to a lesser extent.. ;-) And this mailing list is *not* a place for them to propose their ideas. They have blogged about most of their new ideas on their blog. This is just a communication channel where we can propose ideas for their consideration. I think its high time we dropped the design-team-bashing for not communicating each and every time a change is made.. ;-) -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Wed, 16 Mar 2011, Matthew Paul Thomas wrote:
Do you know of any Ubuntu application that was trying to use its menu
titles as an indicator in the first place?
The Gimp and various other MDI applications prepend an asterisk ('*')
to the front of the window title to show an edited, but unsaved work.
Whilst I am aware of the convention, I don't notice it and there are
probably better ways of conveying if your machine naughtily crashes
right now $some unspecified amount of work will be lost.
-Paul
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Not off the top of my head (which is not an admission that such applications don't exist, I just don't have time to hunt through my app catalogue right now). But one of the solutions proposed for the hidden menu problem, that of not showing the title at all for maximized windows, would probably lead to exactly the problem I'd like to avoid. I suspect this would lead some applications to try to identify themselves in the menu, say, by replacing the standardly named file menu with the name of the application (as in OS X), in order to avoid confusion. This would be an example of using the menu as an indicator. Marc Lajoie On Wed, Mar 16, 2011 at 6:58 PM, Matthew Paul Thomas m...@canonical.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Lajoie wrote on 16/03/11 09:23: ... Advantages to current setup: Increases free vertical space; removes visual clutter; creates a disincentive to use the menu as an indicator conveying useful information for which it's not suited (more standardized and consistent menu headings across different applications is definitely something to be encouraged, taking the guesswork out of menu hunting). Do you know of any Ubuntu application that was trying to use its menu titles as an indicator in the first place? - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Al7wACgkQ6PUxNfU6ecrWXQCgkcyqKfcrEgbL/gyG+3NUQz6B B7YAnj90VdbFxffLtL6PLPUhtXT6iiSm =C+vE -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Is it a coincidence that the two of them worked in Open source projects _before_ joining Canonical design team..? ;-) This topic has been hashed, re-hashed over-n-over again several times.. I, for one, definitely see a huge improvement in communication from the design team. Several members have replied here to questions that are being asked. And IMO, recently, this has ceased to be a problem.. We have to realize that this mailing list is *very* high volume and you really can not expect everyone in the design team to read each-n-every mail and reply to every idea that is being thrown out at them.. I'm always amazed how Mark is able to keep up though, and at MPT too but to a lesser extent.. ;-) And this mailing list is *not* a place for them to propose their ideas. They have blogged about most of their new ideas on their blog. This is just a communication channel where we can propose ideas for their consideration. I think its high time we dropped the design-team-bashing for not communicating each and every time a change is made.. ;-) You completely missed my point. Yes, I'm talking about the lack of communication between the design team and the community, but this time as a mere *consequence* of issue actually being discussed: that the communication is broken *internally* on the design team. As far as I know, design team members not being aware of other design team members are doing is *not* a topic hashed, re-hashed over-n-over again several times. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Wednesday, March 16, 2011 11:00:35 AM Matthew Paul Thomas wrote: (It would be interesting to replace maximization with a standard function that really *does* make all the available screen space ... dedicated to this window.) This is one of the most hated features in osx, imo. It takes control away from the user, and heads to very inconsistent results across different applications. Mac OS X has that in the Help menu for every application. http://www.youtube.com/watch?v=sOoOvIqiWe0#t=22s But searching works only if you are already confident that the application does the exact thing you're looking for. If you aren't, you still need to be able to browse the functions of the application. Menus are an information-dense way of presenting those functions. True. I believe in this proof of concept: http://www.afiestas.org/improving- kde-applications-help-menu-actions-lookup/ ; the dev mitigated this a bit by also letting the search go through the tooltips of the menu options. The difficulty there is that the menu bar would be flickering from the menus to the title at a moment when you're probably trying to concentrate on something else. cant we add an animation to purposefully slow down the flicker to something understandable? I mean when the launcher is hidden there is a visual cue to where it has gone, why not the same for a menu about to be hidden? --Saleel ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Wed, 2011-03-16 at 08:37 -0300, Conscious User wrote: You completely missed my point. Yes, I'm talking about the lack of communication between the design team and the community, yup, I replied to only that part of your mail.. and referred only to that part as being re-hashed.. :-) but this time as a mere *consequence* of issue actually being discussed: that the communication is broken *internally* on the design team. As for the second part I agree, and I addressed that in my reply towards Matthew. I still believe JohnLea might have not realized it was MPT who filed the bug. Which was why I asked if MPT confirmed, before making this an open discussion. Else, we are in a huge mess, if they are lacking communication too.. :s -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sladen wrote on 16/03/11 11:29:
On Wed, 16 Mar 2011, Matthew Paul Thomas wrote:
Do you know of any Ubuntu application that was trying to use its menu
titles as an indicator in the first place?
The Gimp and various other MDI applications prepend an asterisk ('*')
to the front of the window title to show an edited, but unsaved work.
...
They don't change their menu titles, though.
- --
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2ArrwACgkQ6PUxNfU6ecoyjACg1BvbrgadNV5OAjXGfalXBjUv
spoAoKuwj0osY0lqARp/jqdxvq/qET5d
=gG/s
-END PGP SIGNATURE-
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Wednesday, March 16, 2011 08:35:32 am Vishnoo wrote: On Wed, 2011-03-16 at 08:37 -0300, Conscious User wrote: You completely missed my point. Yes, I'm talking about the lack of communication between the design team and the community, yup, I replied to only that part of your mail.. and referred only to that part as being re-hashed.. :-) but this time as a mere *consequence* of issue actually being discussed: that the communication is broken *internally* on the design team. As for the second part I agree, and I addressed that in my reply towards Matthew. I still believe JohnLea might have not realized it was MPT who filed the bug. Which was why I asked if MPT confirmed, before making this an open discussion. Else, we are in a huge mess, if they are lacking communication too.. :s A bug is a bug no matter who files it. If we're down to it's only a real bug if certain people file the bug, then that's a real problem. Scott K ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Wednesday, March 16, 2011 09:42:17 am Vishnoo wrote: On Wed, 2011-03-16 at 08:42 -0400, Scott Kitterman wrote: Else, we are in a huge mess, if they are lacking communication too.. :s A bug is a bug no matter who files it. If we're down to it's only a real bug if certain people file the bug, then that's a real problem. Scott K I completely agree on that.. ;-) I dint want to keep repeating what i said, hence kept it short: https://lists.launchpad.net/ayatana/msg05070.html Btw, it is totally awesome that you agree with this view now.. :) than from a while ago(no flames intended): https://lists.launchpad.net/ayatana/msg00614.html That conversation was about priority, not validity. It was also about getting your ideas accepted in other projects. I think it's a different question. A bug is a bug independent of who filed it. You may look at one bug first and consider the input differently based on the expertise of the filer, but that doesn't make it more or less a bug. Scott K [resending to the list, vish: sorry you got two] ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On 16.03.2011 10:23, Marc Lajoie wrote: Advantages to current setup: Increases free vertical space; removes visual clutter; creates a disincentive to use the menu as an indicator conveying useful information for which it's not suited (more standardized and consistent menu headings across different applications is definitely something to be encouraged, taking the guesswork out of menu hunting). Disadvantages: Menu is disconnected from unmaximized windows, potentially causing confusion; Menu is not discoverable for first-time user (new user won't know where the menu is unless he/she accidentally hovers over the panel) adding one more disadvantage: before, you could directly switch from one window to another windows menu by just one click, now you can't. a solution I would like to see: switching title/menu on mouse hover also for non-maximized windows. that would keep all advantages and avoid the disadvantages. plus we could have a configurable top panel again (...which is hidden when maximized windows appear) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On 16.03.2011 18:08, David wrote: Hi, i just want to add my 2cts (but its to late for natty so you need to continue anyway ;-)) i think we should really let the user choose and just discussing about the best default. See settings.png Yes, I totally agree on that! ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Wed, Mar 16, 2011 at 6:58 AM, Matthew Paul Thomas m...@canonical.comwrote: Do you know of any Ubuntu application that was trying to use its menu titles as an indicator in the first place? - -- mpt Firefox, private browsing mode. the tilebar is how private mode status is conveyed to user. -- Saleel ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I have a simple proposal to fix these problems: The application title should be removed from Unity's menu bar. I'm reliably informed that this would be extremely low risk, in that it would involve changing two lines of code. But how would be the design for maximized windows? I'm guessing the fixed-size title in the menubar is there to occupy the same space the buttons do when maximized, so the menubar doesn't move when the window is maximized. Plus, for maximized windows there is also the problem of how the (potentially long) title and the menubar could share the panel without the show-on-hover. On a side note, I'm kinda baffled at how fragmented the design process seems to be judging by this email... I thought mpt was aware of this for a long time. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I can verify that hiding the menus by default is problematic in my (limited) user testing. On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After several weeks of trying, last week I finally succeeded in installing Natty to test Unity. I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. I reported a bug about this, but John Lea marked it as Invalid on the grounds that this change request contradicts the design. He requested that I discuss it here. The design John cited is not the menu bar specification https://wiki.ubuntu.com/MenuBar, but a separate The Unity Menu document that is new to me. https://docs.google.com/View?id=dfkkjjcj_1776g5ztgbc3 I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. The The Unity Menu document says that The top level of the menu rarely shows significant information (it is not an indicator) - it consists essentially of category headings, like 'File' and 'Edit' and 'View'. None of those add any relevant information to the task at hand, or wider awareness. Whoever wrote that is mistaken. Every time the task at hand involves using a menu, it is necessary first to be aware of, and then to move the pointer to, the desired menu. That is much harder to do if the menu is invisible until just after you finish needing to know where it is. Whether the menus collectively are an indicator is irrelevant: the first item in the rationale, for what determines whether something appears in the menu bar, has always been It's not whether it's a status indicator. https://wiki.ubuntu.com/MenuBar?action=AttachFiledo=viewtarget=whether-something-appears.jpg 2. It makes some functions effectively invisible. For example, last month Jack Wallen wrote for TechRepublic http://www.techrepublic.com/blog/opensource/x/2291: One of the most handy menu entries in GNOME (for me at least) is the Connect to Server entry in the Places menu. This allows the user to connect to nearly any type of server quickly and easily. The user can even connect to a Windows Share from here. In Unity - you won’t find that. In fact, you will be hard pressed to find any means to connect to a server in Ubuntu Unity. At the time, I didn't understand how he could have had that problem. Now I do. The Connect to Server item, which is in the Places menu on the Ubuntu 10.10 desktop, is in the File menu on the Natty desktop. But the desktop appears, incorrectly, to have no menus at all. The The Unity Menu document says Many modern applications are being designed without substantial menus. The problem with that approach was explained in my initial post introducing the menu bar: it results in gratuitous inconsistency between applications. http://design.canonical.com/2010/05/menu-bar/#history But that is beside the point. Hiding menus for windows that *do* rely on them does nobody any good. 3. The application or window title becomes ugly when the menus appear. For example, when using Nautilus's menus, the menu bar reads File Man File Edit View Go Bookmarks Help. Similarly when using Terminal's menus, the menu bar reads Termina File Edit View Search Terminal Help. And when using Calculator's menus, the menu bar gets a stutter: Calculat Calculator Mode Help. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. For example, when that Calculator window is open, its title bar says Calculator, and the menu bar pointlessly repeats Calculator. When a Banshee window is open, its title bar says Banshee Media Player, and the menu bar repeats Banshee Media Player. When a PolicyKit authentication alert is open, its title bar says Authenticate, and the menu bar repeats Authenticate. Other windows are inconsistent. For example, Firefox's title bar says Mozilla Firefox, but the menu bar disagrees, saying Firefox Web Browser. Shotwell's title bar says Shotwell, but the menu bar says Shotwell Photo Manager. Most amusingly, if you open a presentation in LibreOffice and then open an accompanying spreadsheet, the title bar says LibreOffice Calc while the menu bar says LibreOffice Impress. There are two paragraphs in the The Unity Menu document that I agree with. One says: The top edge of the screen has some advantages for fine mouse pointer targeting. But that is true only when you know where the
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On 03/15/2011 06:34 PM, Matthew Paul Thomas wrote: I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. The design John cited is not the menu bar specification https://wiki.ubuntu.com/MenuBar, but a separate The Unity Menu document that is new to me. https://docs.google.com/View?id=dfkkjjcj_1776g5ztgbc3 And here I thought you 2 would be on the same team. That switching behavior only makes sense to me in the maximised window case. I guess it's then shoehorned unto the non-max window case for consistency. Consistency is great, but sometimes there maybe a benefit in breaking it. Though it might be a design smell, if your underlying concept drives you into such cases. If menus are disliked that much, I wonder where the alternatives are? Piling everything up in one mega-menu is only acceptable for seldom used functionality. Many applications have way to many commands to put them into a toolbar or to sprinkle the interface with them. Even in an application like Rhinocerus (rhino3d), where all commands are available in commandline at the bottom of the window, the menus help by letting you explore what's there and in case where you don't remember enough of a command name even for autocomplete. Though in Emacs, I have been doing fine with no menu at all. Anyway, if menus are bad, menus where you can't aim for their top level items directly are even worse. I have a simple proposal to fix these problems: The application title should be removed from Unity's menu bar. I'm reliably informed that this would be extremely low risk, in that it would involve changing two lines of code. The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Tue, 2011-03-15 at 17:34 +, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After several weeks of trying, last week I finally succeeded in installing Natty to test Unity. I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. I reported a bug about this, but John Lea marked it as Invalid on the grounds that this change request contradicts the design. He requested that I discuss it here. The design John cited is not the menu bar specification https://wiki.ubuntu.com/MenuBar, but a separate The Unity Menu document that is new to me. https://docs.google.com/View?id=dfkkjjcj_1776g5ztgbc3 I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. The The Unity Menu document says that The top level of the menu rarely shows significant information (it is not an indicator) - it consists essentially of category headings, like 'File' and 'Edit' and 'View'. None of those add any relevant information to the task at hand, or wider awareness. Whoever wrote that is mistaken. Every time the task at hand involves using a menu, it is necessary first to be aware of, and then to move the pointer to, the desired menu. That is much harder to do if the menu is invisible until just after you finish needing to know where it is. Whether the menus collectively are an indicator is irrelevant: the first item in the rationale, for what determines whether something appears in the menu bar, has always been It's not whether it's a status indicator. https://wiki.ubuntu.com/MenuBar?action=AttachFiledo=viewtarget=whether-something-appears.jpg 2. It makes some functions effectively invisible. For example, last month Jack Wallen wrote for TechRepublic http://www.techrepublic.com/blog/opensource/x/2291: One of the most handy menu entries in GNOME (for me at least) is the Connect to Server entry in the Places menu. This allows the user to connect to nearly any type of server quickly and easily. The user can even connect to a Windows Share from here. In Unity - you won’t find that. In fact, you will be hard pressed to find any means to connect to a server in Ubuntu Unity. At the time, I didn't understand how he could have had that problem. Now I do. The Connect to Server item, which is in the Places menu on the Ubuntu 10.10 desktop, is in the File menu on the Natty desktop. But the desktop appears, incorrectly, to have no menus at all. The The Unity Menu document says Many modern applications are being designed without substantial menus. The problem with that approach was explained in my initial post introducing the menu bar: it results in gratuitous inconsistency between applications. http://design.canonical.com/2010/05/menu-bar/#history But that is beside the point. Hiding menus for windows that *do* rely on them does nobody any good. 3. The application or window title becomes ugly when the menus appear. For example, when using Nautilus's menus, the menu bar reads File Man File Edit View Go Bookmarks Help. Similarly when using Terminal's menus, the menu bar reads Termina File Edit View Search Terminal Help. And when using Calculator's menus, the menu bar gets a stutter: Calculat Calculator Mode Help. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. For example, when that Calculator window is open, its title bar says Calculator, and the menu bar pointlessly repeats Calculator. When a Banshee window is open, its title bar says Banshee Media Player, and the menu bar repeats Banshee Media Player. When a PolicyKit authentication alert is open, its title bar says Authenticate, and the menu bar repeats Authenticate. Other windows are inconsistent. For example, Firefox's title bar says Mozilla Firefox, but the menu bar disagrees, saying Firefox Web Browser. Shotwell's title bar says Shotwell, but the menu bar says Shotwell Photo Manager. Most amusingly, if you open a presentation in LibreOffice and then open an accompanying spreadsheet, the title bar says LibreOffice Calc while the menu bar says LibreOffice Impress. There are two paragraphs in the The Unity Menu document that I agree with. One says: The top edge of the screen has some advantages for fine mouse pointer targeting. But that is true only when you know where the target area is before you begin. The other
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Thorsten Wilms wrote: The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. And where would the window buttons go? If this discussion ends up concluding that they are better on the right, the universe will probably explode with irony. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
The change that you propose might make it harder to see which application a particular menu belongs to. I think it's that (and the desire to hide a bit of messy interface) that led to the current situation, although I've no citation on it. I think in having it always-menu, care would need to be taken to make sure that it's obvious which window is focussed. I know a lot of fuss has been made about shadows to highlight the focussed window, but that's a pretty weak visual cue which is vulnerable to being obscured. Apple have that problem largely solved with the Application Menu or whatever it's called (the one that uses the application's name, in which they shove everything they can't think of a good place for. :/ ) Of course, the fact that they have had that consistently for some time indeed has meant that people have deliberately not made their applications have the same name as their first menu item. Ubuntu couldn't do the same, especially since most of the applications on a default Ubuntu install weren't even designed for Ubuntu's interface, but indeed for Gnome's (there's another lovely problem with the whole state of affairs as we have it.) In summary: Showing only menus, how are you going to make sure people know what the menus being shown are for? 2011/3/15 Conscious User consciousu...@aol.com Thorsten Wilms wrote: The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. And where would the window buttons go? If this discussion ends up concluding that they are better on the right, the universe will probably explode with irony. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Tuesday, March 15, 2011 5:34:52 PM Matthew Paul Thomas wrote: I have a simple proposal to fix these problems: The application title should be removed from Unity's menu bar. Possibly. The titlebar is used to differentiate between two windows of the same app, or less used to differentiate between windows of different apps. By clicking the maximize button, the user is saying that I want all the available screen space to be dedicated to this window (note: its not this app) please see my tweak to thorwils idea. On Tuesday, March 15, 2011 7:28:59 PM Thorsten Wilms wrote: If menus are disliked that much, I wonder where the alternatives are? Piling everything up in one mega-menu is only acceptable for seldom used functionality. Many applications have way to many commands to put them into a toolbar or to sprinkle the interface with them. In the perfect world, there would be button in the toolbar. when you click it will pop-up a box saying what are you looking to do? and search/display through the menu options based on what the user has typed ala GnomeDo/ Krunner. Though in Emacs, I have been doing fine with no menu at all. jokeEmacs is perfect for people with 32 fingers that love to memorize obscure codes /joke Anyway, if menus are bad, menus where you can't aim for their top level items directly are even worse. Super Agreed. The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. Here is an idea, make it time based. it being 'giving the preference to'. If I am watching a youtube video inside a maximized Firefox windows, and my mouse activity is low, then the title should be given the preference. If my mouse/keyboard activity picks up then the menu should be given the preference. I assume this is technically feasible. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Tue, 2011-03-15 at 15:51 -0300, Conscious User wrote: Thorsten Wilms wrote: The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. And where would the window buttons go? If this discussion ends up concluding that they are better on the right, the universe will probably explode with irony. I dont think we should decide _not_ to do the right thing just for the sake of irony.. ;-) Sane design trumps irony any day.. ;p -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On 15 March 2011 20:13, Vishnoo v...@ubuntu.com wrote: On Tue, 2011-03-15 at 15:51 -0300, Conscious User wrote: Thorsten Wilms wrote: The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. And where would the window buttons go? If this discussion ends up concluding that they are better on the right, the universe will probably explode with irony. I dont think we should decide _not_ to do the right thing just for the sake of irony.. ;-) Sane design trumps irony any day.. ;p -- Cheers, Vish Erm, I hate to point out the obvious, but why don't we just put the menu back in the windows and abandon appmenu as a failed experiment? Keep the title and window controls in the panel for maximized windows only (at least just for Natty). I can already imagine the replies to this email, so let me save you guys the trouble: 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I don't think it should be used as an overriding reason to squash, overlap, and generally complicate a UI and shove it into an edge. I especially don't see why Fitt's law is so important for menu bars, when users get on perfectly fine with buttons, sliders, window resize grips and icons, and well, everything else. 2. Someone will likely bring up the space saving of the global menu. Firstly, the global menu only saves vertical space on a maximized window, on non-maximized windows they only save on chrome. By keeping the title in the panel for maximized windows, we are still saving 22px on Gnome 2, with the removal of the bottom panel that brings it up to 44px. It's about finding a balance of space saving vs usability and I really think we have shot past that balance point with the global menu. So, the question again raised is why exactly are we using a global menu? I know I've brought it up before, but alongside the issues we are having fitting it into the panel with the title, it also brings issues with dual monitors, large resolutions and focus-follows-mouse. It doesn't fit all use cases. I think we should revert the global menu for Natty, and spend the next 6 months innovating on the menu bar, finding a replacement that doesn't have the chrome but is easy to use. Firefox and Chrome have come up with their replacements and Elementary are removing it altogether in their apps. Now we have a dbus API for exporting the menus maybe there is another, better, more compact, way to display them to the user? The only other suggestion I can come up with is to make the title a button that displays the menu bar as drop down menu (Firefox style). Luke. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I've raised this issue before in various places, but I never got any response, so I'm really, positively surprised to see the same issues raised by someone from Canonical. Why not just keep the window title on the window, it's not really wasting that much screen space. This space efficiency as a design goal is being taken to far. Integrating window controls and title into the panel gains a bit of space, but is introduces some issues, most of which you listed. Keeping the application name in the global menu is important, as it a visual clue as to which application's menus are displayed. The inconsistencies in application naming can be filed as bugs and fixed, as names are read from desktop files. If an application has no menu, no name would need to be displayed. As for naming of entries in application menus, that sadly can't be easily resolved, as it's mostly up to application developers to sort out. Cheers, Mitja - Original Message - From: Matthew Paul Thomas m...@canonical.com To: Ayatana@lists.launchpad.net Sent: Tuesday, March 15, 2011 6:34:52 PM Subject: [Ayatana] Design problem: Menus hidden by default in Unity -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After several weeks of trying, last week I finally succeeded in installing Natty to test Unity. I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. I reported a bug about this, but John Lea marked it as Invalid on the grounds that this change request contradicts the design. He requested that I discuss it here. The design John cited is not the menu bar specification https://wiki.ubuntu.com/MenuBar, but a separate The Unity Menu document that is new to me. https://docs.google.com/View?id=dfkkjjcj_1776g5ztgbc3 I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. The The Unity Menu document says that The top level of the menu rarely shows significant information (it is not an indicator) - it consists essentially of category headings, like 'File' and 'Edit' and 'View'. None of those add any relevant information to the task at hand, or wider awareness. Whoever wrote that is mistaken. Every time the task at hand involves using a menu, it is necessary first to be aware of, and then to move the pointer to, the desired menu. That is much harder to do if the menu is invisible until just after you finish needing to know where it is. Whether the menus collectively are an indicator is irrelevant: the first item in the rationale, for what determines whether something appears in the menu bar, has always been It's not whether it's a status indicator. https://wiki.ubuntu.com/MenuBar?action=AttachFiledo=viewtarget=whether-something-appears.jpg 2. It makes some functions effectively invisible. For example, last month Jack Wallen wrote for TechRepublic http://www.techrepublic.com/blog/opensource/x/2291: One of the most handy menu entries in GNOME (for me at least) is the Connect to Server entry in the Places menu. This allows the user to connect to nearly any type of server quickly and easily. The user can even connect to a Windows Share from here. In Unity - you won’t find that. In fact, you will be hard pressed to find any means to connect to a server in Ubuntu Unity. At the time, I didn't understand how he could have had that problem. Now I do. The Connect to Server item, which is in the Places menu on the Ubuntu 10.10 desktop, is in the File menu on the Natty desktop. But the desktop appears, incorrectly, to have no menus at all. The The Unity Menu document says Many modern applications are being designed without substantial menus. The problem with that approach was explained in my initial post introducing the menu bar: it results in gratuitous inconsistency between applications. http://design.canonical.com/2010/05/menu-bar/#history But that is beside the point. Hiding menus for windows that *do* rely on them does nobody any good. 3. The application or window title becomes ugly when the menus appear. For example, when using Nautilus's menus, the menu bar reads File Man File Edit View Go Bookmarks Help. Similarly when using Terminal's menus, the menu bar reads Termina File Edit View Search Terminal Help. And when using Calculator's menus, the menu bar gets a stutter: Calculat Calculator Mode Help. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. For example, when that Calculator window is open, its title bar says Calculator, and the menu bar pointlessly repeats Calculator. When a Banshee window is open, its title bar says
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Tue, Mar 15, 2011 at 23:29, Mitja Pagon mitja.pa...@inueni.com wrote: I've raised this issue before in various places, but I never got any response, so I'm really, positively surprised to see the same issues raised by someone from Canonical. I also raised this issue in a bug report[1], and was informed that it would be discussed by 'design'. The bug was later closed, with the elaboration that we're now committed to this course for Natty. The thing I find jarring is that we have this mysterious design team that basically discusses things behind our backs here at Ayatana. I understand that a small team with face-to-face meetings can be beneficial to design, but a problem lies in communication and collaboration between the team and Ayatana. I have no idea how this secret discussion lead to the closure of my bug. -- Remco [1] https://bugs.launchpad.net/unity/+bug/717450 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
After several weeks of trying, last week I finally succeeded in installing Natty to test Unity. I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. I reported a bug about this, but John Lea marked it as Invalid on the grounds that this change request contradicts the design. He requested that I discuss it here. […] I have a simple proposal to fix these problems: The application title should be removed from Unity's menu bar. I'm reliably informed that this would be extremely low risk, in that it would involve changing two lines of code. - -- mpt Today I have been working on my fix for bug #716177: https://bugs.launchpad.net/unity/+bug/716177 Right now, the panel acts like the titlebar for the current maximized window, but only if it's in focus. That leaves a big hole where a maximized window is visible and it isn't in focus, but the top panel still looks like it should correspond to that window. (The tldr version: try using GIMP, maximized, without frowning). My patch makes the top panel's draggable area relate to the front-most maximized window regardless of who is in focus. Anyway, I bumped into a design question that relates to this! The draggable titlebar proxy works, and I had the code lined up to fix the button proxy, but fixing that would totally break the application title for an unmaximized window. So, the inconsistency mpt describes hits us in another place: when somebody maximizes a window, its title bar disappears and is replaced by a pretend title bar that doesn't look or feel like an ordinary title bar. We do fairly well making it work, and my patch brings that a little closer, _except for the buttons_ :) Dylan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Remco wrote: The thing I find jarring is that we have this mysterious design team that basically discusses things behind our backs here at Ayatana. I understand that a small team with face-to-face meetings can be beneficial to design, but a problem lies in communication and collaboration between the team and Ayatana. Yeah, the current situation is... weird, to say the least. I've always heard rumors that the design team worked far from the rest, but at the same time always felt comforted by the fact that at least *someone* from the team (Matthew and, before, David Siegel) was active here. Apparently, that doesn't mean much. I know that different people in the design team probably work in different things, and I know that it's not the first time Ubuntu has a design change not approved by all members of the team (ex: IIRC, Matthew didn't agree with music icons in the Sound Menu instead of specific app icons), but to see such a miscommunication in such a prominent part of Unity is a little bit... shocking. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.comwrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible. The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear. #3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. Although this is a problem, a title is necessary for maximized windows, so it has to be shown for them. I proposed a solution to this earlier on this list, but unfortunately, it got no replies. However, I still believe that it can solve the problems brought up here. My basic idea is: https://lists.launchpad.net/ayatana/msg04555.html However, I have a change: The Application Title should only be shown for maximized windows, where it is necessary. Otherwise, only the menu should be visible. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I, for one, love the integration of the menu and titlebars into the panel in Natty. The decluttering of the workspace, or the chromifization (as in Google Chrome, which started the wonderful trend of minimal interfaces and the hiding of visual clutter) of Ubuntu is the main reason I am looking forward to Natty. So while I understand the concerns about the hidden menu, I agree with the logic of not treating the menu as an indicator, and hiding it up in the panel. Yes, there are a couple of small problems with this approach (mostly discoverability for new users, people using Natty for the very first time), but my opinion is the benefits outweigh the disadvantages. My vote, for what it's worth, is to keep it the way it is! That said, I would not oppose having the menu in the panel being shown by default, instead of the title, in the case of non-maximized windows, with the title/menu overlap occurring only for maximized windows. Marc Lajoie On Wed, Mar 16, 2011 at 8:59 AM, appi2...@gmail.com appi2...@gmail.comwrote: On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.comwrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible. The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear. #3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. Although this is a problem, a title is necessary for maximized windows, so it has to be shown for them. I proposed a solution to this earlier on this list, but unfortunately, it got no replies. However, I still believe that it can solve the problems brought up here. My basic idea is: https://lists.launchpad.net/ayatana/msg04555.html However, I have a change: The Application Title should only be shown for maximized windows, where it is necessary. Otherwise, only the menu should be visible. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
