https://bugzilla.novell.com/show_bug.cgi?id=274817 Summary: revamping the GNOME main menu layout to something simpler Product: openSUSE 10.3 Version: Alpha 4 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Usability AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: christian.jaeger@rub.de QAContact: qa@suse.de When we look at the layout of the 0.9x-series of the gnome-main-menu, we see a lot of empty space (see attached picture #1); this dead space can be regarded as wasted screen-real-estate. Is it a good idea to go the big-board-way and eventually fill the whole screen? IMHO the right thing to do is not to fill the empty spaces with yet more buttons but to shrink the main-menu. A smaller menu makes for shorter ways for the mouse-cursor and quicker access. This brings me to a second problem - too many buttons. IMHO the menu in its current form already constitutes an information-overload for many users: apart from the actual application-buttons we have no less than 11(!) click-able tiles in the menu; not including the search function. My suggestion is to bring this number down to 6. See attached picture #2. Here is how I arrived at this design in more detail: Thought #1: We don't need _two_ bars attached to the actual menu. Tought #2: We don't need the search-field to extend across the entire length of the menu. Thought #3: So let's put the buttons from the right-side bar into the top bar and get rid of the right-side bar. I would especially like the logout-button to be prominent (because my Dad couldn't locate it in the original menu...). For this we still need to drop some buttons; candidate number one is 'lock screen'. At default settings, Gnome locks the screen automatically after some minute of inactivity; plus a screen-lock could just be added as another option to the 'logout'-menu (http://www.tuxmachines.org/gallery/d/357-2/byebye.jpg). Candidate #2 is the 'install software'-button. Some users install or remove software regularly, a bigger portion of users does so very rarely. My suggestion is to simply put the 'install software' or a 'software management'-button among the other applications because an application it is and next to other applications is where people will look when they look for applications. Finally, the info-tiles. Do we really need to know whether the machine is connected to the Net every time we open the menu? And also, how much space there is on the HD? I think not. Also, this replicates data we should be shown in the gnome-panel (network-manager, D-Bus low-space warning). In the end, if want more in-depth information about what the state of our computers is, we would look for system-information somewhere where we can do other system-maintenance, also, i.e. somewhere in the control center. So, my suggestion is a new tab which merges some system information display with an integrated version of the control center. Let us call it 'System'. But I'm gonna file this suggestions as another bug. Apart from the main tab of the main-menu there is more waste of screen-real-estate. The 'Documents'-tab displays does use an entire tab to display no more than 6 recently-used documents at the defaults. The 'Places'-tab uses this space to display 8 places that we also find in Nautilus' sidebar. And it even looks more messy than Nautilus' places-sidebar. Why do we need a whole tab to do something that fits into a sidebar? This is not efficient IMHO. As 'Documents' and 'Places' share a very similar semantic value (spatial), I think we could easily merge these two tabs and call it 'Documents', 'Files' or whatever. See attached picture #3. I have some more suggestions, namely integrating a rudimentary filebrowser, but I'm going to file another bug for that. This would also give us a beautiful trinity of function in the main menu, now: 'Applications' (=actions), 'Documents' (=data) and 'System' (=settings). Easier software installation is a big point of discussion ATM and I think that the main-menu could be useful in this respect, too. I'm gonna file another bug for that. One more word about the 'search'-function. As many other people I feel it should be intuitive if the search button would display results inside the main menu, as long as the user doesn't hit the return-key. --------- We should also have some guidelines about the design of the menu. I have some suggestions to make: • The mouse should have to move short ways --> no dead space wanted. • The complexity of the layout should be minimal (no extra bars). • The menu should stay small. • The hierarchy of buttons is top-down and left-right • There should be as few clickable objects as possible. • There should be as few screens as possible to navigate before finding a desired function • There is three types of click-able objects in the menu: links(those aren't tiles and don't have symbols), actions and 'super' objects (those aren't tiles, either) • 'Super' objects are those which trigger actions that supersede the usual menu-actions: logout and help • Links represent collections of activities • Clicking on links changes the layout of the main frame, like in an internet-browser-window • Links appear only within the main-window, which they change, in order to make their being connected obvious • Activities are represented by tiles. --> installing software is only an activity, too! • Links should change the main frame • Information should not be clickable! (because it confuses) -->'harddrive' and 'network' are reduced to text-status and aren't tiles, anymore • There should not be more bars than necessary in order not to distract the eye from the main part of the menu. What do you think so far? Is this a meaningful collection of ideas? Thanks for your time; keep up the great work! Chris The initial discussion about this design-proposal started here: http://lists.opensuse.org/archive/opensuse-gnome/2007-05/msg00013.html -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.