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

[Kevin Krammer]

On Saturday 07 June 2008, Robert Knight wrote:

> 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.

The tray application is probably not the ultimate solution for the problem we 
have created it for, i.e. basically serving as a GUI peer for the service 
processes making up the Akonadi infrastructure.

Since KDE is now even more service based than it used to be, it might make 
sense to have a kind of monitoring (and probably control) factility for KDE's 
and related services.

> When Mailody starts 
> up, I received a warning message about a problem locating Akonadi
> resources, again, without mentioning
> what an "Akonadi resource" is.

We should definitely improve the wording here, though it will be kind of 
difficult to find a user understandable error message for a quite new concept 
of handling such common things as e-mail.

> - 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 ;)

Akonadi is a bit in a better situation anyway, because its configuration will 
in most cases happen through its client applications, e.g. in Mailody users 
can configure IMAP servers just like they would expect to be able to in a 
mail program and not have to deal with the fact that the IMAP server access 
is actually not handled by the program itself but by a helper program running 
invisibly in the background.

Even if at some point we want to have the configuration options available in 
system settings as well, we can split them into task specific sections rather 
than putting everything under "Mail & Calendaring", e.g. having 
Mail/Usenet/Newsfeed setup somewhere in a network related section, calendar 
and addressbook setup in a user/person related section.

Regarding branding it is probably more a question of creating a "powered by 
$technology" kind of attribution in the usual places (about dialog, startup 
pages, splashscreens, etc)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/72e9840c/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability