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

List:       kde-usability
Subject:    Re: Show desktop behaviour
From:       Zak Jensen <coolguyzak () gmail ! com>
Date:       2005-09-30 0:09:22
Message-ID: 21bb44f30509291709h147a2546k9cae0b6bb7feddcc () mail ! gmail ! com
[Download RAW message or body]

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:
> > 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.

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).

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. Most
even use the desktop for practically everything. (My mother, for
instance, is one of those people who stores everything on her
desktop).

> 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.

I don't see them as workarounds. Then again, I am also a highly
technical user who "loves" the desktop metaphor. Personally, I don't
use SK. Mostly, this is because the information it provides I find
useless. I use folders, files, and launch icons quite a bit though.
(And, come the advent of plasma, I fully indend to go buck-wild).

As far as the mental model of the "show desktop" button is concerned,
I feel that the reason why this mental model doesn't exist is because
there is no real-world parallel to it. I don't typically "show my
desktop". More often, I'll "bring my digital clock to the front", in
essence, I create a larger mess by placing it on top of whatever is
covering it. The times when I do show my desktop, it is of a more
permanent affair.

However, given that I _could_ perform this action, I would expect it
to stay cleared while I interacted with it. When I was done, or if I
decided to start a new task, I would want it to return to how it was.
In other words, I'd want an intelligent desk. ;)

> > 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.

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.

> > >> 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.

Not true. If you have passive SK applets that you wish to monitor, you
will also need to show desktop. Or, what if your boss walks by and you
want to hide kgoldrunner from him... ;)

> 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.

> >  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?

Buttons have the goal to facilitate the goals and needs of a user.
(Well, maybe this is a goal or purpose of the button concept, but that
distinction is moot).

> > 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).

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.

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.

If a user shows the desktop then opens a folder or device on the
desktop, chances are they still want to work with the desktop, and so
the desktop should remain shown.

If a user selects an application from the start menu or restores an
application from the task bar, chances are they wanted to clear the
mess of windows off of their desktop. So, the desktop should remain
shown.

If a user selects the show desktop button again, chances are they were
contemplating their wallpaper. So, the desktop should restore itself.

If a user presses the show desktop button while there are one or more
windows displayed, chances are they want to show the desktop... so
minimize their windows.

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.

> > >> 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:

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.

> 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.

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 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.

"not similar" =/= "the only similarity"

You are attempting to apply a technical facility where one would be
both not needed and confusing. In addition, that would cluter the
desktop with 2 more (largely useless) buttons. Also, what would the
default state of your desktop be? What would it be if I minimized the
buttons by hand? Why should the various show desktop buttons display
different results than the desktop?

> > 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

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. There is a
plethora of discussion realted to this on kde-artists.org (search for
SymphonyOS discussion). And, while many (most?) people on kde-artists
are _not_ usability experts, they still manage to bring up the cons of
this approach.

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.

> 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]