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