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

List:       kde-usability
Subject:    Re: Usability Strategy Discussion
From:       Robert Watkins <robert_maria () yahoo ! com>
Date:       2002-07-02 11:28:40
[Download RAW message or body]

I don't believe that OSS has proved structured
development processes 'largely wrong'. My hunch
is that if  you look at time spent on a project
that had a SDLC followed and one that used
OSS-type processes, you'd find that the
structured process was much more efficient. I
believe that you get to the end point sooner,
rather than later because you spend much less
time re-designing and patching bad design and
more time designing.

As for the uniqueness of KDE, I can't disagree.


>> Exactly! The $64K question is "How do you
marry a
>> relatively loose process with a relatively
formal
>> process and still have a workable result?"

>by a combination of buy-in from the existing
>developers and effort put in by
>those who care about it. fail on either count
>and it won't work very well at
>all.
Buy-in is the single most difficult activity to
succeed in. It's a combination of timing, context
and substance that have to occur in the right
sequence. It's typically associated with a
'wake-up' call. 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, a strong leader with a
vision making a call to action, etc. But with
such a loosely organized effort involved with
each project, it's difficult for me to come up
with any ideas. 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.

>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.

>One of the problems
>here is that most developers
>work in their spare time and add features when
>their time permits it (and
>they are in the right mood). But a discussion on
>kde-usability can take
>days...
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.

>BTW it would also be helpful when developers who
>ask on kde-usability for
>advice could actually get a few answers :)
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.

>You have to teach people the importance of the
>formal process, and when y>ou do 
>that, people who care will use a loose process
in
>a formal manner.
That assumes that a formal process is called for.
This is almost a chicken-and-egg scenario where
you need a formal process to do Usability, but
without wanting Usability, a formal process may
be unnecessary. I think questioning whether or
not there is a place for Usability in this
culture is still appropriate.

>In other words, applied specifically to
>usability, you teach someone what> good 
>usability is, why it's important, how you can
>achieve good usability, and> 
>then you have people thinking in terms of
>usability when they start layin>g 
>out components.
You don't teach someone about 'good Usability'
like you teach someone about threads. Good
Usability is gained by measuring a design against
a list of requirements with your target user
group. KDE, OSS, etc. have never consistently
defined who the target user group is and then
work with them to create a list of requirements.


>One strong way to do this is to let peple on
>KDE-devel and other -devel l>ists 
>know that a usability project exists in the
>first
>place.  The next step i>s to 
>take the existing documentation (like the KDE
>style guidelines) and updat>e it 
>to make something that is easily followed.
Again, this is not the point. A styleguide is not
a replacement for Usability. It does help with
consistency and branding, but that's about it. I
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.

>As the usability team, we have a few
>responsibilities here:
>
>1) We identify WHAT exactly good usability is,
>and inform people of the 
>general "principles" of good usability, and from
>those principles, we bui>ld 
>more strict, more formal guidelines.  (The
>styleguides for example are a 
>starting point; an extension would be
>"recommendations" such as informing> 
>people that they shouldn't combine slider bars
>and scrollbox widgets, or 
>encouraging that people use tabs properly, etc.)
You started out good, but then went downhill.
Instead of providing answers, we need to provide
a process for finding the answers. A good design
today will not necessarily be a good design next
year, but the process for finding out what is a
good design will essentially be unchanged.

>3) We identify problems in existing user
>interfaces.  When we identify th>em, 
>we find out why they don't conform to the
>guidelines.  Ideally, every 
>usability problem would have a point in the
>guideline to follow.  Of cour>se 
>we are NOT in an ideal environment.
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.

>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.

>5) We act as consultants to how to better
>implement user interfaces.  If 
>people are interested in usability, they should
>be able to get answers on> how 
>to improve their dialog, rather than having to
>follow philosophical argum>ents 
>about why QToolTip is superior to QTextTip (as a
>fake example).
Again, the expectations are not that Usability
provides answers, but rather a process to get to
a point where a system acts as expected.
Philosophy only gets you so far, you need to back
it up with data.

One of the key components to making Usability a
success is to identify who the users are. The
answer 'Everybody' is not good enough. My Grandma
doesn't even own a computer, so she shouldn't be
considered a target user. My mom doesn't use
Linux, so she's not necessarily a target user.

It's also useful to think of types of users.
(Developer, Early Adopter, Inexperienced, etc.)
These types are used when gathering data to make
sure that you have a representative sample group
when you start to gather data.

I did find some readings on Usability and OSS
that seem to be worthy of reading.
http://www.comp.lancs.ac.uk/computing/users/dmn/docs/oss.html
http://mpt.phrasewise.com/2002/04/13
http://mpt.phrasewise.com/discuss/msgReader$182
(BTW, I didn't use 'suck' in my search, honest :)
)

Robert

====--------------------------------------------------

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
_______________________________________________
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]