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

List:       kmail-devel
Subject:    Re: $%^#%&^@%&@% [long, rambling]
From:       Carsten Burghardt <cb () magic-shop ! de>
Date:       2002-02-05 7:36:33
[Download RAW message or body]

On Monday 04 February 2002 18:38, Seth Kurtzberg wrote:
> Rob makes some good points, about which I have a few comments.  (I have
> LOTs of experience working with non-technical users and user interfaces.)

You should sell this list ;-)
Honestly, does something like this list exists as a general rule on e.g. 
www.kde.org?

> 1.  It is extremely difficult to design a user interface that will be
> universally well received.  For example, I find it immensely frustrating to
> work on a Mac (not the new O/S, which I haven't tried, but the older Mac
> OS). Yet there are people who love it.  Which brings up a point.  The
> environment in which kmail is running, because it is intelligently layered
> and allows a very clean separation between the interface and the engine
> behind the interface, makes it very easy to implement interface variations.
>  What I'm suggesting is that, rather than making one interface that will
> satisfy everyone from the least to the most sophisticated user, it may be
> more tractable to build different interfaces, or at least substantial
> interface variations.  (The comment about an "advanced" tab for
> configuration is thinking along this same path, I believe.)
>
> 2.  I have worked extensively with a variety of users over many years, and
> I've found that we tend to make certain mistakes when designed user
> interfaces for the non-technical user.  Here is a short list:
>
> (1)  The user's first impression of an interface is often modified after
> only a short period of use.
>
> (2)  There is a fear factor with most users, but that factor dissipates
> quite quickly if the interface is well defined.  That is, they will often
> react negatively to something the first time they see it, but they will
> change their minds after using it for a while.
>
> (3)  They are smarter than you might think.  The fear factor makes them
> appear to be much less capable then they turn out to be.  So, what you need
> is not a Mickey Mouse interface; rather you need a good interface and
> outstanding training materials.
>
> (4)  Stability is as important to them as other factors.  This is where
> kmail ( and KDE in general) (IMHO) has a huge advantage over other
> implementations. To me it is clearly the most stable of the easy to use
> environments.  And it is, in fact, easy to use.
>
> (5)  Jargon scares them; not what the jargon means, the jargon itself.  Use
> ordinary language whenever possible.
>
> (6)  There is very little difference, when you dig deeply, between what the
> sophisticated user wants and what the unsophisticated user wants.  In the
> kmail environment, where sophisticated command line tools can be used, the
> sophisticated user is more than happy to use a (relatively) simple
> interface most of the time.
>
> (7)  The non-technical user is willing to deal with exceptional cases
> (which require workarounds) as long as the software works as advertised,
> and is easy to use, most of the time.
>
> (8)  Even people who specialize in user interfaces usually get it wrong.
> They pile on more and more features, sometimes short changing stability,
> which is NOT what the end user wants.
>
> (9) Consistency is a key factor.  It is important that, for example, the
> user interface for kword and kmail do similar things in similar ways; an
> improvement in one that creates an inconsistency will not be appreciated.
>
> (10)  You don't need an elaborate setup to get feedback from users, and you
> don't need a large number of users.  In my experience, you'll get the same
> results working with a group of 5 or working with a group of 50.
>
> Specifically with regard to kmail, here are some reactions from my users.
>
> (1)  Do spell checking as part of the send process; don't make the user
> remember to run the spell checker.
>
> (2)  When configured for plain text (prefer HTML off), give the user a
> button on the tool bar to bring up the HTML mail in a browser.  (This may
> have been addressed; I'm using a version of kmail that is a few months
> old.)
>
> (3)  When you double click on a message, bring up a window with the
> appropriate tool bars.  That is, when you double click, the window created
> should look like the reply window, with the send button replaced by a reply
> button.
>
> On Monday 04 February 2002 09:47, Rob Walker wrote:
> > On Monday 04 February 2002 05:01, Ingo Klöcker wrote:
> > > About creation of non-existant folders, why not simply add a New_folder
> > > button next to the target folder selection in the config dialog. I
> >
> > I have yet to believe that all users will understand what "creating a
> > folder" does, why they need to do it, and that it is the first step one
> > must do before reading email.  Did I have to create my "inbox" folder?
> > (and it doesn't even point to a file called "inbox")
> >
> > I think that this whole UI discussion is an interesting view on who we
> > are and where we come from as a whole.  It also shows that we are a bunch
> > of smart people who have been pretty much set out to sea with one oar on
> > this design stuff.  Only one of us has even claimed the first bit of
> > experience with any I training.
> >
> > We know how _we_ like things, but we are not the primary audience.  I
> > don't even know who the primary audience _is_.  I don't know the goals of
> > this app (kmail), who its' intended audience is, what features will be
> > implemented, which ones are way too much functionality (I guess elisp
> > interpretation is a bit much :-), and which ones are way under the bar
> > (iMail seems a bit simplistic to me, even if not to the UI people at
> > Apple).
> >
> > Jordan Hubbard (a friend works for him at Apple) puts it in terms of a
> > Bicycle shop vs. a Nuclear power plant.  If someone is putting up a
> > Nuclear power plant the next canyon over, everyone assumes that smart
> > people are on it, and that they have done all of the right things, and
> > that no mistakes will be made.  There are public hearings, the public is
> > easily satisfied, and everyone doesn't say much.  However, let someone
> > propose putting up a bicycle shop the next street over.  Everyone and
> > their dog will have comments and input, and will try to push and pull the
> > whole thing this way and that way. This is because a bicycle shop is easy
> > for everyone to get their heads around, and everyone likes to have their
> > voice heard.
> >
> > Apply this to kmail (or knode, or any of these apps which are being
> > worked on).  We all say, "hey, it is just UI stuff, I am a User, I use an
> > Interface, I can do UI design work.  Anyone can."  Or something like this
> > might be said, "I met some UI deisgn people one time, they had an IQ a
> > whole 30 points lower than mine, so I _must_ be able to do their easy
> > work, and faster and better, too."  So we don't put any actual project
> > time into mockups, into sitting down with users, defining our target
> > audience, soliciting UI feedback from them, watching them work with the
> > early designs, seeing how they will work with the product.
> >
> > We need to face a few facts.  The first one is that half of the world is
> > below average.  The second one is that the people on this list are
> > probably in the top 5% of everyone.  That puts all of us over 45 points
> > away from half of our user base!  (That is, if you agree with me that
> > World Domination is the goal here.)  Is there any surprise that we don't
> > work the same way they do?  Do they even understand what a directory is? 
> > The term has become 'folder' over the last few years, and now we are
> > using 'folder' to mean 'mail file', too.
> >
> > I think that all of this combines to make Open Source desktop programming
> > work (KDE) very difficult and frustrating.  We don't have a usability
> > lab. We don't have people who will come in and be videotaped while using
> > the application.  None of this is intentional, and I don't know where we
> > can change it without a serious infusion of money
> >
> > I don't know the solution here, unless it is to release the UI work to UI
> > design people, and keep the coding on the back end to smart people like
> > you all.  But I don't think that this is a viable option at this point. 
> > Since we don't have people who are trained on UI here, what do we do?  I
> > don't know. I suppse we continue working as best we can.  :-)
> >
> > > don't see the need for automatic folder creation. If the user wants to
> > > move messages to a folder he could simply create it at once. Why should
> > > folder creation be delayed? I know that procmail does it this way. But
> > > procmail is no GUI app.
> >
> > why should the user have to even think about creating a folder?  Why do
> > they need to manage folders?  I don't think users use folders, I think
> > that they read emails, and store then places.  The fact that these places
> > are folders is a side effect, and its' existence and interaction needs
> > should be minimized.
> >
> > > IMO invalid filters should simply be ignored and there should be a
> > > warning on program start (maybe with the buttons Ignore and Configure).
> > > In the filter dialog invalid filter should be marked and then the user
> > > can simply delete those invalid filters which he now longer needs.
> > >
> > > I'm against your idea to add options like
> > >
> > > > a) Enable automatically
> > > > b) Ask user
> > > > c) Ignore
> > >
> > > to the filter config dialog. This will only clutter the config dialog
> > > with IMO unnecessary options and confuse the average user.
> >
> > I find it interesting how we all like to invoke "the average user" every
> > time we need to make a point.  I do it all the time.  None of us want to
> > say, "I am the average user", and I bet none of us are the average user.
> > However, the closest any of us come to knowing an "AU" is our co-workers
> > or our spouses, or someone who we hang out with.
> >
> > rob
> > _______________________________________________
> > kmail Developers mailing list
> > kmail@mail.kde.org
> > http://mail.kde.org/mailman/listinfo/kmail
-- 
Carsten Burghardt
email: cb@magic-shop.de
WWW: http://www.magic-shop.de
PGP: http://www.magic-shop.de/Carsten_Burghardt.asc

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