unity-design team mailing list archive

[Allan Caeg <allancaeg@xxxxxxxxx>]

To make things clearer, when he said

> the app menu looks like it is exactly the type of control we are interested
> in having (both for our own use, and because we think it is a good direction
> for the general design of desktop applications).

he was referring to this
menu<http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu?action=\>

On Sat, Aug 7, 2010 at 8:48 AM, Allan Caeg <allancaeg@xxxxxxxxx> wrote:

> Here's Alex Faaborg's view on Firefox menu on the toolbar and the menu that
> Ryan Peters suggested
>
> the app menu looks like it is exactly the type of control we are interested
>> in having (both for our own use, and because we think it is a good direction
>> for the general design of desktop applications).
>>
>> To answer Mark Shuttleworth's question:
>>
>>
>> Allan, I haven't followed the Firefox usability and design discussion
>>> around the Firefox Button, but can you tell us if there will be an
>>> option to expose the button/menu off a button in the toolbar next to the
>>> URL, as it is in Chrome? That would be most straightforwardly compatible
>>> with our direction.
>>>
>>> Mark
>>>
>>>
>> We are trying to differentiate between browser level commands and commands
>> on the particular Web application.  Since the browser is itself a platform,
>> we want to draw a clear separation, both visually and interactively.  For
>> instance in these mockups the Firefox application button appears on the
>> browser background layer while the tabs containing different Web
>> applications appear in the foreground of the application:
>>
>> https://bug572482.bugzilla.mozilla.org/attachment.cgi?id=451656
>>
>> An additional reason for us to avoid placing the browser level commands on
>> the navigation toolbar is that App Tabs (small persistent tabs on the far
>> left side of the tab strip) may not have a toolbar, or may even choose to
>> expose their own native toolbar using HTML5. (example:
>> http://people.mozilla.com/~faaborg/files/20100625-tabsOnTop/appTabHypotheticalMapApp.png )
>> Also note in this example how the app button is placed on the glass
>> background layer.
>>
>> For the more general case of desktop applications that are not themselves
>> a platform, we think the app menu is a great control because it merges the
>> name of the application and top level commands into a single widget.
>> Despite not being standard control on Windows, we are seeing this design get
>> some pickup from other applications as well, most recently with the popular
>> instant messenger Trillian:
>> http://www.trillian.im/learn/tour-trillian5.html
>>
>
> Shaun, that sounds cool :)
>
> On Sat, Aug 7, 2010 at 2:01 AM, Shaun McCance <shaunm@xxxxxxxxx> wrote:
>
>> On Fri, 2010-08-06 at 11:15 -0500, Ryan Peters wrote:
>> > > > Help, Check for Updates, and About, that affect the entire program,
>> > > > meaning every open window.
>> > > "About" is a fair example. But "Help" should be context-sensitive
>> > > whenever possible -- showing help relevant to the window you choose it
>> > > from.
>> > Maybe that could be implemented. The Help option now would simply open
>> > the standard help menu for the application at the beginning.
>> > Context-sensitiveness could be possible, thought I don't know how the
>> > GNOME devs feel about it.
>>
>> We have a project underway to provide more dynamic and relevant
>> help buttons, menus, and other controls. We could probably find
>> ways to bring some of that to the application menu. Ping me if
>> you're interested.
>>
>> --
>> Shaun
>>
>>
>> _______________________________________________
>> usability mailing list
>> usability@xxxxxxxxx
>> http://mail.gnome.org/mailman/listinfo/usability
>>
>
>
>
> --
> Regards,
> Allan
> http://www.google.com/profiles/AllanCaeg#about<http://www.google.com/profiles/allancaeg#about>
> +63 918 948 2520
>
>


-- 
Regards,
Allan
http://www.google.com/profiles/AllanCaeg#about<http://www.google.com/profiles/allancaeg#about>
+63 918 948 2520