Use of library names (Akonadi, Solid, Nepomuk, Phonon etc.) in user interfaces

Robert Knight robertknight at gmail.com
Sat Jun 7 02:59:00 BST 2008


Hello,

Names for some "behind the scenes" KDE libraries/daemons are creeping
into user interfaces.
I am concerned that:

- Users who are not KDE-tech enthusiasts seeing these would be
somewhat mystified.  To give an idea of what
I mean, imagine how odd it would seem if Apple's next Safari release
had an "Enable Squirrelfish" option in its
settings to turn JavaScript on/off.
- Distributors working to get KDE setups ready for schools,
businesses, mobile devices etc. will all have to
waste time patching software to take these names out and put something
more descriptive and obvious in place.
I think there is an element of this happening already with KDE 3 on
the EeePC, mEDUXa (correct me if I am wrong).

Some examples:

- While testing Mailody from trunk I noticed the 'Akonadi tray'
utility which gets started in the system tray.
The user interface for this tray doesn't mention anywhere what Akonadi
actually is.  When Mailody starts
up, I received a warning message about a problem locating Akonadi
resources, again, without mentioning
what an "Akonadi resource" is.

- In System Settings there are modules called "Nepomuk" and "Solid".
Again, I worry that many users are not going
to have a clue what these are.  For quite a while during the 4.0 cycle
the sound setup in System Settings was called "Phonon".

Some non-examples:

Plasma seems to have a better balance here.  There are references to
"Plasma Workspace" in various places in the UI but
you can use and configure the desktop quite happily without needing to
know what Plasma is.  For example, setting the wallpaper
and theme is done through a dialog which is helpfully called "Desktop
Settings".

We could spend a lot of time having extensive bikeshedding arguments
about each and every case that comes up.  What I propose
is to create some simple guidelines about when to use project names
and when to go for something more descriptive,
perhaps make them part of the HIG.  A suggestion on what these
guidelines might be:

- End-user applications should use their project name (eg. Dolphin).
The .desktop files already provide a generic name which can be used
instead where needed (eg. File Manager)
- Libraries and daemons which have user interfaces for setup,
settings, status monitoring etc.
should use a consistent descriptive name  (eg. "Semantic Desktop"
instead of "Nepomuk", or "Hardware Management" instead of "Solid").
I am not sure what you could use for Akonadi as its scope is very
broad.  "Akonadi Calendaring/Mail/Organisation/Backup/Tea Making" is
probably
too long for a menu item ;)

An alternative to the above that I have seen elsewhere is a
combination of the project name and a plain description (eg. "Plasma
Workspace")

Thoughts?

Regards,
Robert Knight.




More information about the kde-core-devel mailing list