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

List:       kde-usability
Subject:    Re: Usability Strategy Discussion
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-07-02 15:47:40
[Download RAW message or body]

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

On Tuesday 02 July 2002 05:28, Robert Watkins wrote:
> I don't believe that OSS has proved structured
> development processes 'largely wrong'. My hunch

no, but it proved it unecessary for many/most situations.

> Buy-in is the single most difficult activity to
> succeed in.

you do realize that OSS development is largely a process of buy-in, right?

> It's typically associated with a
> 'wake-up' call.

OSS is based on positive engergy, not negative energy. fear of loss is far 
less useful than promise of gain in these projects (think about the 
motivators involved)

> This could take the form of a
> report that Gnome is 'better' than KDE by a
> respected group or a full usability study by a
> professional organization,

yeah, stirring up the GNOME vs KDE flames would be a great way to make friends 
and motivate people. please. 

we've all had enough of such braindamaged attempts at manipulation from people 
"on the outside" through badmouthing and "you suck" mantras.

> What do you think about having a
> "KDE Usability Labs Certification" program. We
> could assign Silver, Gold, Platinum levels based
> on formal Usability tests. The devil is in the
> details, but it may provide the right incentive
> to the developers.

it would be an interesting idea and a good addendum to usability reports. they 
would need to be revisited during the devel of the program (at least every 
public release), but that needs to happen w/the usability reports anyways.

btw, where are these of ours labs again? ;-)

> >What you could do is to convince developers to
> >consult kde-usability before
> >implementing new features.
>
> I think it's more of a change in culture to
> incorporate Usability techniques as an integral
> part of the process. The KDE-Usability site
> shouldn't be seen as an answer site. There are no
> 'right' answers that can be documented that work
> for all cases.

i don't think he was referring to the web site, but the project itself (e.g. 
the people involved). and yes, we need to be able to perform much of the 
usability process for and with the developers.

> Sure a discussion can take days, but there's lots
> of research out there that says up-front planning
> can save loads of time when delivering a quality
> product.

and lots that says the opposite. it depends on what you are doing, but 
exhaustive up front planning tends to be a waste of resources when taken to 
the degree you seem to think it should be. planning is good, over-planning is 
a waste of time.

take a look at the actual complexity involved in your average actual KDE 
application and think about it for a bit.

> I think the expectations of having Usability
> professionals availabe are not accurate. This is
> not a business of saying use this widget over
> that, but rather a process on how you can find
> out which is better within the context of the
> application in question.

and that is why we need usability people, to help walk that process. welcome 
to the world of OSS where you get your hands dirty and ivory towers are few 
and far between.

> think we need to change our approach to this and
> focus on how to determine if a design is good or
> not, rather than use cut-n-paste screens.

this whole time i've been wasting my efforts determing if a screen is good or 
not when i should've really been asking how to do so? sorry, my mistake.

</sarcasm>

> When we idendtify problems, they should be backed
> up by data. The data could be that a function is
> implemented outside the list of requirements or
> users are measureable unable to use the feature
> as intended.

agreed

> >4) We fix problems in existing user interfaces.
>
> I think a better way of saying this is. "Suggest
> solutions, evaluate those solutions until one
> works as expected and them work to implement"
> Having a person wear both Usability and Developer
> hats, you run the risk of competing goals, speed
> over quality.

unless that develper is aiming for usability. remember that we don't have 
deadlines strapped to the back of our heads like guns just waiting to go off. 
this is open source devel, not "gotta make fall marketing campaign" devel

btw, implying to developers that they value speed over quality is a great way 
to get laughed at and then ignored. we already have enough of a challenge 
helping people to take usability serious.


in all: just as OSS reinvented and in many ways reinvigorated the typical 
development process through largely reinventing it, we may need to do similar 
things for usability. we can't simply take the square peg of corporate 
deadline report writing usability chin scratching and expect it to fit the 
round hole of self-propelled collaberative open development. if you have no 
interest in adapting traditional usability mechanisms to OSS (and only wish 
to do the opposite: adapt OSS to traditionl usability) you will fail. 

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Icsc1rcusafx20MRAk8HAJ98yzCTPMjsZSzy2DUuyu/RXhnXVACeO1Tg
be4jynW3GhTwPmcANDx2FNg=
=0Czy
-----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]