What's in a name?
Overriding common word definitions or conventional perceptions in your interface is a one way ticket to Sorrowsville. Written language is a series of symbols that describe concepts. Dictionaries exist to document the concepts commonly agreed upon by the general public. I realize that language evolves (though I sometimes lament just how it evolves), but when it comes to user interface design, I find it's best to stick to conventions when it comes to naming features.
Example: inbox. The inbox paradigm implies a collection of items (usually of a unified type), populated via submission from external sources. What's in it is usually news to you.
If you're writing an application and you have a feature that behaves in these ways, then by all means call it an inbox if that suits you. Actually, unless there are extenuating circumstances or the nomenclature would be somehow confusing to the user, you probably should call the feature an inbox. However, if the feature doesn't satisfy the conventional definition or supports numerous behaviors beyond that of the definition, you should absolutely not call it an inbox.
The value of following convention is that you don't need to teach your users how to do things. This saves them time and brain power. You're helping them not have to think.
They don't think about the connotations of the word anymore, they perceive it symbolically as a tool, useful to accomplish their goals. If you later realize there is a better name for the feature (which there most likely is), you can't simply rename the current feature without compromising user expectations. Pulling the rug out from under your current user base like that would be strike two.
Now what happens if a new revision of your application includes a feature that perfectly fits the inbox convention? Well, you're out of luck, because the word has already become symbolic of a different interaction model. And don't even think about creating a conventional inbox along side your non-conventional inbox, because that breaks your lexicon.
I've used the inbox paradigm as an example, but the same policy holds true for all mature conventions. Emerging conventions aren't as volatile, but you do run the risk of choosing a representation that will become dated as the new convention matures.
Feature naming is often one of the hardest parts of building an interface. Just be careful when you include conventional terms in your naming options. You might be looking at trouble ahead that you didn't expect.
The Swiss Army Inbox™
Let's suppose that you have an application which misrepresents the inbox convention. New users will encounter your inbox and expect X, but be delivered Y (which may = X + Z). Strike one! You've unnecessarily made new users think. Over time, your users will learn that your inbox can do Y, at which point, the inbox symbol comes to represent Y (within the context of your application).
They don't think about the connotations of the word anymore, they perceive it symbolically as a tool, useful to accomplish their goals. If you later realize there is a better name for the feature (which there most likely is), you can't simply rename the current feature without compromising user expectations. Pulling the rug out from under your current user base like that would be strike two.
Now what happens if a new revision of your application includes a feature that perfectly fits the inbox convention? Well, you're out of luck, because the word has already become symbolic of a different interaction model. And don't even think about creating a conventional inbox along side your non-conventional inbox, because that breaks your lexicon.
I've used the inbox paradigm as an example, but the same policy holds true for all mature conventions. Emerging conventions aren't as volatile, but you do run the risk of choosing a representation that will become dated as the new convention matures.
Feature naming is often one of the hardest parts of building an interface. Just be careful when you include conventional terms in your naming options. You might be looking at trouble ahead that you didn't expect.
