Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On 28/10/10 12:49, frederik.nn...@gmail.com wrote: Thank you! That's why we want to move the desktop to human language. Words like application, service or process have nothing to do with writing a letter, watching a movie or listening to music. Certainly the words Service or Process may not be necessarily useful when writing a letter etc., but iPhone users and many others don't have a problem with the term App - e.g. There's an app for that and they're perhaps not the most technically savvy computer users - no offence intended. It's a bit hard to know what you intend by That's why we want to move the desktop to human language as this is the only message I've received on the thread (having just subscribed), however, having seen how the new version of Ubuntu (10.10) has increased the number of words in dialog boxes, e.g. the file copy/overwrite files, presumably to make things simpler and friendlier, personally I find that it has had the reverse effect and obscured the intended meaning. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
The Fact that everyone and His Mom know what an App is can mostly be credited to the Fact that Apple created some of the most simple advertisements in History with strong visual emphasis on how to use the aforementioned Apps. Think of it this way, you know what's an App cause? There simply isn't anything else in the UI, so those Icons MUST be the Apps. This simple metaphor cannot be transported to a Desktop since the UI is just radically different. http://twitter.com/cldx3000 On 29.10.2010, at 11:22, steve-ayat...@hst.me.uk wrote: On 28/10/10 12:49, frederik.nn...@gmail.com wrote: Thank you! That's why we want to move the desktop to human language. Words like application, service or process have nothing to do with writing a letter, watching a movie or listening to music. Certainly the words Service or Process may not be necessarily useful when writing a letter etc., but iPhone users and many others don't have a problem with the term App - e.g. There's an app for that and they're perhaps not the most technically savvy computer users - no offence intended. It's a bit hard to know what you intend by That's why we want to move the desktop to human language as this is the only message I've received on the thread (having just subscribed), however, having seen how the new version of Ubuntu (10.10) has increased the number of words in dialog boxes, e.g. the file copy/overwrite files, presumably to make things simpler and friendlier, personally I find that it has had the reverse effect and obscured the intended meaning. ___ 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
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On Fri, Oct 29, 2010 at 22:31, Joern Konopka cldx3...@googlemail.comwrote: The Fact that everyone and His Mom know what an App is can mostly be credited to the Fact that Apple created some of the most simple advertisements in History with strong visual emphasis on how to use the aforementioned Apps. Think of it this way, you know what's an App cause? There simply isn't anything else in the UI, so those Icons MUST be the Apps. This simple metaphor cannot be transported to a Desktop since the UI is just radically different. Cannot is a little strong, don't you think? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
Hello Steve, welcome, sorry about my formulation sometimes, i was never much of a poet ;) On Fri, Oct 29, 2010 at 11:22, steve-ayat...@hst.me.uk wrote: On 28/10/10 12:49, frederik.nn...@gmail.com wrote: Thank you! That's why we want to move the desktop to human language. It's a bit hard to know what you intend by That's why we want to move the desktop to human language as this is the only message I've received on the thread (having just subscribed), however, having seen how the new version of Ubuntu (10.10) has increased the number of words in dialog boxes, e.g. the file copy/overwrite files, presumably to make things simpler and friendlier, personally I find that it has had the reverse effect and obscured the intended meaning. yeah.. every consistency aware interface must speak one or more languages, since it will otherwise never achieve actually serving the user. The more human(e) this language is, the more humans will find it easy to connect with the command interface. I think Ubuntu doesn't understand English yet, but certain formal instructions which resemble human language are understood, e.g. by the Command Line Interface ~$ Ubuntu also can't speak or write English yet, at least not creatively. What we call dialogs are in fact pre-written conversations. The user barely gets the chance to say anything really. Instead, these pseudo conversations impose geeky language upon the ordinary user, which rids them even more of purpose. An entity can only understand a message, if it is able to associate its content with experience. If i don't know the difference between suspend and hibernate for example, the only way to find out what happens is to try out the respective control. Understanding an interface makes using it correctly a walk in the park, that's why we all want to see the desktop move more into that direction. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On Sat, Aug 7, 2010 at 15:46, Matthew Paul Thomas m...@canonical.com wrote: People know what a web browser is. By far, most of them do not. http://www.youtube.com/watch?v=o4MwTvtyrUQ http://www.youtube.com/watch?v=lEt0N3xu0Do http://www.youtube.com/watch?v=ZH5ZIXItkS8 The menu doesn't control the page, but rather the application that renders a page. For OpenOffice.org, the menu wouldn't say editing my resume or designing a website or putting numbers of some sort into a table, would it? No, because that's things that people use OOo for and they know that it's all the same program; same with Firefox. If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. Thank you! That's why we want to move the desktop to human language. Words like application, service or process have nothing to do with writing a letter, watching a movie or listening to music. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On Thu, Aug 19, 2010 at 2:50 PM, Mark Shuttleworth m...@ubuntu.com wrote: Me neither :-( For a while, I thought a windicator would work, but I can't think of a relevant status that covers the use cases of the menu other than a tools icon, which isn't status at all. Functionally, I think a windicator would work just fine (it's a menu on the window decoration, just what the doctor ordered). But it would really be messing with the concept, and likely to lead to all sorts of abuse if encouraged. However, in 10.10 Netbook Edition, with Unity, we're already making menus much less visible by hiding them under the window title in the panel unless invoked with mouse or Alt. That's for the maximised browser window case, which is I think the one where the user is most concerned with pixel efficiency. How about if we start with that? Mark That could work for Unity (though I'm not very familiar with it), but we also have to think about other platforms. Got to think about something that will work upstream (GNOME). Let's not forget other desktop environments too. It's Firefox on the Linux desktop that we're talking about so there's a lot more to it than its presence on Unity. Ideas, anyone? -- Regards, Allan http://www.google.com/profiles/AllanCaeg#abouthttp://www.google.com/profiles/allancaeg#about +63 918 948 2520 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On 19/08/10 10:48, Allan Caeg wrote: That could work for Unity (though I'm not very familiar with it), but we also have to think about other platforms. Got to think about something that will work upstream (GNOME). Ah, you touch on my sensitivities! From our perspective, Unity is upstream, it's design and lead implementation is completely independent of the Ubuntu team. It's also as much part of GNOME as something like Zeitgeist and lots of other projects that have started out in the wild and moved to the center over time. We would like Gnomers to think of it as a proud contribution from Canonical, and we're a little hurt when people suggest otherwise. So, tread softly when you tread on folks dreams, even if inadvertently ;-) Let's not forget other desktop environments too. It's Firefox on the Linux desktop that we're talking about so there's a lot more to it than its presence on Unity. Indeed, I would expect FF to inspect its environment and use the right tools as available, and we'd support making that easy for the Unity case. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On 19/08/10 12:54, Allan Caeg wrote: Oops! That's not what I meant, good sir! I just wanted to make sure that we're not forgetting other platforms. I love what you and the rest of the Ubuntu team do. We sometimes just have miscommunications because of semantics and stuff. Perhaps, what I should have said was, thanks for the support from the Unity side of things and we'll find ways to do the same for other environments. I apologize, Mark No apology needed, I didn't take offense, just letting you know how we feel about that area. Your sentiment is fully supported here - FF needs to be able to express this nicely on each fo the places it will be used. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vishnoo wrote on 07/08/10 19:59: On Sat, 2010-08-07 at 14:46 +0100, Matthew Paul Thomas ... In Ubuntu 9.10 and later, the application icon does not appear in the window title bar, partly for the same reason (it's not relevant to user goals). You seem to be contradicting yourself. ;) https://bugzilla.gnome.org/show_bug.cgi?id=557469#c1 A menu item should have an icon only if it represents a dynamic object such as an application, file, device, or user, or if it makes the items in that menu segment very much more recognizable If an application icon in a menu makes it more recognizable , how is it not relevant to the user goals? I'm not suggesting that there should be an app menu but that it should not use the application icon. What I'm suggesting is that most of the time, when you're using a window, you don't need to see the application brand *at all*. Now, sometimes the application name still needs to be used in the window's title bar, because there is no relevant document name to show instead (for example, Calculator, F-Spot, or Rhythmbox). Here it could go either way: we could be consistent either with other window titles, which don't have an icon, or with menu items representing applications, which do. I think it's better to be consistent with other window titles, because the history of operating systems is a history of things that used to be separate applications slowly being merged into the OS or into other applications, so branding windows would cause churn. (To use another Ubuntu example for a moment, with apologies to those who use other OSes: Once all graphical package management is handled by Ubuntu Software Center and Update Manager, Software Sources will no longer need to be presented as a separate application with its own name and icon. It'll be much the same window as it was before, just without a distinct brand.) ... If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. You are /not/ completely right here. We do have Close and Exit in OO.o. We can close one spreadsheet and have the other document open too. There's no contradiction there. Close does the same in both suites, but that's not the problem. The problem is that Quit would do different things. Btw, Why is this an argument against the app-menu? Shouldnt we just find a way to expose right option here? Because Quit is given as the first example of an item justifying the menu's existence at all. Now again , why isnt the app-menu ideal? because of a few bugs or improper names in the app-menu? What is it that makes it completely nonsensical to use such an app-menu? ... To sum up: Because it increases cognitive load by showing branding at a time when it isn't relevant, and because most of the items proposed for it either should not exist or could sensibly be somewhere else. - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxf3rUACgkQ6PUxNfU6ecoDrQCfQOzg8ih2AtoXfQkRnBgvDNsK DwsAnjGL9G3GPOnGVYtvatB+giOJcQrr =wFO9 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Peters wrote on 07/08/10 20:12: On 08/07/2010 08:46 AM, Matthew Paul Thomas wrote: ... In this scenario someone is using (for example) Calculator, Banshee, Empathy, Gmail, Amazon, CNN, Farmville, the Gundam AnimeSuki Forum, and Hulu respectively. That they are using Firefox for 70% of these things does not mean it is useful or informative for Firefox to appear in the corner of the screen while doing them -- just as, for example, Gnome or Xorg or Ubuntu or GNU or Linux shouldn't. Taking up that much screen space with any of those brands may well be good for their vendors, but it is not relevant to user goals. Of course it's relevant. People know they're in a web browser (whatever they'd call it, most likely The Internet or The Fox-thing). because they can go to different websites in it. They know that they use /only one application/ to do so. How do you know they know that? Since you were mistaken last time, I think the burden of proof is on you now. :-) Since Safari 1.0 in 2003 and Firefox 1.0 in 2004, browser vendors have increasingly competed on unobtrusiveness -- on how little they can impose on your mental model. Browsers used to have branded throbbers, now they don't. They used to have separate toolbars and address bars, now they don't. They used to have large distinctive toolbar icons, now they don't. They used to have status bars, now they usually don't. And vendors have been experimenting with ways to let you extract Web sites as standalone windows with no browser chrome at all. When you're using applications like Amazon, Gmail, and Hulu, it's becoming less and less obvious that you're using a browser to run them. (The Firefox button is a big outlier from that pattern.) If they want options relevant to the application, they open the Application menu. Shoving it in a menu with other window-specific options would be unorganized and confusing (It isn't to you or me because we're used to it. Think of the new users or people like my mom, for example). After they figure out that GNOME has application-specific things in an application-specific place, they pick it up quickly and remember that. Unlike other menus that are structured differently for every application, the contents of the application menu are almost always the same. It makes more sense for Preferences to go under the Application menu than a Tools or Edit menu, doesn't it? Yes, it does -- as I said, that's probably the best example of an application-global item. But I think there are too few good examples to warrant the menu's existence. ... If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. Why? Because Microsoft Word and Microsoft Excel happen to be coded as separate applications, but OpenOffice.org Writer and OpenOffice.org Calc happen to be coded as a single application. Given how far off you were in thinking people knew what a Web browser was, please excuse me for not taking your word for it when you claim that people know that [OpenOffice.org] is all the same program. The app menu does not introduce this problem, but it does perpetuate it and enshrine it. And Quit is given as the first example of an item justifying the menu's existence at all. Bad example. The window still has a close document option (and if it isn't labeled as such it's a bug in the application itself, not GNOME). People will learn that the application menu quits everything (which is just as easy to learn how to use Windows or Mac, if not easier), and it is a very useful function to have. Might I note that GNOME Shell and OpenOffice.org are by no means complete and are open for bug reports. Reporting this to both would be a logical step to take. That doesn't address my point at all. That Close exists does not excuse the inconsistent redundancy (it makes it even less excusable), it's nothing to do with how complete OpenOffice.org is (it's behaved like this for over *ten years* now), and you're assuming the question of what quits everything means. ... to reduce confusion among new users and making the desktop seem more integrated and organized. Those are new claims that you're making without evidence. Apparently you don't have problems finding things if your vision is cluttered with objects. I do. I like to have as little visual clutter as possible because the interface seems cleaner and it's easier to find what I'm looking for. You're the one advocating an extra object. I'm advocating
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On 08/09/2010 05:56 AM, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Peters wrote on 07/08/10 20:12: On 08/07/2010 08:46 AM, Matthew Paul Thomas wrote: ... In this scenario someone is using (for example) Calculator, Banshee, Empathy, Gmail, Amazon, CNN, Farmville, the Gundam AnimeSuki Forum, and Hulu respectively. That they are using Firefox for 70% of these things does not mean it is useful or informative for Firefox to appear in the corner of the screen while doing them -- just as, for example, Gnome or Xorg or Ubuntu or GNU or Linux shouldn't. Taking up that much screen space with any of those brands may well be good for their vendors, but it is not relevant to user goals. Of course it's relevant. People know they're in a web browser (whatever they'd call it, most likely The Internet or The Fox-thing). because they can go to different websites in it. They know that they use /only one application/ to do so. How do you know they know that? Since you were mistaken last time, I think the burden of proof is on you now. :-) Since Safari 1.0 in 2003 and Firefox 1.0 in 2004, browser vendors have increasingly competed on unobtrusiveness -- on how little they can impose on your mental model. Browsers used to have branded throbbers, now they don't. They used to have separate toolbars and address bars, now they don't. They used to have large distinctive toolbar icons, now they don't. They used to have status bars, now they usually don't. And vendors have been experimenting with ways to let you extract Web sites as standalone windows with no browser chrome at all. When you're using applications like Amazon, Gmail, and Hulu, it's becoming less and less obvious that you're using a browser to run them. (The Firefox button is a big outlier from that pattern.) While browsers might not be focused on branding, that branding is still there. My point, however, isn't the branding, but the fact that there is a brand. If we treated every web browser as web browser or every email client as email client, how would people tell the difference between them? Branding, with different icons and application names, helps this issue, and there's a healthy level of branding exposure we need to find. If the window borders didn't have the application title, the Application Menu, with the icon as well as the name (so people can more easily recognize the name), fixes this problem because you can tell what application you have open no matter what window is focused, its contents, or what the window title is. If they want options relevant to the application, they open the Application menu. Shoving it in a menu with other window-specific options would be unorganized and confusing (It isn't to you or me because we're used to it. Think of the new users or people like my mom, for example). After they figure out that GNOME has application-specific things in an application-specific place, they pick it up quickly and remember that. Unlike other menus that are structured differently for every application, the contents of the application menu are almost always the same. It makes more sense for Preferences to go under the Application menu than a Tools or Edit menu, doesn't it? Yes, it does -- as I said, that's probably the best example of an application-global item. But I think there are too few good examples to warrant the menu's existence. ... If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. Why? Because Microsoft Word and Microsoft Excel happen to be coded as separate applications, but OpenOffice.org Writer and OpenOffice.org Calc happen to be coded as a single application. Given how far off you were in thinking people knew what a Web browser was, please excuse me for not taking your word for it when you claim that people know that [OpenOffice.org] is all the same program. The app menu does not introduce this problem, but it does perpetuate it and enshrine it. And Quit is given as the first example of an item justifying the menu's existence at all. Bad example. The window still has a close document option (and if it isn't labeled as such it's a bug in the application itself, not GNOME). People will learn that the application menu quits everything (which is just as easy to learn how to use Windows or Mac, if not easier), and it is a very useful function to have. Might I note that GNOME Shell and OpenOffice.org are by no means complete and are open for bug reports. Reporting this to both would be a logical step to take. That doesn't
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
Ryan, On Mon, 2010-08-09 at 11:22 -0500, Ryan Peters wrote: While browsers might not be focused on branding, that branding is still there. My point, however, isn't the branding, but the fact that there is a brand. If we treated every web browser as web browser or every email client as email client, how would people tell the difference between them? Branding, with different icons and application names, helps this issue, and there's a healthy level of branding exposure we need to find. If the window borders didn't have the application title, the Application Menu, with the icon as well as the name (so people can more easily recognize the name), fixes this problem because you can tell what application you have open no matter what window is focused, its contents, or what the window title is. the branding falls back down to the operating system. It's Ubuntu's access to facebook etc. not Chrome or Firefox. Martin. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
Not showing the branding while the app is running may reduce cognitive load, just like what MPT said. However, there are issues with this. *Apps that are supposed to do the same things have differences that many people know or need to know.* Whenever I'm browsing, I have to know that it's Firefox, because Chrome works differently. Some keystrokes won't work on the other app, some plugins aren't present, etc. *When more than one app of the same kind is running, they would be tagged the same way* There are cases when we open more than one web browser or music player. For example, if I want to use two different accounts on one social networking site, I would run two browsers. Not being able to identify easily which app is which would be confusing in this case. *Upstream vendors may want to keep their branding * Some of them take their marketing so seriously that they won't even consider this. This may damage our relationship with them, and may cause them to brand their products in places that will be less fit. *This could make app launching more complicated* When I launch Firefox, I would need to look for the Web Browser, Internet Browser, or whatever window. That is confusing. It's even more complicated for other apps like Sudoko. What should I expect Sudoku to be named after launching it with whatever launcher (GNOME Main Menu, GNOME Shell, etc.) Regards, Allan http://google.com/profiles/AllanCaeg +63 927 982 0592 On Aug 10, 2010 2:05 AM, Martin Owens docto...@gmail.com wrote: Ryan, On Mon, 2010-08-09 at 11:22 -0500, Ryan Peters wrote: While browsers might not be focused on branding, that branding is still there. My point, however, isn't the branding, but the fact that there is a brand. If we treated every web browser as web browser or every email client as email client, how would people tell the difference between them? Branding, with different icons and application names, helps this issue, and there's a healthy level of branding exposure we need to find. If the window borders didn't have the application title, the Application Menu, with the icon as well as the name (so people can more easily recognize the name), fixes this problem because you can tell what application you have open no matter what window is focused, its contents, or what the window title is. the branding falls back down to the operating system. It's Ubuntu's access to facebook etc. not Chrome or Firefox. Martin. ___ 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
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Peters wrote on 06/08/10 17:15: On 08/06/2010 06:17 AM, Matthew Paul Thomas wrote: ... What sense does it make to have a menu that's labelled Calculator when doing a calculation, Banshee when you're playing music, and Empathy when you're chatting with friends -- but Firefox when you're writing e-mail, Firefox when you're buying books, Firefox when you're reading the news, Firefox when you're playing Farmville, Firefox when you're posting on a Web forum, and Firefox when you're watching Hulu? Not much sense at all. It lets people see what application window they have open more clearly Sorry, I guess I didn't make my point clearly enough. Let me try again. In this scenario someone is using (for example) Calculator, Banshee, Empathy, Gmail, Amazon, CNN, Farmville, the Gundam AnimeSuki Forum, and Hulu respectively. That they are using Firefox for 70% of these things does not mean it is useful or informative for Firefox to appear in the corner of the screen while doing them -- just as, for example, Gnome or Xorg or Ubuntu or GNU or Linux shouldn't. Taking up that much screen space with any of those brands may well be good for their vendors, but it is not relevant to user goals. than looking for clues such as a super-tiny icon In Ubuntu 9.10 and later, the application icon does not appear in the window title bar, partly for the same reason (it's not relevant to user goals). or the window title, which sometimes does not say the name of the application (like this Thunderbird window, which says Write: Re: [Usability] [Ayatana] The Future of Window Borders, Menu Bars,- (it cuts off there) or if the screen is in direct sunlight. I know this is a Thunderbird window because I opened it with Thunderbird and I'm used to this behavior, but what about people with mental or visual disabilities/deficiencies, or people that aren't used to how E-mail clients work? They shouldn't be excluded; GNOME is just as much for me as it is somebody that wasn't made the same way as I was or somebody that isn't used to GNOME, and I'd hate to leave them out. You're assuming the point. Why should I care that it's a Thunderbird window? That matters only if I often use multiple e-mail clients and need to distinguish between them. Otherwise, it's obvious from the design of the window that it's a window for writing an e-mail message. Unnecessary cognitive load is just as much a problem for people with disabilities (even more, for those with mental disabilities), so using them as a rhetorical bludgeon won't work here. Also, what sense would it make to have the menu do different things for every tab? I wasn't suggesting that the menu should exist at all. People know what a web browser is. By far, most of them do not. http://www.youtube.com/watch?v=o4MwTvtyrUQ http://www.youtube.com/watch?v=lEt0N3xu0Do http://www.youtube.com/watch?v=ZH5ZIXItkS8 The menu doesn't control the page, but rather the application that renders a page. For OpenOffice.org, the menu wouldn't say editing my resume or designing a website or putting numbers of some sort into a table, would it? No, because that's things that people use OOo for and they know that it's all the same program; same with Firefox. If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. Why? Because Microsoft Word and Microsoft Excel happen to be coded as separate applications, but OpenOffice.org Writer and OpenOffice.org Calc happen to be coded as a single application. Given how far off you were in thinking people knew what a Web browser was, please excuse me for not taking your word for it when you claim that people know that [OpenOffice.org] is all the same program. The app menu does not introduce this problem, but it does perpetuate it and enshrine it. And Quit is given as the first example of an item justifying the menu's existence at all. ... In our user testing of Rhythmbox (results to be published real soon now), one consistent result was that no-one understood the distinction between Close and Quit. In other words, they didn't distinguish between the window and the application. Then I'd assume that GNOME Shell would help them understand the distinction even better because it makes a larger difference now. It is one direction in which to attempt a solution, but it's one that increases cognitive load rather than reducing it. (A relevant example of reducing cognitive
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On Sat, Aug 7, 2010 at 15:46, Matthew Paul Thomas m...@canonical.com wrote: In this scenario someone is using (for example) Calculator, Banshee, Empathy, Gmail, Amazon, CNN, Farmville, the Gundam AnimeSuki Forum, and Hulu respectively. That they are using Firefox for 70% of these things does not mean it is useful or informative for Firefox to appear in the corner of the screen while doing them -- just as, for example, Gnome or Xorg or Ubuntu or GNU or Linux shouldn't. Taking up that much screen space with any of those brands may well be good for their vendors, but it is not relevant to user goals. Oh, but you're not directly using Gmail, or Amazon, or CNN, or Farmville, or any of those sites. You're using a browser to view them. This browser has a URL bar, a back button, bookmarks, history, extensions, tabs. You can pretend that a web page is a normal application (with Prism and those kinds of things), but that's a whole other thing. If you're using a browser, then the application menu which will allow you to manipulate that browser is a useful feature. Now, if you create a Prism app from a web page, then it would make sense that the web page itself fills that menu. This is something that Prism developers would have to figure out though. You're assuming the point. Why should I care that it's a Thunderbird window? That matters only if I often use multiple e-mail clients and need to distinguish between them. Or if you use Thunderbird instead of the default email client in Ubuntu. Brands exist to reduce confusion. They allow people to talk about the software they are using. If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. Why? Because Microsoft Word and Microsoft Excel happen to be coded as separate applications, but OpenOffice.org Writer and OpenOffice.org Calc happen to be coded as a single application. Given how far off you were in thinking people knew what a Web browser was, please excuse me for not taking your word for it when you claim that people know that [OpenOffice.org] is all the same program. The app menu does not introduce this problem, but it does perpetuate it and enshrine it. And Quit is given as the first example of an item justifying the menu's existence at all. The bug seems to be that users don't expect Writer and Calc to be the same application. Instead of getting rid of a menu which would trigger this bug more often, it would be better to actually make them behave as separate applications. -- Remco ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On Sat, 2010-08-07 at 14:46 +0100, Matthew Paul Thomas wrote: ... What sense does it make to have a menu that's labelled Calculator when doing a calculation, Banshee when you're playing music, and Empathy when you're chatting with friends -- but Firefox when you're writing e-mail, Firefox when you're buying books, Firefox when you're reading the news, Firefox when you're playing Farmville, Firefox when you're posting on a Web forum, and Firefox when you're watching Hulu? Not much sense at all. True , and so did mccann mention using generic names instead of app names: http://blogs.gnome.org/mccann/2009/08/08/whatchamacallit/ Was this forgotten in the recent shell designs? Or just an oversight while doing mockups? As mentioned earlier the window titles are used and not just named Firefox always. than looking for clues such as a super-tiny icon In Ubuntu 9.10 and later, the application icon does not appear in the window title bar, partly for the same reason (it's not relevant to user goals). You seem to be contradicting yourself. ;) https://bugzilla.gnome.org/show_bug.cgi?id=557469#c1 A menu item should have an icon only if it represents a dynamic object such as an application, file, device, or user, or if it makes the items in that menu segment very much more recognizable If an application icon in a menu makes it more recognizable , how is it not relevant to the user goals? There needs to be a consistent presentation within an OS , everywhere . If the application icon is not relevant,then there is no point in showing it in the menu either. If you have a document open in Microsoft Word and a spreadsheet open in Microsoft Excel, and you choose Quit from Excel's application menu on the Mac (or Exit from its Office button on Windows), the spreadsheet will close. But if you had the same document open in OpenOffice.org Writer, and the same spreadsheet open in OpenOffice.org Calc, and you chose Quit from OpenOffice.org's app menu in Gnome Shell, the spreadsheet would close, and -- surprise! -- the document would close too. You are /not/ completely right here. We do have Close and Exit in OO.o . We can close one spreadsheet and have the other document open too. Btw, Why is this an argument against the app-menu? Shouldnt we just find a way to expose right option here? Now again , why isnt the app-menu ideal? because of a few bugs or improper names in the app-menu? What is it that makes it completely nonsensical to use such an app-menu? These are examples of what I meant by giving historical context for a design: http://design.canonical.com/2010/04/notification-area/ http://design.canonical.com/2010/05/menu-bar/ Such documentations are indeed needed for shell and appmenu too. Anyone subscribed to the shell mailing list would realize the constant opposition/rants regarding the design decisions that have been made so far. -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On 08/07/2010 08:46 AM, Matthew Paul Thomas wrote: ... Or to put it another way: The Gnome Shell application menu mimicks the Mac OS X application menu almost exactly. It may seem "shiny" or "familiar" to those designers who use a Mac, but it is obsolete today and ignores the historical context that led Apple to introduce it in the first place. Have you even /looked/ at the page detailing the menu http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu, Yes, that's why I'm writing. or even /tried/ the work-in-progress menu? It doesn't mimic the menu. In fact there are /several/ differences. Mainly, Mac's menu bar has every single menu bar option, while GNOME's only has those relevant to the application That's not relevant. We were discussing the app menu, not the menu bar as a whole. Sorry, got confused for a minute. to reduce confusion among new users and making the desktop seem more integrated and organized. Those are new claims that you're making without evidence. Therefore, it isn't "familiar" to Mac developers because it works in a totally different way (drop-down instead of immediately accessible, yet taking up less space). They are both pull-down menus, taking up almost exactly the same amount of space. The biggest difference is that the Gnome version uses the application icon (in quite a stylish way), while the Mac version does not. It doesn't ignore any historical context; the page detailing the menu as well as the design document are very, very detailed and instead of directly moving forward, they're simply taking a step back, looking at what they have, and how they can improve it for everybody. That's not just people who are used to GNOME, or people used to other OSs, or people without visual or mental problems, or "power users", but everybody they can. You'd be amazed at the level of detail they're approaching this project with and the questions they ask while doing so. ... These are examples of what I meant by giving historical context for a design: http://design.canonical.com/2010/04/notification-area/ http://design.canonical.com/2010/05/menu-bar/ In contrast, http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu (and the equivalent section of http://people.gnome.org/~mccann/shell/design/GNOME_Shell-20091114.pdf) doesn't even mention the Mac application menu, let alone Nextstep or the Microsoft Office button. Of course, the Gnome Shell designers are under no obligation to explain the similarities and differences, but I think if they did, it would substantially improve their designs. GNOME does take it into context, but they see the global menu bar that Mac uses as a bad thing. The reasoning behind them using an application menu, from what I can gather, is that if they used the entire global menu bar system that Mac uses, it would take too long to open menus. To open a menu for one window or for one application, you'd first have to select it and then move your mouse all the way to the top of the screen. While this reduces aiming slightly, it takes longer to do, thus the GNOME design team (if I remember correctly) hates it. They do, however, see value in the application menu portion. Here's two usage examples: 1) A user uses an instant messenger, such as Pidgin. The instant messenger has a different menu bar on the conversation window compared to the buddy list. The options on the conversation window only affect the currently active conversation, while the menu bar on the "buddy list" has options that affect both the window and the application as a whole. If you only have the conversation window open, or the buddy list window is on another workspace or minimized, you can still access "entire-application options" from the conversation window by using the Application Menu. Things such as smiley settings, preferences, plugins, enabling or disabling accounts, or the help function could be moved to the application menu. 2) After clicking a "malto:" link in your web browser, a composer window for your email program opens. The menu bar for your composer window compared to the main window is different, but the main window isn't open. The Application Menu would still allow for you to open your preferences, account information, add-on settings, and so on. The rest of the menu bar items will stay there. 3) Suppose that somebody opens a program in Wine. Windows applications natively don't support the Application Menu, so the Application Menu could instead be
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
On 08/06/2010 06:17 AM, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Peters wrote on 30/07/10 21:05: ... GNOME 3 comes out next year. With it comes many new technologies including the Application Menu, a message tray for non-system applications, and GTK+ 3. The GNOME Shell design page http://live.gnome.org/GnomeShell/Design has an interesting page on the Application Menu (aka AppMenu) http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu, a feature coming in GNOME Shell. I think an application menu like that might have made sense in the 1980s, or even when it appeared in Mac OS X in 2000, but today it would be an incoherent waste of space. What sense does it make to have a menu that's labelled "Calculator" when doing a calculation, "Banshee" when you're playing music, and "Empathy" when you're chatting with friends -- but "Firefox" when you're writing e-mail, "Firefox" when you're buying books, "Firefox" when you're reading the news, "Firefox" when you're playing Farmville, "Firefox" when you're posting on a Web forum, and "Firefox" when you're watching Hulu? Not much sense at all. It lets people see what application window they have open more clearly than looking for clues such as a super-tiny icon or the window title, which sometimes does not say the name of the application (like this Thunderbird window, which says "Write: Re: [Usability] [Ayatana] The Future of Window Borders, Menu Bars,-" (it cuts off there) or if the screen is in direct sunlight. I know this is a Thunderbird window because I opened it with Thunderbird and I'm used to this behavior, but what about people with mental or visual disabilities/deficiencies, or people that aren't used to how E-mail clients work? They shouldn't be excluded; GNOME is just as much for me as it is somebody that wasn't made the same way as I was or somebody that isn't used to GNOME, and I'd hate to leave them out. Also, what sense would it make to have the menu do different things for every tab? People know what a web browser is. The menu doesn't control the page, but rather the application that renders a page. For OpenOffice.org, the menu wouldn't say "editing my resume" or "designing a website" or "putting numbers of some sort into a table", would it? No, because that's things that people use OOo for and they know that it's all the same program; same with Firefox. The menus that Chrome and Firefox and Opera and every other application with menus are often relevant to two different things at once: the window and the application. In our user testing of Rhythmbox (results to be published real soon now), one consistent result was that no-one understood the distinction between "Close" and "Quit". In other words, they didn't distinguish between the window and the application. Then I'd assume that GNOME Shell would help them understand the distinction even better because it makes a larger difference now. The difference between the two is that there are some options, such as Open File, Print, or the View menu that only affect the current window, and some options such as Preferences, options for Add-Ons, Preferences and add-ons are the strongest case for a menu that applies to the application in general. Bookmarks, (maybe) History, Both of those are window-specific. (Modern Web browsers show a global history in any "History" menu, but actually choosing any of the items affects only the current window.) Hence why I said "maybe". I agree that those are very window-specific decisions, and I wasn't sure whether or not they would make sense in the menu (they will probably be left out). 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. And "Check For Updates" is, in Ubuntu and other Gnome-based OSes, the job of the OS rather than the application. Not quite. GNOME has no "official" package manager. Fedora, Debian, Ubuntu, Arch and so on, do. GNOME by itself exists without a package manager, and there are quite a few people that don't use package managers. While it is less organized, and package managers are why so many people love using Linux,
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
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 sha...@gnome.org 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 usabil...@gnome.org http://mail.gnome.org/mailman/listinfo/usability -- Regards, Allan http://www.google.com/profiles/AllanCaeg#abouthttp://www.google.com/profiles/allancaeg#about +63 918 948 2520 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More
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 menuhttp://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu?action=\ On Sat, Aug 7, 2010 at 8:48 AM, Allan Caeg allanc...@gmail.com 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 sha...@gnome.org 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 usabil...@gnome.org http://mail.gnome.org/mailman/listinfo/usability -- Regards, Allan http://www.google.com/profiles/AllanCaeg#abouthttp://www.google.com/profiles/allancaeg#about +63 918 948 2520 -- Regards, Allan http://www.google.com/profiles/AllanCaeg#abouthttp://www.google.com/profiles/allancaeg#about +63 918 948 2520 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
