Posts Tagged ‘names’

Let’s Make Our Name Sillier: KDE Chooses Not to Rebrand

You may have already heard (and here, here, here, and the announcement here) that KDE just changed their name to KDE. That’s right. What’s that? You don’t see the difference between KDE and KDE? Isn’t it obvious? Now it’s not an acronym. No, I know what you’re thinking, when you have something in all caps, by convention that means it’s an acronym- it stands for something. But KDE no longer stands for something- it’s just… KDE. My favorite part:

The expanded term “K Desktop Environment” has become ambiguous and obsolete, probably even misleading. Settling on “KDE” as a self-contained term makes it clear that we have made the shift from a limited set of software components to a community providing an ecosystem of free software applications and platforms for the end user on the desktop, mobile devices, and more.

Definitely clearer. I know I’ll be able to explain it to my mom now.

What’s really wrong with this? I mean beside naming yourself in a way that suggests your brand is an acronym even though it’s not.

Rebranding is a hard decision and I respect anyone that makes a change intended to make their product more obvious to the casual observer. I think there are a lot of open source projects that would do well to rename their project. To me, though the KDE community doesn’t deserve any notice, let alone applause, for this… decision.

If the community surrounding the GNOME desktop renamed themselves GNOME (no longer an acronym) I would be equally disdainful. But at least their acronym is also a word. Whether an acronym or not, you always have to spell out K-D-E to say KDE.

THIS WAS YOUR CHANCE!

Want to make it clear what you are or what you provide? Pick a catchy name that says something -anything- about what you’re providing so your explanation just clarifies your focus. I am not saying there’s not some good decisions and points in the repositioning document- a good read for anyone mulling a rebranding of their project. Just don’t do what they did.

At least they’re just ruining it for themselves and no one else, like app developers that develop using the KDE platform.

Oh, wait…

Software created by the KDE community is branded on its own under the umbrella brand of KDE. Use of “KDE” in the product name is optional and depending on the context. Especially for applications that are not well known as KDE applications and are not easily identified as such by a “K” prefix in their name, it is recommended to use “KDE” in the product name.

Well, at least it’s optional. One example on the announcement page mentions KDE Dolphin. Now, Dolphin as the name of a file manager (does the default file manager need a name?) is pretty questionable. I don’t see it. But KDE Dolphin? Seriously?

Thanks for visiting! Any suggestions for content that would be helpful to you? Contact me.



Naming Your App

Last time we talked about bizarre names in open source software. This time we’re going to address how to fix it. What constitutes a good name for software? Last time, we mentioned a trend to include within the app name a reference to the programming language used to code it.

Let’s think about that for a minute. If you see programs called phpBird or jBird, and you are a webmaster or network administrator, you might know that “php” refers to the scripting language PHP and that “j” refers to the Java programming language. If I am a normal user though, those mean nothing to me. Plus, jBird may be an actual desktop program programmed using Java or a web-based application based on Java, the latter of which is nearly useless for desktop users.

Keep in mind that for any project you have, you can (and perhaps should) use a project code name

until the new version is ready for release, at which time you give it it’s “real” name. For example, Internet Explorer 1.0 was codenamed “O’Hare” (which went well with Windows 95, codename “Chicago”) until it was actually released. Apple’s Mac OS X has used codenames to the extent that their releases are as well known by the version numbers (10.3, 10.4, 10.5) as the codenames (Panther, Tiger, Leopard). Yet most users aren’t going to know which they have. They have might know they have the “newest” version. But most likely, they would just tell you they have a Mac. But keep the release name separate.

Release names need to be neat and catchy, but they should also be somewhat descriptive. Consider the leading photo editing software. Photoshop, Photopaint, PaintShop Pro, Photodraw, PhotoImpact, and the GIMP are arguably the biggest in this arena. Do any of them stand out as if they don’t belong? Now, in the GIMP’s defense, I use it for everything and prefer it over any of the others. But the name GIMP is an acronym that stands for GNU Image Manipulation Program. Written out, it’s a lot more descriptive, if not overstated. All those other programs work, but they also have catchy names that are descriptive, all but one including the term “photo” in its name.

