Re: [Evolution-hackers] PIM application suite



On Tue, 2004-04-20 at 19:05, Tristan O'Tierney wrote:
> I have taken courses in usability.  I haven't done
> usability tests on evolution, but I have no need to
> because my basis for comparison has done far more
> usability testing than you: Apple and Microsoft.

Microsoft has Outlook, which is pretty much what Evolution mimics. This
is what the market expects and has grown to understand and use. There's
a lot to say for that.

>   I
> don't claim to be an expert.  It is however a hobby,
> and one that I spend a lot of time developing and
> studying up on.  If I were saying that I made my
> usability assumptions up out of thin air, of course
> that would leave me with little to argue about. 
> However my proposal to break up the interface is based
> on these reasons:
> 
> 1) Gnome software trends
> 
> For one moment, I'd like you to consider what other
> gnome apps that are close to the gnome-tradition of
> simple design follow the design of evolution.  Taking
> a brief look at my Gnome 2.6 menus shows this:
> Browser - epiphany
> Chat - gaim
> Movies - totem
> Music - rhythmbox
> Files - nautilus
> Documents - abiword
> Spreadsheets - gnumeric
> 
> just to name a few. 

you are comparing apples to oranges here. these comparisons are
irrelevant.

>  I could go in more detail, but I
> think you get the point.  each one of these apps is
> responsible for one task.  that is not typically a
> gnome thing, every system should strive for this.  is
> it a HIG requirement that each app have a set goal? i
> do not know this for sure, but you cannot deny that
> it's a software trend. 
> 
> 2) Previous usability testing done by large
> corporations (Apple and Microsoft)
> 
> You cannot deny the testing of such large companies as
> these.  They obviously put in millions of dollars of
> usability testing. However the difference is seen once
> you look closer.  Microsoft's design (of which
> evolution mimics) is Outlook.  Apple's design, is
> iCal, Addressbook, and Mail (of which kcalendar,
> kontact, kmail mimic component wise).

Apparently you haven't seen the direction that KDE is going with their
Kontact application, which is to say that they are putting them all
under a single window :-)

see here: http://www.kontact.org

KMail, KOrganiser, etc were originally separate applications because
they were developed independently, not due to any usability designs.

>   We can debate
> all day which OS is more usable, but most credited
> interface designers and usability experts will agree
> it's Mac OS.  Apple is known for being better at
> user-oriented design.

...and Microsoft has the market share which means that nearly all users
are familiar with their software - making software similar in look/feel
to software that the user is already familiar with goes a long way
toward helping them to transition to the new software package.

so usable or not, it's the the way to get market share.

part of usability is defining who your users are, and in our case - it
is mostly ex-Outlook (and similar) users.


Food for thought: why are keyboards still using the QWERTY layout? Is it
really more intuitive? Or is it just what people are used to?

> 
> 3) Basic principals of human factors and interface
> design
> 
> One of the things they make you do in usability 101 is
> design a clock, radio, phone, alarm, and cd player all
> in one physical device.  It's meant as an example more
> than anything, but what it shows is obvious -- it
> cannot be done well.  Related functions are not the
> same as differing functions.  When I go to burn a CD
> in iTunes, I don't have to convert all my iTunes mp3s
> to wave files, then import the wave files into Roxio
> Toast, then burn them as an audio CD. iTunes should
> just manage my music, and manage it well.  However it
> should also include related functionality that does
> not all-encompass another application if such related
> functionality enhances the usability of the
> application but at the same time does not serve to
> completely replace the functionality of another
> application.  Can iTunes act as a complete replacement
> for Roxio? no. That is a clear distinction from the
> design of Evolution.  Evolution treats any of the
> components as subfunctions -- they are all totally
> separate modes.  Calendar mode is completely different
> from Contacts mode.  Contacts is in no way a subset or
> useful subfunction of calendars.  Calendars may
> reference contacts, but a calendars program does not
> need a full-fledged contacts system within it.  The
> way Mac OS makes this distinction is apparent whenever
> you add a buddy in iChat.  It asks you to provide the
> buddy's real name by showing a standardized contacts
> widget (http://otierney.net/images/contacts.pdf).
> 
> 4) User expectations and their environment
> 
> You claim that users want all their PIM features in
> one collective space, and don't want to fool with
> system menus.  What you're assuming is that the user
> is using only Linux, with only Gnome, and that said
> user does not have direct quick launch icons on a
> taskbar.  If I had quick launch icons for my address
> book, calendar, and mail all separate that would be a
> lot faster than going through the system menu.  Many
> users do this, and OS X even defaults to having a
> shortcut for all 3 of these applications (since as
> another rule of interface design: most users never
> change the defaults).  Lets change the situation
> around a bit and say the user is running evolution in
> Mac OS X. This is not far fetched, as it can be done. 
> With 10.3's new expose feature, having individual
> windows per-application is actually a benefit.  By
> using fittz law the user can hit the edge of the
> screen and zoom all windows out, and then click the
> respective window they want to acquire.  This is going
> to be faster than acquiring the individual evolution
> window, then acquiring the sub-component (Say the
> contacts button) to finally get to a list of contacts.
>  You're making too many assumptions about what the
> user wants, and their respective environment.

It would be trivial for a distro to package their GNOME Desktop to have
multiple launchers (menu or otherwise) to be able to launch a specific
Evolution component, one window per each. You don't have to make
separate applications or executables to do this like you keep suggesting
(which, by your own admission, is a bad usability decision since users
don't use the console anyway)

> 
> 5) Defaults
> 
> In conclusion, I think the most important argument is
> this: users don't change defaults.

hence the distro's responsibility.

>   Some do, but for
> many just making a mail account is a feat.  It's nice
> that i now know how to split it up into individual
> applications, but until this is the default it is
> quite useless to all but a select few.

you're wrong as I explained above. Plus there are quite a few users (a
majority in fact) that will expect a groupware suite to be a single
application rather than a collection of multiple independent programs.

>  the select few
> who actually care enough about usability to find and
> make such a change are the very ones who benefit the
> least from it. Few people will ever touch the console,
> let alone "man evolution" or "evolution --help".  It
> may be in the help file, and at least I hope it is. 
> If you want to have a option, rather, it should be to
> include them all in one application (as it is
> currently).  This way you get the added usability from
> splitting up the functions, and the outlook-like users
> can have an option to enable mode-switching in all
> applications in the preferences, or someplace easily
> found (a console switch is unacceptable).

you call this usable? :-)

having to have the vast majority of users enable a checkbox to make
Evolution act like the software they've been using for years and have
come to expect?

anyways. I consider this "End of Thread". There's no use discussing this
further. It's clear no one is going to change their mind, so we might as
well stop wasting bandwidth.

Jeff





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]