Jakob,<br><br>I actually agree with you (discovery of features through expanding dialogues). That was me running out of time on a stream-of-consciousness sounding off.<br><br>Let's say I hadn't written the last "rules of thumb" bit, I still believe that properly identifying the user types is key in the whole GUI discussion.<br>
<br>But back to one of the original points made earlier on : "I wrote this great subsystem, given it a cool name, I want it to be embraced by the user". That *may* work for power users but it certainly does not fit into any task-driven scenarios, don't force it on users.<br>
<br>You made an interesting point with regard to the middle-ground users and I don't claim to have the answers to that (although I'd love to discuss that).<br><br>My intervention really was triggered by the ego-driven notion pushed by some hypothetical developer that the user should care about his groovy library.<br>
<br>Anyway, a lot of people have been talking about this over the last few days and my posts are really just "my 2 cents".<br><br>Cheers, <br><br>Michael O'Shea<br><br><div class="gmail_quote">On Mon, Jun 9, 2008 at 12:00 PM, <<a href="mailto:kde-core-devel-request@kde.org">kde-core-devel-request@kde.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send kde-core-devel mailing list submissions to<br>
<a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mail.kde.org/mailman/listinfo/kde-core-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-core-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:kde-core-devel-request@kde.org">kde-core-devel-request@kde.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:kde-core-devel-owner@kde.org">kde-core-devel-owner@kde.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of kde-core-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon<br>
etc.) in user interfaces (Michael O'Shea)<br>
2. KDE/kdelibs/kutils (Rafael Fern?ndez L?pez)<br>
3. Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon<br>
etc.) in user interfaces (Jakob Petsovits)<br>
4. Speeding up plotting widget (John Tapsell)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 8 Jun 2008 11:59:41 +0200<br>
From: "Michael O'Shea" <<a href="mailto:michael.a.oshea@gmail.com">michael.a.oshea@gmail.com</a>><br>
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon<br>
etc.) in user interfaces<br>
To: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID:<br>
<<a href="mailto:d323dcfd0806080259y514edfdcie7f319a767cff20a@mail.gmail.com">d323dcfd0806080259y514edfdcie7f319a767cff20a@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Although I'm joining late in the discussion, I'd like to add my voice to<br>
Michael Pyne's with regard to how to position software and users vis-a-vis<br>
of one another.<br>
<br>
I've been fascinated with the relationship between the programmer and the<br>
user ever since I started coding professionally in 1989. I have no training<br>
in cognitive whatevers that give me any authority on the matter so this is<br>
just *my *take on the debate.<br>
<br>
A few observations that I've come up with over, time:<br>
- as soon as a piece of s/w has a GUI, whatever the user wants and needs is<br>
CORRECT.<br>
- there are no stupid users, only users who want to get something done<br>
- the user doesn't care about the developer<br>
- corollary to the previous point : they couldn't care less what you think<br>
of how they should use your s/w regardless of how many sleepless night you<br>
put into it<br>
- the meaning of "intuitive" has been distorted by s/w developers to mean<br>
just about anything. Its true definition is "obtained through intuition<br>
rather than from reasoning or observation" (<br>
<a href="http://dictionary.reference.com/browse/intuitive" target="_blank">http://dictionary.reference.com/browse/intuitive</a>)<br>
<br>
Now there *are* different types of users :<br>
- casual users<br>
- power users<br>
<br>
*Any disagreements between users and s/w developers or developers between<br>
themselves come purely from a disagreement on which angle to take on the<br>
casual/power user divide.<br>
*<br>
The two types have two different needs:<br>
- the casual user has simple, task-driven needs ("I just want to download a<br>
picture from my camera, rotate it and print it")<br>
- the power user has a function-driven need ("I want to make a cool texture<br>
to put on my mesh")<br>
<br>
The two approaches will require two different workflows:<br>
- the task-driven user can be catered for with wizards. This will cover 100%<br>
of the needs of 95% of casual users. The remaining 5% are ripe to become<br>
power users<br>
- the function-driven user will load up a bunch of image files into Gimp and<br>
start futzing around with them using many filters and effects, using the<br>
full selection of tools available to mix everything up until he/she's happy.<br>
<br>
Your s/w will implement one of the following:<br>
- if you want to cater only to the casual user : a full wizard approach<br>
(your app's splash screen is a wizard and will launch other wizards)<br>
- if you want to cater only to power users : a function-driven interface<br>
where objects and tool palettes can be opened all over the show to cover the<br>
whole 4 desktops available if the user wants it<br>
- if you want to cater to both : allow the user to choose at install time if<br>
they want to use wizards or if they're a power user (present it in<br>
non-condescending terms, and like John Lennon used to say : it's possible if<br>
you try). If a wizard user ever decide they want to break out of the<br>
hand-holding, they can easily go to power user from the splash screen,<br>
top-level wizard<br>
<br>
The developer must choose which of the three above points he's trying to<br>
achieve.<br>
<br>
My rules of thumb for creating a useful GUI :<br>
- the easy/straightforward stuff should be easy to get to / achieve in 3<br>
clicks<br>
- the hard/clever stuff should be only a little more involved to<br>
- the hard/clever stuff should not swamp the easy/straightforward (dialogues<br>
with "Advanced" or "More Options" fold-outs are great)<br>
- I'd write more but it's lunchtime here and the kids are getting restless<br>
:-)<br>
<br>
For anyone who's read so far, thanks for your time.<br>
<br>
Michael O'Shea<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/4fc11e86/attachment.html" target="_blank">http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/4fc11e86/attachment.html</a><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 08 Jun 2008 10:35:34 +0000<br>
From: Rafael Fern?ndez L?pez <<a href="mailto:ereslibre@kde.org">ereslibre@kde.org</a>><br>
Subject: KDE/kdelibs/kutils<br>
To: <a href="mailto:kde-commits@kde.org">kde-commits@kde.org</a><br>
Cc: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID: <<a href="mailto:1212921334.195936.11046.nullmailer@svn.kde.org">1212921334.195936.11046.nullmailer@svn.kde.org</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
SVN commit 818331 by ereslibre:<br>
<br>
Use KAboutApplicationDialog for showing information about the plugins.<br>
<br>
CCMAIL: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
<br>
<br>
M +34 -26 kpluginselector.cpp<br>
<br>
<br>
--- trunk/KDE/kdelibs/kutils/kpluginselector.cpp #818330:818331<br>
@@ -43,6 +43,7 @@<br>
#include <kcategorydrawer.h><br>
#include <kcategorizedview.h><br>
#include <kcategorizedsortfilterproxymodel.h><br>
+#include <kaboutapplicationdialog.h><br>
<br>
#define MARGIN 5<br>
<br>
@@ -714,6 +715,25 @@<br>
const QModelIndex index = focusedIndex();<br>
const QAbstractItemModel *model = index.model();<br>
<br>
+ // Try to retrieve the plugin information from the KComponentData object of the plugin.<br>
+ // If there is no valid information, go and fetch it from the service itself (the .desktop<br>
+ // file).<br>
+<br>
+ PluginEntry *entry = index.model()->data(index, PluginEntryRole).value<PluginEntry*>();<br>
+ KService::Ptr entryService = entry->pluginInfo.service();<br>
+ if (entryService) {<br>
+ KPluginLoader loader(*entryService);<br>
+ KPluginFactory *factory = loader.factory();<br>
+ if (factory) {<br>
+ const KAboutData *aboutData = factory->componentData().aboutData();<br>
+ if (!aboutData->programName().isEmpty()) { // Be sure the about data is not completely empty<br>
+ KAboutApplicationDialog aboutPlugin(aboutData, itemView());<br>
+ aboutPlugin.exec();<br>
+ return;<br>
+ }<br>
+ }<br>
+ }<br>
+<br>
const QString name = model->data(index, NameRole).toString();<br>
const QString comment = model->data(index, CommentRole).toString();<br>
const QString author = model->data(index, AuthorRole).toString();<br>
@@ -722,33 +742,21 @@<br>
const QString version = model->data(index, VersionRole).toString();<br>
const QString license = model->data(index, LicenseRole).toString();<br>
<br>
- QString message = i18n("Name:\n%1", name);<br>
-<br>
- if (!comment.isEmpty()) {<br>
- message += i18n("\n\nComment:\n%1", comment);<br>
+ KAboutData aboutData(name.toUtf8(), name.toUtf8(), ki18n(name.toUtf8()), version.toUtf8(), ki18n(comment.toUtf8()), KAboutLicense::byKeyword(license).key(), ki18n(QByteArray()), ki18n(QByteArray()), website.toLatin1());<br>
+ aboutData.setProgramIconName(index.model()->data(index, Qt::DecorationRole).toString());<br>
+ QStringList authors = author.split(',');<br>
+ QStringList emails = email.split(',');<br>
+ int i = 0;<br>
+ if (authors.count() == emails.count()) {<br>
+ foreach (const QString &author, authors) {<br>
+ if (!author.isEmpty()) {<br>
+ aboutData.addAuthor(ki18n(author.toUtf8()), ki18n(QByteArray()), emails[i].toUtf8(), 0);<br>
+ }<br>
+ i++;<br>
+ }<br>
}<br>
-<br>
- if (!author.isEmpty()) {<br>
- message += i18n("\n\nAuthor:\n%1", author);<br>
- }<br>
-<br>
- if (!email.isEmpty()) {<br>
- message += i18n("\n\nE-Mail:\n%1", email);<br>
- }<br>
-<br>
- if (!website.isEmpty()) {<br>
- message += i18n("\n\nWebsite:\n%1", website);<br>
- }<br>
-<br>
- if (!version.isEmpty()) {<br>
- message += i18n("\n\nVersion:\n%1", version);<br>
- }<br>
-<br>
- if (!license.isEmpty()) {<br>
- message += i18n("\n\nLicense:\n%1", license);<br>
- }<br>
-<br>
- KMessageBox::information(itemView(), message, i18n("About Plugin \"%1\"", name));<br>
+ KAboutApplicationDialog aboutPlugin(&aboutData, itemView());<br>
+ aboutPlugin.exec();<br>
}<br>
<br>
void KPluginSelector::Private::PluginDelegate::slotConfigureClicked()<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 9 Jun 2008 08:59:17 +0200<br>
From: Jakob Petsovits <<a href="mailto:jpetso@gmx.at">jpetso@gmx.at</a>><br>
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon<br>
etc.) in user interfaces<br>
To: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID: <<a href="mailto:200806090859.18125.jpetso@gmx.at">200806090859.18125.jpetso@gmx.at</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Sunday, 8. June 2008, Michael O'Shea wrote:<br>
> - if you want to cater to both : allow the user to choose at install time<br>
> if they want to use wizards or if they're a power user (present it in<br>
> non-condescending terms, and like John Lennon used to say : it's possible<br>
> if you try). If a wizard user ever decide they want to break out of the<br>
> hand-holding, they can easily go to power user from the splash screen,<br>
> top-level wizard<br>
<br>
I think KDE's usability experts made it clear that switching modes like this<br>
is *not* a good thing for anyone, and that discovering more options should<br>
*not* happen via a "Advanced..." button in the vast majority of cases.<br>
<br>
Mainly because you cannot simply divide users into "power users" and<br>
"casual users" - there are users on the one extreme side and users on the<br>
other one, but there are also lots of users anywhere between. Some are<br>
experts in a particular area while being "casual users" in other areas.<br>
<br>
Coming up with several different interfaces for different target user groups<br>
is not what we want. It's the easy way out, but in the end a seamless<br>
transition from "casual user" to "power user" is the much more desirable<br>
solution. A complete break in user interfaces is not going to help making<br>
that leap.<br>
<br>
Wishes,<br>
Jakob<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 9 Jun 2008 10:18:00 +0100<br>
From: "John Tapsell" <<a href="mailto:johnflux@gmail.com">johnflux@gmail.com</a>><br>
Subject: Speeding up plotting widget<br>
To: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID:<br>
<<a href="mailto:43d8ce650806090218w4c08d89auc4a8f3615694fa40@mail.gmail.com">43d8ce650806090218w4c08d89auc4a8f3615694fa40@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi all,<br>
<br>
I'm trying to improve the plotting widget thing in the kde system<br>
monitor (aka ksysguard). Basically it draws white background,<br>
horizontal/vertical lines, and then plots the cpu usage etc lines on<br>
top.<br>
<br>
I am finding that this is taking around 30% of the CPU, which makes<br>
it kinda useless for monitoring what the cpu usage is :-D<br>
<br>
The reason for it being slow is not obvious to me.<br>
<br>
If I draw just a white background, it takes 1% CPU usage.<br>
If I draw a white background + _dashed_ horizontal lines (updating<br>
twice a second), it takes up 10% CPU time (on dual core. so 20% of<br>
one CPU).<br>
If I draw a white background + _straight_ horizontal lines (updating<br>
twice a second), it takes up 1% CPU time<br>
<br>
<br>
<br>
There seem to be other reasons as to why it's slow, but this seems to<br>
be a good place to start. Why would drawing dashed lines be so slow?<br>
(It's about 10 horizontal lines, stretching across my screen (so about<br>
1000 pixels long).<br>
<br>
How can I try to speed this up?<br>
<br>
Thanks!<br>
<br>
John Tapsell<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
kde-core-devel mailing list<br>
<a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-core-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-core-devel</a><br>
<br>
<br>
End of kde-core-devel Digest, Vol 63, Issue 20<br>
**********************************************<br>
</blockquote></div><br>