Do I think that the GIMP will change it’s name? Probably not. But if you make a photo editing program, include the term “photo” in your catchy name. Like PhotoEdit or something. If you program it in Java, don’t name it jPhotoEdit. The desktop user doesn’t care if it’s written in Java. And what if you, for some crazy reason, recode it in a different language? Better to go with a cool name.

A good name is sleek and cool, but also tells a user what it is that the program does. Not a feature list, but the basic reason they would use the software.



Who Names These Projects Anyway?

Too often, open source programs have bizarre, unhelpful names. This needs to change, at least for desktop applications, for Linux to really take off in that market.
  For all my love for Linux, software names in Linux are probably the most cryptic, arcane names possible. To understand them, you need to have seen most TV shows and sci-fi movies in the last thirty years. Preferrably, these should be the ones that no one else saw. You must also have a large zoological encyclopedia on your bookshelf. At the time of this writing, the site where the newest open source software is announced, freshmeat.net, had listed the following new releases (this was a couple years ago now):

  • Kile beta 1.0
  • JDHCPSim 1.1
  • JavaGuard 1.0b1
  • Cerberus Helpdesk 1.1.5
  • TyGeMo 0.2.0
  • Gibraltar Firewall 0.99.3a
  • archmbox 3.0.2
  • Star Voyager 0.4.0
  • KDevelop 2.1
  • OpenVPN 1.1.0
  • SPIKE 2.1
  • php_jh_pdf 1.1.0
  • lintad 0.0.3
  • KDE 3.0
  • uClibc 0.9.11
  • samhain 1.4.7
  • phpTest 0.5.0
  • HylaFax 4.1.1
  • JBoss 2.4.5
  • phpmailer 1.60 (Stable)
  • wmmemload 0.1.2
  • Rolodap 1.0
  • SmartTAN 0.1.1
  • userinfo 1.6 (Stable)
  • Sidewinder Forcefeedback 2 driver 04102002

Look at those names. How many are readily understandable to a non-geek? Hmmm. Another thing is the version numbers. I’m not saying that they shouldn’t be accurate. These numbers reflect exactly where the program is in its development. The difference between these and commercial programs is that commercial programs usually have announcements of a new version on two occasions:

  1. there has been a recall or security patch or
  2. they have hit another whole number version (like 2 or 3).

To be fair, freshmeat is a site where you announce the “freshest” release. I think it’s partly because to me, and I thus assume it to be true of all geeks, it’s fun to install new software and try it out. And this way, you can have the very latest of everything. Many open source software are what you’d call server applications. They are really for the backend or administration of a website or network. And since those that care for those areas are geeks, it’s okay for them to be a little more exact.

Open source names often have puns (notice HylaFax – Halifax, Canada). They also often incorporate a bizarre word (samhain) or the name of an animal. Common names of animals as well as genus and species names are fair game, too. For non-geeks (and even geeks), this makes it necessary to read the description of everything. You’ll notice in the list that some kind programmers have put a helpful indicator in the name of their program. If it starts (or ends) with “php” it probably has something to do with the PHP server programming language, whereas a “j” would usually indicate a problem based in some way on the Java programming language. Those names with a capital “K” usually are designed for use with the KDE, the K Desktop Environment. Programs that start with a “g” are likewise designed for the Gnome desktop. “Gnome” itself is a bizarre mixture of fancy, puns, and acronyms. It is actually an acronym for GNU Object Model Environment. GNU in turn stands for GNU Not Unix, itself a programming joke because this acronym causes what’s called an infinite loop- the acronym repeats itself forever. This is amusing to me, but I’m a programmer. I think most people would find it odd. Gnome, however, is a fine name, but I don’t like to think of as an acronym. I like it anyway.

When applications are written, they should be better named. It’s not that the name needs to be descriptive, but it should be a name perhaps combined with an explanation. Mystery. Don’t make users have to deal with that. Next week we’ll talk about good names. The surprise users feel about your app shouldn’t be that they would never have guessed that an app with this name would do that- your app should take their expectations and exceed them with features that make their lives easy.



Improving Apps: Some hints, tips, and thoughts on marketing an app for Linux.

More

Pure Linux: How I use Linux 100% of the time.

More