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

[Sebastian Kuegler]

On Saturday 07 June 2008 14:12:59 Tom Albers wrote:
> > Names for some "behind the scenes" KDE libraries/daemons are creeping
> > into user interfaces.
>
> Which is good. We spent a lot of time investing in promoting those words,
> and the user should see them in the interface too, to actually identify
> that we are not about words, but actually implemented stuff.
>
> Nepomuk is the big example. No-one understands what it is. Even when you
> are actually tagging in dolphin, you have no clue, you are using nepomuk.
> Which is bad. If you want it to be a bigger success, users should be
> confronted with it.

It might make sense to confront them with those names, but they should not 
*need* to know the name to use its functionality. The system settings module 
Nepomuk is actually a good example here. Try to open system settings and 
locate the module where you can finetune the desktop search. You have to know 
the name Nepomuk, that it's related to strigi (which really is the indexer) to 
find it. There are two related issues here:

- Missing keywords in the desktop file (that's actually true for most modules)
- No direct connection between "desktop search" / "semantic desktop" concepts 
  and Nepomuk as a name

The user interface should be as self-descriptive as possible and we should not 
give up any bit of that just to push our branding. So the name under the 
module in systemsettings should IMO be "desktop search", it'd be actually 
useful to see 'Nepomuk' and 'Strigi' in the module itself, since it helps 
identifying the exact gusto of "desktop search".

> I can not understand that the marketing dudes would agree with your
> proposal. But it's similar too the discussion to branded vs generic icons,
> which we had a while back to this list. Which I also did not agree too.
>
> We spent a lot of time in promoting the "pilars of KDE", let's please not
> tear them down.

I don't think it's really relevant in the user interface. The "Pillars of 
KDE"-concept has a pretty well defined target group: enthusiast users and 
developers. Developers are the one clear group that need to know those names, 
because we expect them to use those frameworks when writing code. Arguably, 
now we have the 4.0 out there, we'd want the enthusiast users to talk about 
our cool applications, rather than frameworks.

Most important, however, is that we should not make the UI harder to use than 
absolutely necessary (that has nothing to do with dumbing down, and everything 
with "make things descriptive for human beings"). If we agree that KDE4's 
target users might be smart, but not necessarily technically versed (let alone 
in the know of implementation details in KDE), the answer is pretty clear to 
me.

So as marketing dude, I fully agree with Robert, based on the following:

- we've positively identified user that are non-technical and not in the know 
  about KDE as one of our largest target groups
- making a complex product such as software harder to understand than 
  necessary doesn't do the product any good. Marketing is all about matching 
  user's needs and what the product has to offer.

> > - 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.
>
> I don't get this point at all. If you want to know, google for it.

I do believe in people's laziness (based on my own experience). If people 
need to google to find out what happens when they click a certain button, 
we've failed (and we expect that people have internet access, which is also 
debatable). Users just don't do that, they'll not understand and move on. End 
result: they didn't get the job done as well or as quickly as possible. Why? 
Because we wanted them to know that our hardware integration framework is 
called Solid, and they should need to find that out themselves. :/

Let's all remember that users want to spend as little time as possible using  
settings dialogs. Changing a setting is pure overhead (you need to invest time 
to change some option, you hope to win time back in the end because it makes 
you work faster). Having to think about, or worse, use google will (best case) 
cost them more time than necessary or (worst case) they'll simply give up and 
use another app because it just didn't work well enough for them, wasn't self-
descriptive or just took them to long to do something seemingly trivial.

> > - 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.
>
> Well great. I guess they adapt more stuff to their customers. If they think
> it should go upstream, they can find us and we can see if that fits.
>
> > - 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.
>
> (Which is pretty strange because the akonadi tray is in kdepim/akonadi,
> where the resources are also located, so how can you have the tray but not
> the resources?)
>
> This is a silly example because the distro's should make sure there are
> resources available. For all other users ( developers who compile from svn
> ) this message is fine.

Bugs happen (I agree that they shouldn't!), finding the right balance between 
'understandable for normal people' and 'useful for tech support' is always the 
hard part.

If we put something into the user's face (like in the systray), we should make 
sure it's easy to find out what it actually does. After all, if the user 
doesn't understand something, he won't be able to use it, meaning it's only 
wasting screen space and adds clutter.

> > - 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".
>
> It's all about branding. First we create a hype and then we are going to
> deny those words to be used in the interface?

Again, see above. We shouldn't make our user interface worse because we want 
more people to know about our technologies. That's what we have 
thedailywtf.com for, and I rather read about other people's software there :)

> >  What I propose
> > is to create some simple guidelines
>
> Obviously I will vote against it.

Against creating guidelines? I think it'll certainly be helpful for developers 
that ask themselves how to do something, or didn't even think about this 
issue.

> > 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 ;)
>
> Yeah, that's why it is called "Akonadi".
>
> But it is a cross-desktop implementation, so possible KDE guidelines don't
> apply anyway.

Common sense does :) In any case, the real question is if Akonadi should be 
visible to the user. It looks a lot like the Linux kernel to me. It's cool 
technology, it makes a lot of things possible, and it it works well, the user 
can simply ignore it. No need to know about its name.


So I'm all for Robert's suggestions.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/69b413e7/attachment.sig>