From kde-core-devel Sun Jun 08 00:50:12 2008 From: Sebastian Kuegler Date: Sun, 08 Jun 2008 00:50:12 +0000 To: kde-core-devel Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Message-Id: <200806080250.12495.sebas () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=121288645904236 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1911137.XYJ0vRDe3y" --nextPart1911137.XYJ0vRDe3y Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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= =20 *need* to know the name to use its functionality. The system settings modul= e=20 Nepomuk is actually a good example here. Try to open system settings and=20 locate the module where you can finetune the desktop search. You have to kn= ow=20 the name Nepomuk, that it's related to strigi (which really is the indexer)= to=20 find it. There are two related issues here: =2D Missing keywords in the desktop file (that's actually true for most mod= ules) =2D No direct connection between "desktop search" / "semantic desktop" conc= epts=20 and Nepomuk as a name The user interface should be as self-descriptive as possible and we should = not=20 give up any bit of that just to push our branding. So the name under the=20 module in systemsettings should IMO be "desktop search", it'd be actually=20 useful to see 'Nepomuk' and 'Strigi' in the module itself, since it helps=20 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=20 KDE"-concept has a pretty well defined target group: enthusiast users and=20 developers. Developers are the one clear group that need to know those name= s,=20 because we expect them to use those frameworks when writing code. Arguably,= =20 now we have the 4.0 out there, we'd want the enthusiast users to talk about= =20 our cool applications, rather than frameworks. Most important, however, is that we should not make the UI harder to use th= an=20 absolutely necessary (that has nothing to do with dumbing down, and everyth= ing=20 with "make things descriptive for human beings"). If we agree that KDE4's=20 target users might be smart, but not necessarily technically versed (let al= one=20 in the know of implementation details in KDE), the answer is pretty clear t= o=20 me. So as marketing dude, I fully agree with Robert, based on the following: =2D we've positively identified user that are non-technical and not in the = know=20 about KDE as one of our largest target groups =2D making a complex product such as software harder to understand than=20 necessary doesn't do the product any good. Marketing is all about matchin= g=20 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=20 need to google to find out what happens when they click a certain button,=20 we've failed (and we expect that people have internet access, which is also= =20 debatable). Users just don't do that, they'll not understand and move on. E= nd=20 result: they didn't get the job done as well or as quickly as possible. Why= ?=20 Because we wanted them to know that our hardware integration framework is=20 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 usin= g =20 settings dialogs. Changing a setting is pure overhead (you need to invest t= ime=20 to change some option, you hope to win time back in the end because it make= s=20 you work faster). Having to think about, or worse, use google will (best ca= se)=20 cost them more time than necessary or (worst case) they'll simply give up a= nd=20 use another app because it just didn't work well enough for them, wasn't se= lf- 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 thi= nk > 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 betwe= en=20 'understandable for normal people' and 'useful for tech support' is always = the=20 hard part. If we put something into the user's face (like in the systray), we should m= ake=20 sure it's easy to find out what it actually does. After all, if the user=20 doesn't understand something, he won't be able to use it, meaning it's only= =20 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 wan= t=20 more people to know about our technologies. That's what we have=20 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 develop= ers=20 that ask themselves how to do something, or didn't even think about this=20 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= =20 visible to the user. It looks a lot like the Linux kernel to me. It's cool= =20 technology, it makes a lot of things possible, and it it works well, the us= er=20 can simply ignore it. No need to know about its name. So I'm all for Robert's suggestions. =2D-=20 sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9=20 --nextPart1911137.XYJ0vRDe3y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUASEssxGdNh9WRGQ75AQIItwgAkKDm//nyx/vyolEtwKwz3mFPGeZrdVFf Cz6kLYdvUypALuRmLygt8TxPbVfxtDjjKG9OEzLSYgxyDXIMb0zpoRLW/DuNQQnQ 5RLDKJAcQL9ogPIUv+Lc2E4mFhnJGKo9D5vmrdEo8jEKTmfglOSVEpjMghvFniWW VorR+Q5AOz3pZXBPgfV5e4VcXLpnLyEG8qSyKy65qdbdJRefu5LYFMKaxsz+w1pK aYMCGJxB12s3h3Q+ZjkYLbsmjf71d5Vt9DWZKwQx72Dv6hgciIkGOUi48tzQh2Y3 g1GF8DO3ccArESk7BgxF8bDaFaU/e0hl3I1/1OZuy6fjx05oadVLoQ== =B9Ko -----END PGP SIGNATURE----- --nextPart1911137.XYJ0vRDe3y--