LWN: Comments on "TXLF: HeliOS helps schoolkids and challenges developers"

Project names

Trelane — Fri, 15 Apr 2011 16:00:55 +0000

hahahaha. I'd not thought about that before.

"Hammer." The -"er" indicates that it effects the thing that it attaches to, e.g. a "carrier" carries and a "flier" flies.

So clearly, a hammer hams. Perhaps it creates hams, or helps in the creation of ham?

Project names

robbe — Fri, 15 Apr 2011 14:01:53 +0000

Why harp on (relatively) obscure projects -- because you don't already know what they stand for? Firefox. Powerpoint. Facetime. Eclipse. Java. Blender. Facebook. etc.

We all had to learn what these stand for, the same way we had to learn that the tool to put nails into wood is called a hammer, not a nailinator.

TXLF: HeliOS helps schoolkids and challenges developers

wilck — Tue, 12 Apr 2011 15:25:32 +0000

> The lxBDPlayer media player ... confronts the user with a palette of Unix-heavy terminology such as "mount points" and "paths" even within its GUI.

"path" is a first-class concept in computing, and easy to explain, too. I see no reason not to use this term. "mount points" are a different issue.

Project names

aryonoco — Fri, 08 Apr 2011 14:14:50 +0000

I completely agree. And the best example of this in English-language countries has been the Nintendo Wii. I still remember when originally the name of the device, which was codenamed Nintendo Evolution, was released. Slashdot went up in flames, claiming that it was doomed to failure cause of the name. Similar story when the iPad was first announced. All the pad jokes died within 2 weeks, and everyone just associated a different meaning to the word in a different context.

Project names

jezuch — Fri, 08 Apr 2011 08:36:03 +0000

> "Kazehakase" clearly is a japanese word

Oh... For whatever reason I thought it was from one of the Indian (the Native American Indian, I mean) languages.

> In the end, you can't actually avoid these problems. Ignore them.

Yup... We in Poland got used to OSRAM (the light bulb brand) even though it means something like German "Mist" but worse ;) The language centers in our brains can be quite flexible with interpreting words differently in different contexts.

TXLF: HeliOS helps schoolkids and challenges developers

halla — Thu, 07 Apr 2011 18:47:58 +0000

The current situation is actually like that -- and has been for many years now. I'm not even sure when that change came in. As far as I remember, originally only the description was shown.

On my desktop it has entries like "Choqok (KDE microblogging client)" or "Amarok (audio player)" if I use the menubar style. And if you use the "application launcher" style instead of the menu style, applications are shown as an icon and two lines of text: in bold, heavy print the description and in light, smaller, gray print underneath the application name. And typing "Word Processor" in the search bar gives you a choice of word processors.

This sounds pretty ideal to me, actually.

TXLF: HeliOS helps schoolkids and challenges developers

iabervon — Thu, 07 Apr 2011 18:03:17 +0000

I think that the solution to the project name issue is to have the desktop support launching applications by role. So you click "Paint", a splash screen pops up that says "GIMP" (ideally with a logo rendered in woven plastic cord). You click "Micro-blog" and you get either Gwibber or Choqok, depending on which fits your desktop (or which you've selected to fill that role, if you've made some choice). Project names are chosen to be distinctive and contrast with other project names, particularly among applications that serve the same role; users need to find applications by role. Obviously, the same string can't work for both sounding the same as "word processor" and sounding very different from every other word for "word processor", but this is a problem we can solve with indirection.

The current situation is a bit like someone refusing to hand you your cell phone unless you can identify its product name, and people complaining that cell phone brands are hard to identify as cell phones. The problem is not that project names are hard to understand; it's that users have to understand them in order to use the project.

project naming

martinfick — Thu, 07 Apr 2011 16:15:35 +0000

> If you dislike the name Choqok, then you can see the futility in trying to provide a cognitive pathway. ('Choqok' provides as good a cognitive pathway for a Twitter client as any, to people who know it as a word meaning "sparrow".)

