[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-29 22:56:54
Message-ID: 11ee049405092915562e44d5fa () mail ! gmail ! com
[Download RAW message or body]

On 29/09/05, seele@obso1337.org <seele@obso1337.org> wrote:
> the problem with this is that no one is really sure what mental model a
> user has when they 'show desktop', or if they use that model every time
> they use that button.

Mental models should be related to the functions for which the
interface element is designed. The original intended model was that
of, well, a desktop: you put things on it. So it was intended mainly
as a folder, the most frequently accessed one. Problem is that this
only worked for a very small amount of files (10, 20) and just one or
two applications open at a time.

Current use of computers make this metaphor impractical, and it should
be deprecated; a new model should be developed. Actually this is being
done by all the major desktop environments - panels, applets, virtual
desktops, dashboards, Exposé, they are all workarounds to the fact
that the desktop metaphor is 20 years past its valid lifespan. It's no
surprise that no one is really sure what the correct mental model
should be.


> yes, but kicker doesnt get hidden when you show the desktop.  also, the
> metaphor of the desktop is usually defined as the 'work space' and
> controls (re: kicker) arnt always a part of a users mental model of what
> the 'desktop' is.

I'm not sure what you're trying to say. My point was that the desktop
background area (what is shown when you press "show desktop") is
overloaded with a mixture of unrelated functions. So either the
desktop or the peripheral controls/panel are redundant, which is
probably bad (mainly because the interaction with the desktop is
different to that with the peripheral panels even though they serve
the same functions). I hope the Plasma project will solve that and
panels and desktop will behave the same.


> >> Even for me it's hard to define what I'd "expect" it to do.
> > That's because you don't know for what it will be used, and that's
> > because the desktop serves for too much unrelated goals.
>
> i think the only goal here is to show the desktop

I can't agree to that. Showing the desktop is only a goal if you want
to contemplate the desktop background image.

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 .


>  and we don't know how to
> restore windows when an action is performed.  the desktop can facilitate
> many activities, but the 'show desktop' button has one goal:

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?

> desktop.  the issue we cant seem to determine is if the working space
> should be restored after the desktop is shown.

It should be restored if the user goals depend on the previously open
windows. It shouldn't be restored when the user goals are related to a
completely new task. Simple, isn't it? (But it raises the question:
how do we know? This is why user interface design is difficult).


> as aaron said, it used to act as previously mentioned would be ideal, and
> we had a bunch of bugs filed on it.  it was changed, and people still are
> not happy.

That's because neither option solves all situations.


>
> >> So, in my view the feature itself is hard to define unambiguously and
> >> thus
> >> implement. Hence you'll get bugs whatever you do :/

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:

1) for new designs (i.e. KDE4), get rid of it completely. Turn to a
"layers" approach, one layer for each task.

2) for legacy support (KDE3 as long as it is actively developed) treat
"show desktop" as transient, the same way that the K-menu is
transient: it only performs its function until you select a command
from it. So keep the "all windows restored" behavior. Forget the
"toggle" metaphor (but keep reading).

3) for improved functionality, keep a history of the previous
configurations of minimized and shown windows. Think of this scenario:
- You have open windows for Kmail, Konqueror and Konsole.
- Press "show desktop". All windows are hidden.
- Reopen Konqueror either through the taskbar or with Alt+Tab. This
actually creates a new configuration of windows; the old one gets
pushed down one place in history.

Through a dropdown list near to the "show desktop" button you could
reselect either the previous "Kmail, Konqueror and Konsole"
configuration or the "Konqueror only" configuration, and switch back
and forth between them as many times as you wish.



>
> > I would prefer to refactor the goals that the desktop solve,
> > separating them into several different areas - instead of only one
> > "show desktop" button, you would have one to show frequently used
> > files, another for launching applications and yet another one for
> > showing the Superkaramba widgets.
>
> i dont think adding more buttons to do different but similar modifications
> to the desktop is a good solution.
>

They are not similar - they serve to completely different functions.
The only similarity is that all them temporarily hide the open windows
- but it can be seen as different layers on top of the desktop instead
of a single layer at the background.

> also keep in mind that the issues we discuss on this list usually deals
> with "default" settings of kde, which means the Average user (re: Not
> power users).

Have you seen the Mezzo desktop mockups? It is specially tailored to
average & beginner users:
http://homepage.mac.com/jasonspisak/Mezzo

This design should work well because it simplify a complex object -the
desktop, which provides many unrelated functions- by slicing its
functions in different parts of the screen.
_______________________________________________
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]