On Sun, 23 Nov 2008 11:04:13 +0100, Andrea Musuruane wrote: > > Many, *many* people (except for fan-boys and people who are told to search > > for a specific brand) don't care at all about the name of a program when > > searching for a program. When they see the word "Thunar" it doesn't ring > > any bell. Instead, it makes them nervous as they don't know whether it > > matters to know what "Thunar". It could also be a special environment > > which they don't know and don't want. Adding the program name makes such a > > summary (and in turn the package) less attractive to these people. With > > the shorter summary "File manager" they are more willing to try out the > > software they don't know yet. > > If what you say was true nobody would search and use Microsoft Office, > Adobe Photoshop, Internet Explorer, Oracle and even Coca Cola. > > Sorry, you are plain wrong about this. We live in a world of branding, > where branding recognition is important and it starts from the name. > > Many Open Source organization do branding too! Firefox, Samba, Fedora > and MySQL and brands and their controlling organizations promote these > brands. You're missing the point, however. I don't say branding isn't done. I don't say that brand recognition is unimportant to some vendors. I don't say that users never learn all the different names and brands. I'm talking about beginners, the newbie-friendliness of Fedora, and the interface to the growing number of packages in the repositories. About [Fedora] Linux newbies, who are confronted with (1) the task of finding the counter-piece for every program they are familiar with on the platform they've used before and (2) the task of finding new programs in an overwhelming collection of several thousand packages or in a default installation. Give them a task, such as resizing an image. They won't search for a specific program name, but for generic terms and phrases. "Image viewer", "resize images", "image manipulation". They won't find "Photoshop" or "IrfanView" anyway. "AbiWord" (which is a trademark) is advertised upstream as "a free word processing program similar to Microsoft® Word". They won't find it with a %summary that doesn't mention "Microsoft Word", but they find it when searching for "word processing". For many types of programs, the Open Source solution has a different name than what users, who come from other platforms, are used to. Don't hide in the small world, where you know all the sometimes weird names and acronyms for lots of packages. Samba -- a great example. Its summary says "The Samba Suite of programs", which won't be found by any user who wants to set up "a network share" or "share a printer". Only by searching and reading the package description, which expands on what the Samba suite does, they would recognise this package as one they might want. It's all different the more experienced [and or knowledgeable] a user is. Indeed, an experienced user would search for specific database suites, such as PostgreSQL or MySQL. These users would be satisfied with a simple mapping of package names to program names/acronyms: firefox : Mozilla Firefox gcc : GCC gedit : gedit gthumb : gThumb mysql : MySQL postgresql : PostgreSQL :) It isn't trivial to come up with good one-line summaries that do more than repeating the program name. It's nothing packagers like to spend time on. Reducing a packager's freedom even further won't be a good thing. The size limit is hard enough already for some packages and sub-packages. Why is gedit : gEdit is a small but powerful text editor for GNOME better than gedit : Small but powerful text editor for the GNOME desktop ? (btw, upstream calls it "gedit" not "gEdit") I think with some people one could argue endlessly about pkg summaries. And during pkg reviews that's wasted time. Still, with very old repositories it has been noticed [and agreed on, mostly] that some types of summaries simply look poor in Anaconda and package management tools. That was the rationale for some of the recommendations. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
