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

List:       kde-usability
Subject:    Re: Show desktop behaviour
From:       Diego Moya <turingt () gmail ! com>
Date:       2005-09-30 13:13:25
Message-ID: 11ee04940509300613n13268142j () mail ! gmail ! com
[Download RAW message or body]

This is getting too big - I'll try to stick to the point.

On 30/09/05, Zak Jensen <coolguyzak@gmail.com> wrote:
> Woo. Alot to reply to. One of these such things is (of course) an
> alternate functionality of the show desktop button--or probably more
> to the point, the desktop as a whole. Anywho:
>
> On 9/29/05, Diego Moya <turingt@gmail.com> wrote:
> > On 29/09/05, seele@obso1337.org <seele@obso1337.org> wrote:
> Concerning the metaphor of a desktop: I think that it is still quite
> applicable. From my current desktop, I can collect documents into a
> bundle (a pile or a folder), I can store individual files or folders,
> I can start an application (picking up a pen to edit a document), and
> I have informative elements (a clock, video monitor (security desk),
> etc).

Two main problems with the metaphor are
1- the volumes of information handled nowadays with computers far
exceed those of a paper office. You can handle hundreds - even
thousands of files on a working session.

2- a computer desktop is way too small! A physical desktop is usually
1.5 meter wide x 0.8 m long. Screens are usually 19'' at most. The
physical equivalent of working on a 19'' desktop would be putting your
documents layered on top of the pen, the clock, and all the other
documents. Even if you have a magic button that instantly removes
everything, any task that involves moving things from one document to
other or to the desktop is a pain of if you have more than one or two
documents open at once. This is how I see the desktop metaphor working
today on computers. We should have magic tools much, much better that
simply a "remove everything" one.


>
> And, just like a real desk, my desktop can become cluttered, and
> occasionally needs to be cleaned. This real-world crossover seems to
> work very well. Very few people I know fail to see the parallel.

Furthermore, in the physical world when you want to archive things you
don't do it on the desktop! You move to a different area - a shelf or
a cabinet. With the file manager metaphor, you would take the physical
drawers out of the cabinet and resting them on the top of the table -
and then moving the folders in and out from the drawer to the desktop.


> There is an important distinction between the kicker and the
> desktop-at-large. While the desktop at large functions as a container
> for things, the kicker serves as a set of controls for task
> management. For instance, the task bar allows you to rapidly switch
> windows. The K-Menu allows you launch new applications, the clock &
> system tray allow you to peripherally monitor other tasks.
>
> If anything, Plasma will make the distinction even worse. Not only
> will it store icons which represent files on your computer, but it
> will also host mini-applications by default. Note that I don't find
> this to be an issue, but given your current stance on "the desktop
> should do 1 thing", you may not enjoy that.

I have mixed feelings. I'm not against the idea of a universal
container - quite contrarily, I feel that current the implementation
of the kicker panels + desktop is not universal enough, different
areas behave differently (which should not happen).

My concern is that the user can't really organize groups of functions
other than with their physical position on screen. There are no
folders for applets - containers that can be opened, hidden, tagged
and hierarchically nested. If your mother wants to organize different
groups of items, she'll have to put some the application launchers on
the top-left, the bank documents on the right, and the photos at the
bottom. And this is quite fragile - accidentally click on the "sort by
type" option and this classification is destroyed.

