[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk,
From: "Michael O'Shea" <michael.a.oshea () gmail ! com>
Date: 2008-06-08 9:59:41
Message-ID: d323dcfd0806080259y514edfdcie7f319a767cff20a () mail ! gmail ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
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.<br><br>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 <b>my \
</b>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 \
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 of how they should use your s/w regardless of \
how many sleepless night you put into it<br>
- 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" (<a \
href="http://dictionary.reference.com/browse/intuitive">http://dictionary.reference.com/browse/intuitive</a>) \
<br> <br>Now there <b>are</b> different types of users :<br>- casual users <br>- \
power users<br><br><b>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.<br></b>
<br>The two types have two different needs:<br>- the casual user has simple, \
task-driven needs ("I just want to download a 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 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% of the needs of 95% of casual users. The remaining 5% are ripe \
to become power users<br>
- 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.<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 (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 \
where objects and tool palettes can be opened all over the show to cover the 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 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<br> <br>The developer must choose \
which of the three above points he's trying to 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 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 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>For anyone who's read so far, thanks for your time.<br><br>Michael \
O'Shea<br><br><br><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic