We do need to fix this HIG vs. desktop entry spec issue. Historically what we've done for Red Hat is just put what we want in Name and ignore GenericName.
Havoc
I made a bug over the weekend to remind myself to fix the HIG on this.
http://bugzilla.gnome.org/show_bug.cgi?id=144284
The F.D.O spec seems to suggest that Name is purely the proper name of the application without the description of functionality included. We should align on this issue. My recommendation is to format the Name as "[Proper Name] [Description of Functionality]" and GenericName as "[Description of Functionality]". When two applications exist with the same "[Description of Functionality]" then the Name is used instead.
I can see the possibility of expecting the "[Proper Name] [Description of Functionality]" format to be generated automatically via the way the F.D.O. spec is now, however the code isn't there to support this and I suspect issues (especially in regards to translation) will arise if we try to generate the names automatically.
~ Bryan
On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote:
We do need to fix this HIG vs. desktop entry spec issue. Historically what we've done for Red Hat is just put what we want in Name and ignore GenericName.
Havoc
Email message/mailbox attachment, "Forwarded message - Re: Gnome Icons, Gnome/KDE Menus need improvement" On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote:
What are your thoughts on this (response to bugzilla re: changing menu entries)
Kaffeine Maintainer (Livna.org):
------- Additional Comment #1 From Ville Skyttä 2004-06-13 21:12 --
I am not quite comfortable changing the menu entry because it is implementation
specific how the actual shown label is constructed. Moreover, we use freedesktop.org .desktop files to provide the menu entries, and so the canonical specification to follow is the desktop entry specification, which says Name is the app_name, and I'd say GenericName would correspond to app_function. http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/ar01s04.html
Until the ambiguities (and AFAICS even small conflicts) between the GNOME HIG and desktop entry specifications are clarified, and there is a clear documented way how to represent this information in .desktop files in Fedora stuff, I do not want to go into the business of changing things. What would make sense to me would be to construct the menu entry label like "Name GenericName" from the .desktop entry fields. That would result in a mess if Name already contained app_function.
===============================================================================
Bryan Clark wrote:
I made a bug over the weekend to remind myself to fix the HIG on this.
http://bugzilla.gnome.org/show_bug.cgi?id=144284
The F.D.O spec seems to suggest that Name is purely the proper name of the application without the description of functionality included. We should align on this issue. My recommendation is to format the Name as "[Proper Name] [Description of Functionality]" and GenericName as "[Description of Functionality]". When two applications exist with the same "[Description of Functionality]" then the Name is used instead.
I'm glad someone (esp @redhat) has seen the light. I suggested doing *exactly* this on the fedora-devel list a few weeks ago, and it was dismissed.
I can see the possibility of expecting the "[Proper Name] [Description of Functionality]" format to be generated automatically via the way the F.D.O. spec is now, however the code isn't there to support this and I suspect issues (especially in regards to translation) will arise if we try to generate the names automatically.
In KDE, at least, the display/handling of [Name] [GenericName] is user-configurable.
-- Rex
On Mon, 2004-06-14 at 10:23 -0500, Rex Dieter wrote:
Bryan Clark wrote:
I made a bug over the weekend to remind myself to fix the HIG on this.
http://bugzilla.gnome.org/show_bug.cgi?id=144284
The F.D.O spec seems to suggest that Name is purely the proper name of the application without the description of functionality included. We should align on this issue. My recommendation is to format the Name as "[Proper Name] [Description of Functionality]" and GenericName as "[Description of Functionality]". When two applications exist with the same "[Description of Functionality]" then the Name is used instead.
I'm glad someone (esp @redhat) has seen the light. I suggested doing *exactly* this on the fedora-devel list a few weeks ago, and it was dismissed.
Bryan and I have discussed this and we're not doing it. From an end desktop-user (not one of the active community folks, but Abby) the name of the item *is* what we put in the menu. When you or I see "Web Browser" in the menus we think "that item is epiphany". But to Abby, that item is "Web Browser": it has no other name. A good example is the calculator, because "Calculator" is the name of the program to us. Wouldn't it be weird if, upon installing "Pro+ Calculator" calculator, suddenly the default calculator was called "SimpleMath Calculator" (or whatever)? Its like some magic new name appeared for it!
"Web Browser" is the *real name* of the item to Abby, not Epiphany. Calling it "Epiphany Web Browser" all of the sudden because I installed "Firefox Web Browser" is going to be weird, and it doesn't really help anything. "Epiphany" is just as foreign to Abby as "SimpleMath Calculator" is to us.
The only two valid options I see are always including the branding name, or never including it. But, for example, Epiphany and Gaim are just as core to the desktop as a Calculator (perhaps more core at this point). I don't see a particular reason to brand them and not Calculator (except that we happen to be used to the branded names, which is why everyone gets all excited about generic names).
Upstream GNOME and KDE should include both Name and GenericName tags, but the reason is so they are translated so upstream distributors can easily choose whether to use the Branded Name[TM] or the GenericName for a particular item.
-Seth
Seth Nickell wrote:
On Mon, 2004-06-14 at 10:23 -0500, Rex Dieter wrote:
Bryan Clark wrote:
I made a bug over the weekend to remind myself to fix the HIG on this.
http://bugzilla.gnome.org/show_bug.cgi?id=144284
The F.D.O spec seems to suggest that Name is purely the proper name of the application without the description of functionality included. We should align on this issue. My recommendation is to format the Name as "[Proper Name] [Description of Functionality]" and GenericName as "[Description of Functionality]". When two applications exist with the same "[Description of Functionality]" then the Name is used instead.
I'm glad someone (esp @redhat) has seen the light. I suggested doing *exactly* this on the fedora-devel list a few weeks ago, and it was dismissed.
Bryan and I have discussed this and we're not doing it.
I respectfully disagree, and by not doing it, you're not following freedesktop.org .desktop guidelines/standards. Please, *please* reconsider.
Besides, in KDE, at least, the display of [Name] and [GenericName] is configurable, so users can have any of [Name] [Name] ([GenericName]) [GenericName] ([Name]) and redhat is free to use the latter as the default.
-- Rex
On Wed, 16 Jun 2004 15:08:10 -0400, Seth Nickell snickell@redhat.com wrote:
"Web Browser" is the *real name* of the item to Abby, not Epiphany. Calling it "Epiphany Web Browser" all of the sudden because I installed "Firefox Web Browser" is going to be weird, and it doesn't really help anything. "Epiphany" is just as foreign to Abby as "SimpleMath Calculator" is to us.
I'm confused about the assumptions being made in this use case:
1)Is Abby installing Firefox or are you installing Firefox for Abby?
2)Do we expect Abby to install any extra applications with overlapping functionality?
2a)How is Abby suppose to know how to install overlap functionality without understanding the difference between choices at the brand name level?
2b)Once Abby is aware of the brandname choices and is informed enough to make a choice for overlap applications to install, does it really mean that adding the brandname back into the menu entry for the default application for that functionality mean more confusion? Once a user is aware of brandname choice...brandname becomes a distiquishing factor.
2c)Do we expect Abby to have access to someone like you to install the overlapping applications?
-jef
On 2004-06-16T15:08-0400, Seth Nickell wrote: ) "Web Browser" is the *real name* of the item to Abby, not Epiphany. ) Calling it "Epiphany Web Browser" all of the sudden because I installed ) "Firefox Web Browser" is going to be weird, and it doesn't really help ) anything. "Epiphany" is just as foreign to Abby as "SimpleMath ) Calculator" is to us.
When I think about refrigerators, I do not think of brands. "Refrigerator" is label enough for me.
When I think about cars, the make and style can be very important to me. Different makers and models can have very different features, presentation, etc.
The differences from one calculator (or refrigerator) to another are usually not enough to warrant distinguishment. Cars (and possibly web browsers), on the other hand, might warrant some kind of differentiation in a selector.
Car rental agencies usually do not present a choice in makes and specific models, but allow you to choose style (sub compact, full size, van, etc.). What differentiates the various web browsers we support? Can we use that information in the menu?
On Wed, 16 Jun 2004 15:29:35 -0400 (EDT), Daniel Reed djr@redhat.com wrote:
Car rental agencies usually do not present a choice in makes and specific models, but allow you to choose style (sub compact, full size, van, etc.). What differentiates the various web browsers we support? Can we use that information in the menu?
Beyond the menu...can you use that sort of information at package selection time in the add/remove software process? Whatever is used to be the distiquishing characteristic would be great to see as a pervasive characteristic defining how home desktop users interact with their machines to add and remove software as well as using it.
-jef
Bryan and I have discussed this and we're not doing it. From an end desktop-user (not one of the active community folks, but Abby) the name of the item *is* what we put in the menu. When you or I see "Web Browser" in the menus we think "that item is epiphany". But to Abby, that item is "Web Browser": it has no other name. A good example is the calculator, because "Calculator" is the name of the program to us. Wouldn't it be weird if, upon installing "Pro+ Calculator" calculator, suddenly the default calculator was called "SimpleMath Calculator" (or whatever)? Its like some magic new name appeared for it!
"Web Browser" is the *real name* of the item to Abby, not Epiphany. Calling it "Epiphany Web Browser" all of the sudden because I installed "Firefox Web Browser" is going to be weird, and it doesn't really help anything. "Epiphany" is just as foreign to Abby as "SimpleMath Calculator" is to us.
It depends on how strong the branding is. Firefox, for example, is starting to develop a brand of its own. It would be worth it in that case to include "Mozilla Firefox" as the launcher instead of "Web Browser." There's also the issue of whether or not you want to consider it part of the overall brand or operating system or whether or not you're co-branding.
A great example of this was many years ago when the browser wars were in full swing. I remember having conversations with people about how they were "finding things on Netscape" even though they didn't even have Netscape installed anwhere on their computers. They were using IE, but that's how strong the brand was.
--Chris
It depends on how strong the branding is. Firefox, for example, is starting to develop a brand of its own. It would be worth it in that case to include "Mozilla Firefox" as the launcher instead of "Web Browser."
Yeah, I agree. In cases where heavy branding has already been done, it will be easiest for people to recognize the brand. E.g. if we're offering Coke in our menus (and our menus have plenty of, ahem "coke"), I'd call it Coke, not "Cola Beverage". Our goal should be to use the lowest noise / most identifiable name. The apache brand is strong enough in sysadmin circles that I would definitely label an apache menu item (if we were to have such a thing for some wacky reason *grin*) "Apache Web Server". I caution, however, that while the Firefox (or OpenOffice.org) brand could in theory be strong in 2 years, its basically non-existant in the general office worker population today.
From a usability perspective:
In cases where the brand does not already exist (the norm for practically all of our apps relative to, say, Abby), we should use generic names. Branding is usually a process of educating people about things they don't need to know, but we want them to know. It is not typically helpful from a usability perspective (there are cases where it is, but on the whole, not so much). We should not be reducing usability to help establish brands, though where a brand is established we can leverage it ).
From a branding perspective:
Prolific brands lead to brand dillution and reduces the ability to have *any* distinct brands. In the marketplace you can't control this, because everyone will try to establish a brand. In this case we can. We can effect how many brands show up in the interface.
Sometimes having two or three brands can help, because you associate different things with each brand, but you want to do this strategically. Typically you'll have multiple products under a single brand, not a brand per "product": and I even think its questionable to treat each menu item as a "product". We want to treat the core desktop as a single product, not 50 different products.
Put another way, if we add names to menu entries we have multiple brands per product. If anything, we want multiple products per brand.
There's also the issue of whether or not you want to consider it part of the overall brand or operating system or whether or not you're co-branding.
Yes. Sometimes it will be strategic (and mutually beneficial) to associate with existing strong brands by co-branding... but that's not the norm. I have no problem with a couple things that deviate from the norm on the basis of exceptional arguments.
-Seth
On Wed, 16 Jun 2004 17:19:49 -0400, Seth Nickell snickell@redhat.com wrote:
Yeah, I agree. In cases where heavy branding has already been done, it will be easiest for people to recognize the brand. E.g. if we're offering Coke in our menus (and our menus have plenty of, ahem "coke"), I'd call it Coke, not "Cola Beverage". Our goal should be to use the lowest noise / most identifiable name. The apache brand is strong enough in sysadmin circles that I would definitely label an apache menu item (if we were to have such a thing for some wacky reason *grin*) "Apache Web Server". I caution, however, that while the Firefox (or OpenOffice.org) brand could in theory be strong in 2 years, its basically non-existant in the general office worker population today.
Even so, is it in our best interest to promote the Firefox brand because it promotes our goals, even outside of the distribution of our operating system? If people are exposed to it one place, they might be willing to use it in other places as well (think home vs. office.) The more people using something other than IE, the better. Promoting the Firefox brand does this.
From a usability perspective:
In cases where the brand does not already exist (the norm for practically all of our apps relative to, say, Abby), we should use generic names. Branding is usually a process of educating people about things they don't need to know, but we want them to know. It is not typically helpful from a usability perspective (there are cases where it is, but on the whole, not so much). We should not be reducing usability to help establish brands, though where a brand is established we can leverage it ).
There's also uneducating people as well. That is, if someone has had a bad experience in the past with brand Y and those problems have been fixed, rebrand as brand Z and you have the chance to re-educate under the new brand. (Netscape 6 was terrible. Firefox is, by comparison, not.)
From a branding perspective:
Prolific brands lead to brand dillution and reduces the ability to have *any* distinct brands. In the marketplace you can't control this, because everyone will try to establish a brand. In this case we can. We can effect how many brands show up in the interface.
Yep. You need to pick and choose.
--Chris
On Wed, 2004-06-16 at 15:08, Seth Nickell wrote:
Upstream GNOME and KDE should include both Name and GenericName tags, but the reason is so they are translated so upstream distributors can easily choose whether to use the Branded Name[TM] or the GenericName for a particular item.
Keep in mind, we don't have a way at the moment to toggle whether to use Name or GenericName on a per-.desktop-file basis. We'll need to engineer a way to do this.
The simplest hack of course is to just munge GenericName over the top of Name using desktop-file-install.
Also, as an aside, I don't think the HIG is very clear on when to use "Web Browser" and when to use "Foo Web Browser" ... your mail implies this is a "desktop core" vs. "not core" kind of line, the HIG with Bryan's revisions implies it's "whether there are multiple alternatives," etc.
The HIG should document unambiguously what 3rd party, upstream, and ISV app developers should put in the .desktop file...
Another issue we need to address is getting this name consistent across the package manager, the .desktop file, and what's displayed in the app itself (titlebar, about dialog), currently these are not consistent. Some kind of automated relationship between .desktop file and package manager / installer display would be good. We could potentially have the libraries automatically g_set_application_name() from the .desktop file, also.
Havoc
On Wed, 2004-06-16 at 16:51 -0400, Havoc Pennington wrote:
On Wed, 2004-06-16 at 15:08, Seth Nickell wrote:
Upstream GNOME and KDE should include both Name and GenericName tags, but the reason is so they are translated so upstream distributors can easily choose whether to use the Branded Name[TM] or the GenericName for a particular item.
Keep in mind, we don't have a way at the moment to toggle whether to use Name or GenericName on a per-.desktop-file basis. We'll need to engineer a way to do this.
The simplest hack of course is to just munge GenericName over the top of Name using desktop-file-install.
I was sort of assuming that as the status quo. If the translation is in the desktop file, we can figure out something to do with it.... at least it gives us options if upstream includes both.
Also, as an aside, I don't think the HIG is very clear on when to use "Web Browser" and when to use "Foo Web Browser" ... your mail implies this is a "desktop core" vs. "not core" kind of line, the HIG with Bryan's revisions implies it's "whether there are multiple alternatives," etc.
The HIG should document unambiguously what 3rd party, upstream, and ISV app developers should put in the .desktop file...
Bryan & I will work on this... but it can't be unambiguous. As with most design issues, we can give guidelines and factors to consider, but a lot of it comes down to common sense. Unfortunately common sense is somethings ISVs don't display when you give them an opportunity to add more branding :-P Still, it would be hard for me to write a guideline on why we should put "Coca Cola" in the menus, but not "Safeway Select" (make up some market saturation point at which you flip to using a branded name?!?).
Another issue we need to address is getting this name consistent across the package manager, the .desktop file, and what's displayed in the app itself (titlebar, about dialog), currently these are not consistent. Some kind of automated relationship between .desktop file and package manager / installer display would be good. We could potentially have the libraries automatically g_set_application_name() from the .desktop file, also.
That's a concern I share.
-Seth
On Wed, 2004-06-16 at 17:24, Seth Nickell wrote:
The HIG should document unambiguously what 3rd party, upstream, and ISV app developers should put in the .desktop file...
Bryan & I will work on this... but it can't be unambiguous. As with most design issues, we can give guidelines and factors to consider, but a lot of it comes down to common sense. Unfortunately common sense is somethings ISVs don't display when you give them an opportunity to add more branding :-P Still, it would be hard for me to write a guideline on why we should put "Coca Cola" in the menus, but not "Safeway Select" (make up some market saturation point at which you flip to using a branded name?!?).
Maybe some kind of flow chart?
If you have a diamond in the flow chart labeled "judgment call" that's basically going to mean "ask Seth and Bryan" for Fedora Core, but for all third parties it's going to mean "make up something that we will have to fix on the Fedora level"
Maybe an "if in doubt, foo" kind of phrasing based on which answer is statistically more probable would minimize our work ;-)
I'm less worried about ISVs (who will inevitably name it "Our Trademark Here(tm)" no matter what we say) than I am about upstream projects and Fedora Extras.
Havoc
Hi,
I was noticing on Windows XP the other day that the toplevel 4-5 "most frequently used" apps show two names:
Email <i>Outlook Express</i>
Havoc
Havoc Pennington wrote:
Hi, I was noticing on Windows XP the other day that the toplevel 4-5 "most frequently used" apps show two names:
Email <i>Outlook Express</i>
Windows XP does this for the default email client and web browser, but I don't think any other applications.
Here's a screenshot: http://www.microsoft.com/presspass/newsroom/winxp/images/img009.jpg
The terms "Internet" and "Email" are permanent. The app names update to reflect the current default apps.
Steven
On Wed, 2004-06-16 at 18:55 -0400, Havoc Pennington wrote:
Maybe some kind of flow chart?
If you have a diamond in the flow chart labeled "judgment call" that's basically going to mean "ask Seth and Bryan" for Fedora Core, but for all third parties it's going to mean "make up something that we will have to fix on the Fedora level"
Maybe an "if in doubt, foo" kind of phrasing based on which answer is statistically more probable would minimize our work ;-)
I'm less worried about ISVs (who will inevitably name it "Our Trademark Here(tm)" no matter what we say) than I am about upstream projects and Fedora Extras.
Upstream projects and Fedora Extras should be right on track with the Name and GenericName spec as it stands, however I think it could be clarified even more to give better "if in doubt" statements. :-) Seth and I will get this up soon.
As for Fedora Core, unless there is some change in the spec or behavior of the menu code we'll end up munging the GenericName into the Name for most of the upstream code that is correct according to the spec.
The current system and spec work fine except for the case of keeping the standard names intact after 3rd party apps are installed. By copying the GenericName to the Name we fix this on an app by app basis. However if we can change the behavior of the code that displays the names it's better for the GNOME Desktop and Fedora can get this behavior for free too. GNOME protects the name of the standard applications that it considers to makeup the desktop with this new behavior, the same would be true for Fedora.
Seth made a good point (although this is not the best one, but one off the top of my head) about this with the Calculator in MS Windows. If for instance you installed a 3rd party calculator called "Sci-Soft Calculator" because you needed a really great scientific calculator on your PC. Should the original Calculator change it's name to be "Microsoft Calculator" now that there's a new kid on the block? Probably not, the calculator that ships with the desktop is already branded by the entire desktop and doesn't need the added branding. It is simply _the_ "Calculator" of the desktop. Especially true if the calculator happened to come from a company that was bought by MS, all of a sudden it would show it's true colors and be the "SCO Calculator" (hypothetical situation of course).
~ Bryan
On Thu, 17 Jun 2004 00:57:33 -0400, Bryan Clark bclark@redhat.com wrote:
Should the original Calculator change it's name to be "Microsoft Calculator" now that there's a new kid on the block? Probably not, the calculator that ships with the desktop is already branded by the entire desktop and doesn't need the added branding. It is simply _the_ "Calculator" of the desktop. Especially true if the calculator happened to come from a company that was bought by MS, all of a sudden it would show it's true colors and be the "SCO Calculator" (hypothetical situation of course).
Can you add/remove the MS calculator? And if so do you do it by just selecting "calculator" In the case of Epiphany in Fedora, when a home desktop user goes to add/remove "Web Browser" (Epiphany) after they have discovered Firefox and no longer care to use Epiphany, they have to know the brandname to be be able to uninstall it or reinstall it. Is there a plan in the works to make the concept of generic name for the default applications map over as useful concepts for the software install/removal operations? As much as seeing the name change will confuse people who install a second web browser. It will be much more confusing if they decided they don't need the default browser anymore and the add/remove software tools don't understand the concept of generic name as seen in the menus.
-jef
On Wed, 2004-06-16 at 16:51, Havoc Pennington wrote:
We could potentially have the libraries automatically g_set_application_name() from the .desktop file, also.
I wrote a g_set_desktop_file () function that does that.
http://bugzilla.gnome.org/show_bug.cgi?id=139974
--Ray
I've added the entry to the GNOME HIG and closed the bug related, however now the f.d.o. spec needs to be updated.
In the Desktop Entry Spec:
http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/ar01s04.html
Below:
Table 2. Standard Keys
Reads:
Name | Specific name of the application, for example "Mozilla".
If you agree that the translation of the generated names is a bad thing, which I'm certain it is. I believe this should read something like:
Name | Specific and generic name of the application, for example "Mozilla Web Browser".
That might need to be elaborated on a bit though.
Cheers, ~ Bryan
On Mon, 2004-06-14 at 11:15 -0400, Bryan Clark wrote:
I made a bug over the weekend to remind myself to fix the HIG on this.
http://bugzilla.gnome.org/show_bug.cgi?id=144284
The F.D.O spec seems to suggest that Name is purely the proper name of the application without the description of functionality included. We should align on this issue. My recommendation is to format the Name as "[Proper Name] [Description of Functionality]" and GenericName as "[Description of Functionality]". When two applications exist with the same "[Description of Functionality]" then the Name is used instead.
I can see the possibility of expecting the "[Proper Name] [Description of Functionality]" format to be generated automatically via the way the F.D.O. spec is now, however the code isn't there to support this and I suspect issues (especially in regards to translation) will arise if we try to generate the names automatically.
~ Bryan
On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote:
We do need to fix this HIG vs. desktop entry spec issue. Historically what we've done for Red Hat is just put what we want in Name and ignore GenericName.
Havoc
Email message/mailbox attachment, "Forwarded message - Re: Gnome Icons, Gnome/KDE Menus need improvement" On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote:
What are your thoughts on this (response to bugzilla re: changing menu entries)
Kaffeine Maintainer (Livna.org):
------- Additional Comment #1 From Ville Skyttä 2004-06-13 21:12 --
I am not quite comfortable changing the menu entry because it is implementation
specific how the actual shown label is constructed. Moreover, we use freedesktop.org .desktop files to provide the menu entries, and so the canonical specification to follow is the desktop entry specification, which says Name is the app_name, and I'd say GenericName would correspond to app_function. http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/ar01s04.html
Until the ambiguities (and AFAICS even small conflicts) between the GNOME HIG and desktop entry specifications are clarified, and there is a clear documented way how to represent this information in .desktop files in Fedora stuff, I do not want to go into the business of changing things. What would make sense to me would be to construct the menu entry label like "Name GenericName" from the .desktop entry fields. That would result in a mess if Name already contained app_function.
===============================================================================
desktop@lists.fedoraproject.org