I thing the "piles" metaphor alleviates this problem (though it's
patented, and you can't hide and retrieve them easily).


> > If you actually want to DO something with the objects in the desktop
> > (say open the CD), the "show desktop" button doesn't accomplish a user
> > goal, is only an extra step in the task that solves your real goal .
>
> This, however, is true. It appears that this conversation stems from
> what someone wants to do with their desktop. If someone wants to
> interact with several components of their desktop, they want it to
> "minimize all". If they want to launch a new app or open something on
> their desktop, they want it to be a "temporarially hide all windows"
> thing.

My other concern is, if the desktop is that good, why can't you have
several of them? Virtual desktops don't qualify because they only
affect open windows. Both the desktop contents and the peripheral
tools are the same on all the virtual desktops.  Why can't the user
instead want to "hide the current browsing session" and then
"temporarily move to the account desktop" containing the calculator
applet, the spreadsheet and the banking files stored on (that) desktop
all visible? These are higher level tasks than simply "hide all
windows". The problem of the desktop metaphor is that it leads to too
low-level micro-window-management tasks. You can't really define
goal-oriented tasks easily.


> > Buttons don't have goals, users do. Buttons performs functions. Does
> > the function of the "show desktop" button help the user to accomplish
> > her goals? If not, what other functions could it have or what other
> > widgets could we design?
>
> Buttons have the goal to facilitate the goals and needs of a user.

This is widget-oriented design, not user-oriented design. While you
need some of the former if you're designing universal-purpose tools,
you should never . It's better to have several flexible but
specific-purpose tools available that a single tool with facilitates
too low-level goals.


> Well, if we monitor certain actions of a user, and we make a few
> assumptions, we can create a button that helps users instead of
> getting in their way. What do I mean by this? Make the button do
> different things based on the input that it recieves from the
> environment.

This probably is bad design - having a tool that does different things
is the definition of "inconsistent". How will the user learn why
sometimes the previous state is restored and other times it isn't?


> If a user shows the desktop then opens a file/app, chances are they
> want to edit/run the file--hence, it is safe to restore the prevous
> workspace.

How sure are you that this is safe? You could equally show an animated
paperclip saying "It looks like you're editing a file" ;-)


> The assumptions made above are those that I would expect. Actual
> testing should occur to see how user workflows work in each of the
> situations I described above. My real point was to elaborate an
> "intelligent desktop" scheme, where the desktop tries to figure out
> what the user was doing, and accomodate them.


Do you know the implications of trying to make an "intelligent" tool?
Guessing user intent is really, really, really, no I mean really
difficult (I know because this is what I do for my PhD, and it's no
near to be a solved problem). You can make intelligent guesses as long
as 1) the tool always behave the same given the same input, 2) you put
your guesses as default values, 3) the user can easily override them.
Otherwise the frequent "false positives" quickly turn into pain and
hate.

An alternative (and frequently better) approach is - don't guess at
all, provide all the possibilities to the user and let her make the
choice. This is what SymphonyOS does really well.


> IMHO, the problem is that we are too afraid of confusing users, and so
> we hobble our designs with largely unjustified constraints. That's
> just one opinon out of many though.

Maybe, but that's what user testing is for. Just design a prototype
and throw it in front of them - this will validate or reject your
carefully crafted guesses.

> > Unless you try to define unambiguous items, one for each task, instead
> > of a single ambiguous widget that doesn't solve any task well. My
> > suggestions for the "show desktop" button would be:
....
> This seems incredably confusing to me. Why add a new menu with a
> history that is bound to become unusable? What if I have 10 windows
> open on my computer? Will it list all of them in the drop-down
> history? And their status?

I haven't explained well - I was trying to join the "virtual desktops"
idea and the "show desktop" tool into a single, simple widget based on
the browser metaphor. My suggestion is similar in spirit, but not the
same as this one:

http://kde-artists.org/main/component/option,com_smf/Itemid,48/expv,0/topic,361.0

The goals supported should be:
1) define high-level tasks
2) provide for quick context switching between those several different tasks
3) moving one or more current windows away (like "minimize") but
putting it in an accessible point so that they can be instantly
recovered (a finer grained version of the "show desktop" behavior).

This could be accomplished by treating context switching as browsing
through an infinite flow of different "virtual desktops",
automatically created when the user does window management. Each
"automatic desktop" would contain the state of several windows at
once, so that any previous state could be recovered instantly and
through an explicit user order - instead of the automatic recovery
currently implemented (which sometimes works, and sometimes don't).
You could even have a "back" button to move one by one through those
previous "automatic desktop" states.



> People bring up Mezzo quite often on several of the usablity boards
> and mailing lists I frequent... It does make the desktop simple and
> easy to interact with, however it removes the reason why people use
> KDE. It is neither powerful nor particularly configurable.

Maybe the SymphonyOS implementation isn't configurable, but a
Plasma-based one would certainly be. Users could add and mix any tool
that they wanted anywhere, thus configuring it to their needs. Mezzo
would just be the default configuration, a good one for beginners to
stay with.


> Does this mean that I think such a thing should not be possible to do
> in KDE? Of course not! But is it usable enough to make it a default?
> Not in my opinion.

Why not? I've tried to find that discussion to read those cons, and
failed. Do you have the links?
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

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