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

List:       kde-usability
Subject:    Re: How to join the KDE Usability Team?
From:       "Dotan Cohen" <dotancohen () gmail ! com>
Date:       2008-12-30 21:18:55
Message-ID: 880dece00812301318y6938901lb15a00f1a57c0e63 () mail ! gmail ! com
[Download RAW message or body]

2008/12/30 Celeste Lyn Paul <celeste@kde.org>:
> I think you are confusing designers with graphic artists.  Design is design.
> Usability is a quality.  You need good design in order to have good usability.
> Interaction architecture is a specific specialty I get billed out for in the
> company who employs me.
>

I would really like to agree with you, as on a superficial level the
idea that one needs good design to have good usability sounds logical,
but my experience proves otherwise. The Mozilla apps have terrible UI
designs (my opinion, of course) but I find them wholly usable because
they are so configurable. Likewise, the design of Basket is nothing
short of ingenious, however, the application is terribly unusable.

> Back to the ORIGINAL question about the HIG (which you continue on the
> discussion below).  There is no motivation or purpose for a user to know what
> is in the HIG.  For them to go in to it and learn the rules so they can report
> bugs would be the same as reading up on coding styleguide and reviewing source
> code for incorrect uses of classes or lack of comments.  At that point you are
> no longer a user but have taken on a different role, either as a designer or a
> coder.
>

Alright, then, I _won't_ go in there and learn the rules. I have filed
at least 30 usability bugs in the past, most of which have been fixed
or at least confirmed. This includes both errors and feature
enhancement requests. Would you like me to link to a few?

In short, I _use_ the software. Saying that I do not know what would
make the software easier to use just because my degree is mechanical
engineering and not UI design is ridiculous. Actually, it is
insulting.

> Software bugs -- when things aren't working as intended -- are different.
> Reporting those bugs is part of the user's role.
>

Agreed, that's why I'm here!

> Incorrect captialization is one thing, but if you click a button and you
> expect it to do one thing and it does another, it is difficult for the user to
> ascertain if it is a software bug, or if it is working as the developer
> intended.

I can point out an example of this problem:
http://bugs.kde.org/show_bug.cgi?id=91445

Here, the problem reported is (haha) a feature, not a bug, in the
sense that it is doing what the programmer intended. However, what the
programmer intended is both unintuitive and useless. Furthermore, the
programmer has has no formal UI training in this case than has the
user. That is the case for most of KDE. Just look at Aaron's work in
Plasma: I find it to be completely ingenious and even the bits that I
had disagreed with in the past (because of Aaron's secretiveness
regarding what they _will_ do when he is finished) I have learned to
accept and even embrace (Cashew in particular). Does Aaron have a
degree in UI design?

> If it is working as the developer intended but now how you expect,
> then it is difficult for you to put yourself in an unbiased position to
> determine who has the better mental model, you or the developer.
>

1) I do not have to be in an unbiased position. I use the software,
that is the best position to be in regarding usability judgment.

2) I also have about 20 KDE users who I am in continued contact with
who I often ask questions about their usage (I may even be a bit
invasive at times, and I know that). When I notice a pattern, I report
it.

>> I do not want to become a programmer, but according to BKO I've
>> participated in over 400 bug reports, about half of which I've filed
>> and the other half of which I've triaged and added reproduction
>> instructions, marked as dupe, or helped in other ways. If I can do
>> that without formal training, why can't I file usability issues. I sit
>> in front of KDE for 12 hours a day!
>
> See previous mail about conflict of interest.  Do I need to start quoting Don
> Norman? Users are not designers. They can't be.

Please do. And be specific as to why users cannot be designers, or
RTFM me with a link. Teach me, I'm not proud and I certainly could
learn something that would benefit myself and KDE.

> Controlled participation is
> one thing, "user-directed" is a bad bad thing.
>

Again, be specific or provide links. I am not being sarcastic, I
really want to learn.

>> New content does not make a HIG. Content that conforms to what users
>> request, and enforcement of the HIG, makes a HIG. Neither seem to be
>> the case with the KDE HIG.
>
> The HIG has nothing to do with user requests.  It is a technical document.  A
> specification.  It dictates consistency and patterns.  The HIG provides that in
> the few articles it has.  It doesn't do much since it is incomplete. Users
> don't have anything to do with kdelibs and they shouldn't have anything to do
> with the HIG.
>

The HIG seems to be what is preventing some innovative and useful
features to KDE:
http://bugs.kde.org/show_bug.cgi?id=155515
http://bugs.kde.org/show_bug.cgi?id=169043

In fact, there is an open bug about revising the HIG which is being ignored:
http://bugs.kde.org/show_bug.cgi?id=127298

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-� -ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه‍-و-ي
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-� -С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
ä-ö-ü-ß-Ä-Ö-Ü
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

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