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

List:       kde-usability
Subject:    Re: KDE Usability White Papers
From:       Irwin <emerald-arcana () rogers ! com>
Date:       2002-05-30 3:09:06
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 29, 2002 15:59 pm, Simon Edwards wrote:

> I understand the importance of keeping track of how and why things are
> being changed, but what exactly is to be gained by taking things to such a
> high level of formality? Ok, for some more subtle problems, a good
> explaination of what and why is important (the combo-box delay, for
> example, is more subtle), but for most of the dialog redesigns, I think a
> full report would be overkill.

I was exaggerating somewhat, when I think about it.  The main reason we want 
documentation like this is not only to give ourselves credibility (which I 
think is sorely needed in the Linux community... we see a lot of articles 
trashing KDE (some with good reason) just because they believe that because 
it's not designed by professional UI guys that it must suck...)

Anyway, the REAL reason is to give ourselves a reference.  I know it's fun to 
discuss our complaints all the time, and to bring up UI problems, but a lot 
of them have been addressed before and we need to be able to say, "We don't 
do ___ for reason A, B, and C, as written in http://Location."  And when we 
have documents like this, we can tell developers, "Hi, when you design, think 
about usability.  Here's a bunch of reports we compiled about common problems 
and ways to think about usability.  Not only do we have reason A, B, and C, 
but research done by 1, 2 and 3 supports it."

I think to get up to this state requires a long period of preparation, of 
course.  It's mainly to convince people who otherwise don't think of 
usability that:

1) Usability is a good idea
2) What is considered usable
3) How to think more in usability terms

> Is anyone here studying/studied HCI?
>
> If a HCI student can do this as part of thier study, then I'm all for it.

It would be GREAT.  I'd consider HCI, but then I want to do some other things 
as well...

> > This is hard.  However, what SHOULD be done is that every time we do a
> > commit, we should discuss WHAT the problem was before we committed (with
> > screenshots and an example of why it was so bad), WHY it's bad, and what
> > we did to FIX the problem (with after screenshots).  It should be a
> > mandatory thing with every CVS commit.  The programmer doesn't have to do
> > it but someone here should.
>
> How do you see this fitting into what I've been working on for the website?
>  (I wrote the 'Activity' page thing targetted more at people external to
> this project who don't neccessarily have strongs skills in this area. i.e.
> normal people).

I saw what you did and I like it very much.  If I had more time (see, that's 
an ongoing problem) I would be more specific into why "Before" is really bad, 
and why "After" is an improvement.  I would specifically point out that 
people have an easier time scanning single columns of data, which is why we 
have only one column rather than two columns.  Or how a slider and scrollbox 
are redundant widgets.  And so forth.  It would be the same concept as your 
description but would have more specific reasons why certain things were 
done, and WHY they look better.

It is easy to show people a bunch of pictures and people are like, "Aww damn, 
of course AFTER looks better than BEFORE!"  However, we as usability people 
want to figure out why AFTER looks better than BEFORE so we can 1) Apply the 
changes to other similarly flawed UI's and 2) Prevent these mistakes from 
happening when we make a new UI.

But if all we can afford to do is post a before and after picture, certainly 
that is MUCH better than not having any documentation at all.

- -- 
- -- Irwin 
(Arcana)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE89aGF4kwAe/yBEAIRArEoAKCJUY1G4U0cIa4ZxRd4f4eyvnH0NwCfSUSI
bQOmvpSaQD7Ej2uciiLuqTs=
=/9Yy
-----END PGP SIGNATURE-----

_______________________________________________
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]