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

[Michael O'Shea]

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.htm>