[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: clock
From:       Thomas Zander <zander () planescape ! com>
Date:       2003-06-07 19:26:19
[Download RAW message or body]

> On Saturday June 07, 2003 10:58, Alexander Kellett wrote:
> > On Sat, Jun 07, 2003 at 06:06:21PM +0200, Thomas Zander wrote:
> > > The point that adding an option even if a hundred people asked for it
> > > and the result will be that the GUI will be less usable afterwards
> > > means that you should NOT add the option is an opinion I agree with.
> >
> > sorry this is just plain wrong and very lazy.
> >
> > you should spend some time getting rid of the need for the option
> > in the first place via other usability improvements. wishlist items
> > (and more importantly, previous ones) should not just be discarded!
> 
> Right on.  Any monkey can improve usability by removing features over the 
> objections of the users.

Since I never talked about removing and much less about redesigning it I am
just reminded again of that nice saying that nobody ever reads the text from
a UserInterface :-)   Seems to work for email as well.


In another email Neil wrote:
> > It is my personal experience, and widely-known lore, that users as a
> > whole have a tendency to not know what they want.
> 
> You've generalized far too much here.  Users do know exactly what they want 
> to accomplish with their computer.

Users generally want a perfect application.  Perfect applications don't
exist and the result can be seen as something like this:

- user asks for an option to open his webbrowser with the last page
he had open when closing it previously.
- Programmer adds feature
- Another user complains that he always dails in when starting the browser
- Programmer makes feature configurable
- Many  users complains about the same problem (feautre is on by default)
- Programmer finds solution; only reopen last page when closed with a different
menu entry 'close and save'
- Another user complains that the program is not usable; at closing of the
application I have to choose from 2 close options, and a quit. What do they mean?

etc etc etc.

Point is simple. The user fights results; not problems.
THe user wants his work done. Thats it. The user is the only one who _uses_ the
application so giving him the best tool obviously means you have to know how he
does his work.
But the one thing you should never do is adding a feature just because he wants
it.
You always have to look further and ask
- does this feature request mean there is a bug elsewhere?
- does this feature request mean that he really wants another feature
to do a different thing alltogether that he now tries to do with the wrong tool?
- does this feature request mean that in 95% of the cases the user gets helped
but in the rest he is left hanging? (and is that wourth it)
- Is the user lazy (not always bad) but does that mean many other users will not
understand the application anymore?
- Or is the feature request simply a good feature request?

>From personal experience I can tell you that over 90% fall in one of the first
4 categories.  (And that 98% of all statistics are made up)


In yet another email Niel wrote:
> If you sat down to look for ways to improve an app, would you be willing to 
> work harder to improve usability without removing functionality?   Would 
> you demand from the developer that he remove what you say, or else you 
> quit?

As always the answer is not that simple as soon as it includes humans.
I can have a perfect solution but the app writer might not agree.
I have seen many times that a solution is proposed and the app writer just
says that the current version 'will do' and that I can't convince him that
the solution he choose is bound to give him more headaces.

I have quit, as you are probably aware, I just felt I was making more enemies
fighting the very people I wanted to help create a good application.

Bottom line for me is that there is always someone going to be disapointed
about a solution.

Again; this is all about adding features in the first place; not removing them
later.

-- 
Thomas Zander

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]