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. > 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? > 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. > 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. 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. > On Mon, May 17, 2010 at 8:15 PM, Luke Morton > <luke.mor...@internode.on.net> 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@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