Not to mention that the average non computer literate person doesn't know what twitter is anyway (I have to say, I am not even sure I know what twitter is). Name confusion is not a free software problem, it comes with any complex domain and it is not likely going away. Are the problems real? Yes. Is there really a way around it? I doubt it.

With complexity, if you are going to communicate, you need large vocabularies, and thus complexity. The vocabulary is there to help those in the know, not to make things complicated for those who don't. It is complicated for them, with or without the vocabulary. Blaming the vocabulary seems like a miss placed complaint, pointing at a symptom, not the cause of the complexity.

TXLF: HeliOS helps schoolkids and challenges developers

dark — Thu, 07 Apr 2011 15:08:55 +0000

I don't think the 'hellious' project has any cause to be making fun of other project names :)

Project names

tstover — Thu, 07 Apr 2011 13:18:44 +0000

"I actually associated "gimp" with the gimp from "Pulp Fiction","

I think many do as well. What made it so bad was the mascot/logo of the dog. So now everyone wanted to know what this "gimp puppy" thing was.

Project names

Seegras — Thu, 07 Apr 2011 11:55:59 +0000

Well, not everyone does speak english, and even if they do, they might not understand colloquial meanings of certain words.

"Kazehakase" clearly is a japanese word; I don't see anything wrong with a japanese speaker choosing something like this.

I actually associated "gimp" with the gimp from "Pulp Fiction", concluded from the "GNU Image Manipulation Program" that there was probably another meaning, maybe something along the german meaning of "gimpel" (Pyrrhula, a bird; also somebody not quite intelligent), and left it at that.

And there are many more. Also, of course, there are english words that sound (or are written) exactly the same as english words, but have a total different meaning. "Mist" for instance is exactly written and spelled the same in german -- only, in german it means "Manure"... Or "burro" in spanish ("donkey") versus italian ("butter")...

In the end, you can't actually avoid these problems. Ignore them. Name your project however you like. And probably "Gwibber" is better than "ZynAddSubFX" ;)

project naming

pjm — Thu, 07 Apr 2011 11:54:32 +0000

Any "cognitive pathway" that exists for people speaking one language will not work for the majority of people, who speak some other language.

If you dislike the name Choqok, then you can see the futility in trying to provide a cognitive pathway. (Choqok provides as good a cognitive pathway for a Twitter client as any, to people who know it as a word meaning sparrow.)

It's hard to be sure that a given proposed project name doesn't exist as slang with negative connotations somewhere or other: for example, the relatively large English dictionary on my shelf doesn't mention the US slang sense of the word gimp that the speaker was referring to (which I gather means something like limp), and most of the meanings it does give are somewhat decorative (and positive) in nature, so appropriate to a graphics program. Trying to choose a name that provides a good cognitive pathway in one language seems more likely to fall afoul of this problem than choosing a name like Kazehakase.

Perhaps the lesson to take from the HeliOS experience, then, is not so much about project naming as having interfaces give more prominence to descriptions and icons and less prominence to project names.

TXLF: HeliOS helps schoolkids and challenges developers

mjthayer — Thu, 07 Apr 2011 09:58:22 +0000

> Because open source lacks the inherent profit motivation that pushes proprietary software developers to keep working past the "works for me" point, too many projects reach the "good enough" stage and stop.

Sad but true - very few developers are willing to devote their precious free time to something that doesn't interest them. So if free software is to become more user oriented, it will probably have to involve finding ways of making that task more interesting for the developers. On the face of it it doesn't sound like a hopeless task, as I am sure that most people get a tickle of pleasure from seeing their brainchild in use. Perhaps people wanting to promote free software uptake should work on teaching users to interact with developers in constructive ways. Users complaining and demanding things is very off-putting, but users who are clearly appreciative and also willing to think about a problem and what they can do themselves to help solve it can be very encouraging. Nothing is for free, and if you aren't paying money for the software you should expect to invest in some other way.

Perhaps in the case of five year old children it is their mentors who should be targeted - or then again, perhaps not just them!