← Back to team overview

unity-design team mailing list archive

Re: Killing Menu Bars

 

Ah. Well, you're making me work for things, thats for sure. Ha.



On Mon, May 17, 2010 at 9:37 PM, Luke Morton
<luke.morton@xxxxxxxxxxxxxxxx>wrote:

> On Mon, 2010-05-17 at 20:38 -0700, Tyler Brainerd wrote:
> > Actually, I added a (extremely rough) mock up of what gcalc might look
> > like. Basically, the most commonly used options ought to be
> > (categorically) available the easiest.
>
> I agree, although determining what's most commonly used is easier said
> than done--it depends heavily on the user's habits and their particular
> needs.
>

Agreed. Thats why I started with the calculator here, and with the already
partially simplified Nautilus-Elementary.

>
> > In a tool like a calculator that doesn't have a lot going on as far as
> > options its pretty easy to put these on a row of mode or view buttons.
> > everything else can be found in the 'gearbox' options menu. Roughly
> > like so:Calculator_027.jpg
>
> How would I access that with my keyboard?
>

> > This translates very well in simple apps, and with more work, could
> > work well for more complex apps as well.
> > With the keyboard shortcuts, particularly the insert command,
> > ironically enough I'm using chromium, which does not allow for that
> > command.
>
> The point of accessing the Insert menu (in Evolution) was to illustrate
> the discoverability of a feature without having to know its accelerator
> key ahead of time.
>
> > Presumably we could still allow similar behavior for common key
> > presses of that sort,
>
> I would expect items in the toolbar to have accelerators--especially in
> the absence of a menu. But how would I know what they were? And even if
> they were standardised (say the cog icon is in your example is
> accessible via Alt+S), how would I know what they were?
>

Pressing alt brings up hovering indicators perhaps? I don't disagree that
these things ought to be discoverable, but honestly keyboard accessibility
is nowhere near my strong suit, as I rarely use only the keyboard so I
really don't know how to make it work and what doesn't.


>
> > and honestly some of it will be taken care of by a clean shearing of
> > commands that are used for actual action (i.e., in a file browser
> > relate to actual browsing instead of slightly less needed interface
> > editing like "reset view to defaults" or history clearing) and menu
> > items which do not directly relate to the task at hand.
>
> You lost me here. Are you making a case for well thought-out menus? If
> so then yes, I agree menus should be well thought-out.
>


Um, yes. Well thought. :D. In the sense that chrome has "what I can do to
this page" and "what I can do to the whole browser" as its two menus, then
we would have "whats pertinent to the actions I am currently doing" and
"what customizations to the nature of the program are available"



>
> > Again, Chrome is really a great example of giving context menus which
> > are very dependent on the area clicked, and two very sparse clean
> > menus, with all non-essential interface controls tucked away.
> > Accessible in 3 or less clicks, but away. In addition, this would
> > hopefully lower the levels of total overlap going on.
>
> None of the issues I raised pertain to clicking (using a pointing
> device). But you are right about the Chromium menus being well
> organised. And the use of context menus is good too.
>

Fair enough. :P


>
> However, Chromium also highlights one of the issues I menioned: how do
> you open one of those menus without a mouse? I'll save you some
> frustration for the "Customise and Control Chromium" menu: it's Alt+F. I
> know that from trial and error--guessing key combinations until a menu
> popped up. I'm yet to figure out how to duplicate a tab.


You bring up good points, further illustrating to me that my idea as a whole
is likely suitable as a modification, not as an attempt to alter vanilla
ubuntu.



> > On Mon, May 17, 2010 at 8:15 PM, Luke Morton
> > <luke.morton@xxxxxxxxxxxxxxxx> wrote:
> >
> >         On Mon, 2010-05-17 at 18:47 -0700, Tyler Brainerd wrote:
> >         > I know, I know, we just had an announcement about changing
> >         menu's over
> >         > to global menu's for the UNE. But seriously, how necessary
> >         is 4 menus
> >         > in the calculator application "gcalctool"? The only menu
> >         options that
> >         > have anything to do with actual calculator options are under
> >         the view
> >         > menu. The rest is silly and redundant.
> >         >
> >         >
> >         > I just wrote a fairly long blog post on my blog here, along
> >         with
> >         > mockups and what not:
> >         >
> >
> http://tjamesubuntu.blogspot.com/2010/05/re-thinking-desktop.html
> >         >
> >         >
> >         > about how silly most apps menu's are. I'm hoping that we can
> >         maybe
> >         > pool some resources on looking at what is and what isn't
> >         necessary in
> >         > default applications in Ubuntu, although I'm not under any
> >         impression
> >         > that this will be something to be put directly in default
> >         Ubuntu.
> >         > However, I do think it is the sort of mod that can gain
> >         traction
> >         > similar to Nautilus-Elementary if we can get applications
> >         repackaged
> >         > with cleaned up and optimized menus.
> >
> >
> >         "Cleaned up and optimised"; sounds like a good idea. How would
> >         you do
> >         that for the gcalctool menus? (They seem pretty good to me.)
> >
> >         General comments:
> >         (Pertaining to the removal of menus and replacement with
> >         toolbar menus
> >         as mentioned in your blog post.)
> >
> >         1. Menus provide access to functions that might be otherwise
> >         obscured,
> >         infrequently used or hard to access--especially for people who
> >         cannot
> >         use pointing devices.
> >
> >         For example, I can tell that if I want to insert something
> >         into this
> >         email I can press Alt+I to get the insert menu, even though
> >         I've never
> >         used it before. If that menu were represented by an icon in a
> >         toolbar,
> >         how would I get to it without having to tab through the entire
> >         interface?
> >
> >         2. Menus provide a convenient reference list of keyboard
> >         accelerators.
> >         If that menu were represented by an icon in a toolbar, how
> >         would I get
> >         to it without having to tab through the entire interface?
> >
> >         Take gcalctool for example. If it didn't have a menu, and you
> >         couldn't
> >         use your mouse, how would you switch to a different mode? Quit
> >         the
> >         application? Input an ASCII character?
> >
> >         3. A menu by itself takes up less space than a toolbar by
> >         itself
> >
> >         Removing the menu in gcalctool in the same way that
> >         Nautilus-Elementary
> >         removes the menu would mean that we'd have to add a toolbar
> >         for the
> >         functions that have no-where else to go. (I don't think this
> >         is
> >         particularly important though.)
> >         None of these are absolute barriers to your idea, but they are
> >         things
> >         that need to be considered/resolved.
> >
> >
> >
> >         _______________________________________________
> >         Mailing list: https://launchpad.net/~ayatana
> >         Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> >         Unsubscribe : https://launchpad.net/~ayatana
> >         More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References