[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ayatana] Killing Menu Bars
On Mon, 2010-05-17 at 21:48 -0700, Tyler Brainerd wrote:
> Ah. Well, you're making me work for things, thats for sure. Ha.
It's what I do ;)
> 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.
I think IE7 had something like that ... No wait, it was a hidden menu
bar that became visible when holding Alt.
I think IE now has a similar toolbutton/menu thing to Chromium, except
it uses labels instead of icons, thereby allowing for discoverability
and avoiding the issue of poor icon metaphors.
> > 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
>
>
>