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

List:       kde-usability
Subject:    Re: K-Menu/Xandros Launch
From:       Gav Wood <gav () kde ! org>
Date:       2002-09-23 10:54:45
[Download RAW message or body]

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

On Saturday 21 September 2002 8:10 pm, Waldo Bastian wrote:
> On Saturday 21 September 2002 01:06 am, Michael E. Peligro wrote:
> > I notice a rather uncomfortable "finding" in the paragraph. "People work
> > with applications"? I personally prefer Apple's findings that "People
> > work with documents (or types of files)". Like, "my mp3 file, my graphic
> > files, my pictures, my movies, my documents". "File-centric", rather than
> > "Application-Centric" is more "real-world" and easy-to-relate. Examples
> > of user conversations: "I have a lot of mp3 files in that computer. A lot
> > more pictures" I have a text document, etc.." Users almost and always
> > speak of files as products of their work. Apps are only means to this
> > end.

to be fair, i dont think there can be too much argument over whether or not 
people prefer document-centricity or application-centricity *

let us compare the shambles of windows 3.1 to mac os (and windows 95, for that 
matter). windows 3.1 provided only applications to the user as standard - the 
user actually had to open the "file manager" application before he could see 
any files. the desktop could not show files and the whole system was 
completely anti-document-orientated.

mac os and win95 changed this by giving finder/explorer to the user as 
standard. the user could now keep files (virtual-things) on the desktop. they 
could move them around, copy them and view/edit them, and they could do all 
this without having do something indirect and non-obvious, such as opening an 
application.

i'm sure there must be a zillion studies from ms/apple showing how win95/macos 
was better than win3.1. my mother would certainly agree ;)

> When creating the current style guide we played with the idea that "people
> work with documents". While this is true, it is not true to the extent that
> people don't care about applications as long as "applications" are visible
> and have an impact on the user experience.
>
> An important point: editing two files by clicking on the first document,
> closing the document, clicking on the second document and then closing the
> second document tends to be a more cumbersome way of doing things than
> opening the first document, closing the first document but not the
> application, opening the second document in the still open application and
> then closing the application.

clicking one one icon, closing and clicking on another is probably the most 
obvious and intuitive (and, for that matter ui-effective) way to open and 
edit two seperate files for a bog-standard "i dont care how anything works, 
just let me get the job done" user. *

for that matter i myself, being a more experienced user still like the 
simplicity and effectiveness it provides. 

therefore we should assume that this methodology and mind-set should be 
supported in a good, intuitive and effective interface (and the kde style 
guide does agree with this to a substantial degree).

that said:

> Depending on the application, starting an application takes a very
> noticible time and disrupts the workflow of the user, so being able to
> reuse the application brings real benefits to the user.

yes, it does and clearly this must be addressed, however it must be 
acknowledged that the application-centric methodology is a quick fix to this: 
it brings with it more fundamental problems * and therefore should not be 
propelled to the user as "the correct way" to do things.

this supports the idea that application startup times should really be 
addressed as a bug of the interface, since they prevent the better 
methodology from being used properly.

a better quick fix to this problem might therefore be to develop a system of 
keeping basic and frequently used programs running silently even when no 
documents are open. this would cure perceived "startup times" (though of 
course there would be far fewer real startups). this way the user would still 
be able to use the better methodology and yet not suffer speed problems.

> In the above example this document-oriented way of working works a lot
> better when applications load instantly (e.g. within 0.2 sec) but
> unfortunately that is not the reality of today. (Although it is certainly a
> goal)

yes indeed.

> Taking that reality into account the style guide acknowledged that there is
> both room for a document oriented way of working and an application
> oriented way of working. The document oriented way of working is
> represented by the SDI approach which is strongly advocated by KDE and
> which has strong architectural support in for example KParts.

"reality" should be accounted for only as long as it cannot be changed. with 
correct measures and design in place it need not neccessarily be the reality, 
and as such should not detract from any fundamental interface design 
principles.

gav

(*)
people can visualise the files as actual bits of paper and thus have little 
trouble drawing a correct and effective abstract.

applications are also abstactions of real things, but such things can often be 
rather more far fetched and such abstractions do not always fit properly. 
e.g. a word processor's parallel could be a pen, which works fine until i 
wonder how to write an email - i would use a pen in the actual world, yet i 
would not use a word processor in the virtual world.

- -- 
Gav Wood <gav@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9jvL4dci4J4649rgRAo99AKDkI1JHJE+e9TnjyEllGLcWKAw9NwCguQmS
sLdrh9ZYstezifgyGHd8z6g=
=5wv7
-----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]