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