When we are coming up with terms to use for various aspects of the system, the first thing we ask ourselves is, "Is this a word or phrase the user sees, or is this a developer issue?"
For things that the user sees, we use words and phrases that describe what the object or action is and avoid technical jargon. So, for instance, we don't use the word "Plasma" in the Plasma user interface except in the About Box. The person logging in probably doesn't really care what that the wonderful thing they see is called, they just like using that thing that, to them, is their "desktop".
For things that the user doesn't see, we try and use technically useful terms. So because the plugin metaclass is call Applet, the .desktop files are plasma-applet-*.desktop by convention. The user never sees this and it helps developers understand the technical path things take. Another example from Plasma is "Containment" versus "Activity": the former is a literal technical term describing the class structure, while the latter is the ultimate functionality it (and a few other related classes) provide to the user.
This leads to slightly different sets of language depending on whether your are dealing with the technical mechanics of things or the user interface. A common term for this is "plumbing versus porcelain" referring to how the user of a sink or toilet sees just the (hopefully) nice exterior and doesn't see any of the internal pipework and supporting mechanisms.
Once you get used to thinking in terms of "mechanism versus purpose" or "developer and user", it all becomes second nature. The alternative of trying to use one language for both developer and user often results in "leaking" jargon out to the user interface (not good) because user language just doesn't map cleanly to the technical implementations in many cases. So instead we have an accurate and concise language for the technology project and a clear and understandable language for the user. Understandably, those who straddle somewhere in the middle (e.g. packagers) can sometimes find this bewildering. ;)
I hope that clears up a few more bits of confusion around the whole "which words to use" issue.
Subscribe to:
Post Comments (Atom)
11 comments:
The person logging in probably doesn't really care what that the wonderful thing they see is called, they just like using that thing that, to them, is their "desktop".
In the same tone, he certainly does not care for kontact, kmail, k3b (!?),etc, etc.. can you comment how name conventions for programs is being handled in kde4? I like Gnome's simple "File Manager", "Web browser", and "Text editor". Apple gets away with iEverything, but I dont think KDE can with kSomething (perhaps consonents vs vowels is the deal here).
In the French translation, the action to unlock the widgets is called "Déverrouiller les Plasmoïdes" since version 4.0. Isn't it in direct contradiction with this point of view ?
(We also have "Ajouter des plasmoïdes..." for Add Widgets)
Hi Aaron,
I'm glad this is becoming a trend in KDE. It was nice to notice when I upgraded my old laptop from KDE 3 to 4 how much more 'friendly' the language is that greets you.
> I like Gnome's simple "File Manager",
> "Web browser", and "Text editor".
In KDE 4 (and in KDE 3 with OpenSuse) this is done in the menu used to launch applications. Only if there are two applications with the same generic description (eg. Firefox and Konqueror are both a 'Web Browser') will the actual application name be shown. So you can find the program to browse the web, chat to friends or look at images without knowing what it is called.
Hey Aaron,
Agreed with you and Rob on this one. It's really nice to see KDE improving massively in these sort of little areas and helps to show that usability doesn't just mean removing features (which some people would argue).
Keep up the good work!
There's one small problem though: we (KDE) market/advertise and buzz up terms in our announcements and marketing articles: Plasma, Akonadi, Nepomuk, Strigi, and so on. So on one hand, we try to bring the terminology to the level of end users, specially in the UI. But on the other hand, we spread the actual names of the said parts of KDE.
Also, I would have to disagree with Anil. IMHO, there is a difference between the desktop's underlying frameworks/subsystems, such as the ones I listed above, and specifc applications for specific jobs. A user doesn't need (or probably don't want) to know that Plasma is the desktop framework, that Akonadi is the PIM storage backend, that Strigi/Nepomuk provides indexing and tagging. But that doesn't mean he wouldn't have to or want to know that K3b is a burning tool, that KMail is an e-mail client, etc. And if someone were to bring up that "it confuses users", I would ask him to show me a Windows or OS X user who only knows apps by their description/purpose. Most likely, they are able to effortlessly name Nero, Outlook, Safari, iPhoto, etc. Or even without the name, they would more easily associate an app's icon (like a blue 'e'), it's branding, to it's purpose rather than rely on some generic "web browser" name. Of course, usability experts might prove me wrong, as my arguments only come from my experience dealing with people.
In any case, what I'm trying to say is that for stuff like Plasma, Akonadi, etc., it's probably better to stick to the generic names/descriptions, but not for specific apps. Besides, KDE has always provided both name and description in the main menu and, with the search function in Kickoff, it shouldn't be too difficult to get to the app that you want.
I'm also in favour of hiding application names from the user somewhat (not completely though), and presenting their function instead.
As a counter-point to Jucato's argument: I deal with many non-technical users every day. If I ask them to launch "Internet Explorer", they look at me blankly. If, however I ask them to launch their web browser they know exactly what I mean. Of course they know that the "Blue 'E'" is their web browser - they know this because they use it every day. However, If we're trying to make KDE easier to use for *new* users, then we need to start with the functional names, and later introduce the application branding (which includes the application name, icons etc. etc.).
In time, new KDE users will understand that Konqueror is the name of their web browser - you and I already know this, because we've been using it for a while. However, *any* user - even the technically giften ones will struggle to pick the right application if all they're given is a list of unfamiliar names.
I pretty much disagree with your bi-lingual approach, mainly because the functional vs. "inner working" distinction doesn't match cleanly to the user vs. developer distinction. In general it is good practice to name classes and methods after their function, not after their internal implementation. So the question is: If you think the terms "widget" (some English-German dictionary suggests "Dingsbums" as translation) and "activity" are more appropriate in this regard, why haven't you named the classes Plasma::Widget and Plasma::Activity in the first place?
@Tau: "why haven't you named the classes Plasma::Widget and Plasma::Activity in the first place"
Applet vs Widget: for *developers* the word "widget" has a defined meaning already; for Plasma the Applet class is just the "bootstrap" class for the plugin, while the entire plugin + its data is considered the "widget".
Containment vs Activity: internally an Activity is a collection of items: the Containment (which lays out the applets), Wallpaper (which paints the background), Context (the semantic bits), etc. additionally, in plasma-desktop, only the desktop containments are Activities, while Containments are found elsewhere such as in the panels.
if you do wonder about these things, i really recommend reading through the code. it's pretty clear and easy to read.
"In general it is good practice to name classes and methods after their function"
i think you'll find that we do exactly that. however, this misses the point i'm making in this blog entry rather entirely and sort of proves the need for such things to be written. :)
the salient point to take from this entry is that the functionality of the code *often does not map to anything meaningful to the user*.
developers often miss that point and then either use misleading names in their code (trying to bend the code to the user that will never see it) or unintentionally barrage the user with jargon.
we also see this in configuration interfaces where the developer designs the configuration in a way that it mimics the inner workings of the code.
Applet vs Widget: for *developers* the word "widget" has a defined meaning already; for Plasma the Applet class is just the "bootstrap" class for the plugin, while the entire plugin + its data is considered the "widget".
It is true that the function of this visually distinct thing on the screen you can interact with (the "widget") is a result of more than one object, but an instance of (a suclass of) Plasma::Applet is clearly the main object, it not only defines
the visual appearance (via Plasma::Applet::paintInterface) but also the interaction. After all, Plasma::Applet is a direct subclass of QGraphicsWidget (sic!) so there are rellay no reasons for different names.
Containment vs Activity: [...] additionally, in plasma-desktop, only the desktop containments are Activities, while Containments are found elsewhere such as in the panels.
Yes, this is a real conceptual difference.
however, this misses the point i'm making in this blog entry rather entirely and sort of proves the need for such things to be written. :)
the salient point to take from this entry is that the functionality of the code *often does not map to anything meaningful to the user*.
It seems to me that you have slightly changed your argumentation. In your first try you have argued with the function vs. mechanism distinction for your two-language thesis, but this isn't really conclusive. Now you are arguing with different abstraction levels. These indeed exist. It is essentially the difference between object-oriented analysis and object-oriented design. The result of the first is a purely functional specification and should in an UI context incorporate all issues relevant to the user, but can also be very formal/technical. If things like
we also see this in configuration interfaces where the developer designs the configuration in a way that it mimics the inner workings of the code
happen the developer most likely hasn't thought about his application in functional terms. But this is quite different from the question what information should be exposed to the user.
Aaron, the button/lineedit/checkbox/label/etc. are called widgets in Kexi's form Designer. (some people call them 'controls' but I find this as not accurate, as e.g. label does not control anything).
I wonder how we can make it easy to distinguish between desktop widgets and the above widgets in GUI messages and documentation.
@jstaniek: I think the only real solution is to fix Plasma to stop abusing the term "widgets" in the UI.
I strongly disagree with the idea that we should hide the "jargon". Developers will always answer user questions in "jargon", there's no way you can prevent that (because the developers often don't even know the vague non-"jargon" term, and even less so its translation into the user's language), so it'll only help the users if the "jargon" is actually in their menus (and an advantage is that the "jargon" is often composed of proper nouns which are invariant under translation, which makes it easier to find the entries described by English documentation in a translated KDE).
Post a Comment