The entire purpose of a branding (or in this case, brand naming) something is its value for differentiation. Its usefulness has its roots way before any of us were around.
It is still typically bad practice not to include the purpose of an application in its description. Ex. who the hell would know what mousepad was at first sights? Also, how would I differentiate it from gedit if they're both named Text Editor? As such, I would suggest using both branding and purpose in the naming conventions. Let's take for example different web browsers. Firefox, Opera, Konqueror, etc. Firefox Web Browser where "Web Browser" denotes purpose, and "Firefox" differentiates from other web browsers. In the same sense, GNOME System Monitor would differentiate itself from KDE's system monitor. It is quite baffling as to why this is even an issue. Luca Ferretti wrote: > Il giorno sab, 29/03/2008 alle 12.27 +0000, Calum Benson ha scritto: > >> On 28 Mar 2008, at 17:30, daniel g. siegel wrote: >> > > >> Historically, when we wrote the HIG we originally wanted all the core >> GNOME desktop apps to have functional names only, to alleviate some of >> this confusion. Thus there would be no "gedit", no "nautilus", no >> "epiphany"; only the GNOME "text editor", "file manager" and "web >> browser". >> > > Here is an issue in this approach: for example, you could have 2 > desktop environments installed on your system, both providing a "Text > Editor" application, both using "accessories-text-editor" as launcher > icon. You have no ability to know which one you are launching.... > > This should currently occur in GNOME+KDE4 with at least "System Monitor" > and "File Manager" applications, but maybe there are other cases. > > >> However, some maintainers (not necessarily the ones I just mentioned, >> FWIW-- I can't actually remember which ones now) saw this as an >> erosion of their project's identity, and weren't willing to make this >> change. So we came to the uneasy compromise of having the functional >> name on the menu, but allowing the project name in the application and >> its documentation. This undoubtedly does confuse some users. >> > > But it's needed (or at least appreciated) when you have 2 or more > applications with the same GenericName, see before... > > >> In summary, now that you're a core desktop application and there are >> no other core applications with a similar function, your menu entry >> should not include the word "Cheese". It should be something like >> "Webcam Snapshot" (I'm sure we can do better than that, I haven't >> really woken up yet!), and the tooltip something like "Take photos and >> videos directly from an attached camera". You can use the name >> "Cheese" in the application itself, and in the documentation if that's >> what the current docs guidelines allow, but preferably no more than >> necessary. >> > > IMHO we need a more flexible and generic approach, allowing developers, > users, vendors and admins to "tweak" the Application menu or, better, > the "displayed name" for an application. > > So, starting from fd.o desktop entry spec, we have 3 keys: > * Name - Specific name of the application, for example "Mozilla" > * GenericName - Generic name of the application, for example "Web > Browser" > * Comment -Tooltip for the entry, for example "View sites on the > Internet". The value should not be redundant with the values of > Name and GenericName. > > Note that GNOME applications don't respect this spec (see also seahorse > bug #503648). > > Now, from applications point of view we have: > 1. core applications, i.e. no other core applications provides the > same function _in the same DE_, without "branding" name (for > example gnome-dictionary or gnome-panel, i.e. a name using > "gnome" and/or application function) > 2. core applications with "branding" name (for example Nautilus, or > Totem, or Baobab, or Sound Juicer...) > 3. non-core applications (usually with a "branding" name) > 4. preferences/admin tools (usually like core applications without > branding name, but those should provide OnlyShowIn key) > > IMHO the blu sky scenario is show only the GenericName when in your > menus you have only one application providing a specific function, and > show the specific application's Name when you have 2 or more > applications with the same GenericName. Note that UN*X is a multi-user > OS, so we can't simply say "install only one application and don't > care". > > Examples: > * Both Deluge and Transmission could use "BitTorrent Client" as > GenericName, but when both are installed on your system you > should have "Deluge BitTorrent Client" and "Transmission > BitTorrent Client" as displayed names in order to simply > distinguish them; > A. Epiphany, Firefox, Konqueror, Lynx, sometime Internet Explorer, > recently Safari.... all web browsers: if you are a web designer, > you could need to install them all; icons are useful, but labels > are better. > > So I need we should: > 1. Start to respect the fd.o desktop entry spec and write stuff > like "Name=Nautilus//GenericName=File Manager" or > "Name=Epiphany//GenericName=Web Browser" for core applications > with branding name and "Name=Dictionary//GenericName=Dictionary" > for core applications without branding name. Note this is good > also for stuff like SLAB aka gnome-main-menu that grabs the keys > respecting the fd.o spec; see this[1] screenshot. > 2. Add (and support in gnome-menus, I think) a > "X-GNOME-Duplicate-Policy" (or X-GNOME-Visible-Name-Policy) key > in .desktop file to allow developers to define the 'policy' to > compose the displayed name in Application menu (and in any other > place like the Open With menu/tab in Nautilus). Policies could > are: "default" to follow system policies (see below), > "always-both" to always use the composition "Name GenericName" > as displayed name (this is for developers/vendors that can't > resist to add branding), and "always-generic" to always use > only GenericName as displayed name (while I'm not sure this is > really useful). > 3. Add some default policies like: > * If the X-GNOME-Duplicate-Policy is absent, then assume > this .desktop file don't strictly respect the fd.o spec > and use only Name (current behavior); > * If this is the only application with this GenericName in > this Category, then use "GenericName" as displayed > name; > * If we have 2 or more applications with the same > GenericName in this Category, then compose the displayed > name as "Name GenericName" - note: could be interesting > to make this localizable, some languages could work > better with "Name - GenericName" or "GenericName Name" > * If this .desktop file provides the same string for Name > and GenericName (see previous Dictionary example, and in > general any core application without branding name) and > we have another application with the same GenericName, > then use Categories key to grab the DE (GNOME, KDE..) > and add "for GNOME" or "for KDE" or "for GTK" (not so > good, I know, but should only occur if you have 2 > desktop environment installed, providing the same > launcher and you are listing applications for both) > * other? > > Some examples: > > gnome-system-monitor > Name=System Monitor > GenericName=System Monitor > X-GNOME-Duplicate-Policy=default > Categories=GNOME;... > Based on previous policies its entry will always displayed as > "System Monitor" unless you have installed, for example GNOME > and KDE4: in this case, its entry will appear like "System > Monitor for GNOME" > > nautilus > Name=Nautilus > GenericName=File Manager > X-GNOME-Duplicate-Policy=default > Categories=GNOME; > If you have Dolphin installed, the displayed names will be > "Nautilus File Manager" and "Dolphin File Manager" (without "for > GNOME/KDE"). > > skype > Name=Skype > GenericName=Video and Voice Chat > X-GNOME-Duplicate-Policy=always-both > The Application menu entry for this application will always show > both keys, even if this is the only application with this > GenericName. Skype developers will be thankful to us for the > X-GNOME-Duplicate-Policy key 'cause they want to show their > name. > > Of course this proposal is just an outline, not sure it really works (or > even is useful), adds a lot of cpu cycles, and could need a lot of works > (code in gnome-menus/gnome-desktop/..., changes in .desktop files, some > GConf keys to edit policy, ...), but it seems to me a plausible solution > in order to have a fd.o compliant desktop, happy users and happy > developers/vendors. > > Oh, BTW, IMHO could be also interesting provide a way to hide all > applications from another desktop environment. Example: my home computer > is shared between myself, my system and my mother, I like to install > KDE4 to see how it works, but I don't want to show its applications in > my mom and sister sessions. By now, I've to manually uncheck any single > KDE4 app :-( > > [1] http://primates.ximian.com/~jpr/Screenshot-gnome-main-menu.png > > ------------------------------------------------------------------------ > > _______________________________________________ > Usability mailing list > Usability@gnome.org > http://mail.gnome.org/mailman/listinfo/usability > _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
