[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-10-03 0:01:45
Message-ID: 11ee04940510021701h18ab7bc8g () mail ! gmail ! com
[Download RAW message or body]

On 30/09/05, Zak Jensen <coolguyzak@gmail.com> wrote:
> On 9/30/05, Diego Moya <turingt@gmail.com> wrote:
> > 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.
>
> Correct, but most studies (that I have seen) suggest that users only
> look directly at 1 or 2 documents at a time (generally). Whether this
> is because of the constraints of the desktop, or the way people handle
> multitasking is debatable. So, while I may handle 100 different files
> in a session, I won't need to worry about dealing with all of them at
> once.

Not for using them, but you need a way to organize them for retrieval.
And some files will be left on the desktop for long term use, not just
for the current session.



> Well, the concept of a cabinet is 3-dimensional. In a sense, one is
> extending a "desktop layer" which is external to the working surface.
> Since we only have 2 dimensions, and the working surface is the only
> thing we can display on, we cannot yet apply this to the desktop
> metaphor. Regardless of the mechanism we attempt to create, the
> "cabinet" will need to be displayed on our working surface.

Of course. But the point was that the computer desktop has stronger
constraints than the physical one - you can't just intend to use the
computer desktop like a real one, you should have a different workflow
that relied on the computer strengths and not in its weakness. The
desktop metaphor does the latter.



> > 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.
>
> http://kde-artists.org/main/component/option,com_smf/Itemid,48/expv,0/topic,238.0
> http://kde-artists.org/main/component/option,com_smf/Itemid,48/expv,0/topic,158.0
> (Read both pages of the "design mode" thread. I posted a rough mockup
> on the 2nd page).

The "formats" of plasmoids are a good idea. I think they should be
used as different "views" of a same object - every plasmoid should be
able to support all these four positions. The user should be able to
move any plasmoid from one of these roles to any other one and it
should keep working there. Is this how they're being designed?

I've answered some concerns about the design mode in that thread. But
moving common files should be done by default drag and drop/direct
manipulation - the design mode should only be used for creating and
resizing containers, not standalone items.


> Well, I think the solution will eventually include he marging of the
> two concepts. A goal-oriented desktop design. Basically, the desktop
> has its management struture, and the goal management integrates with
> it. Maybe I'm crazy though. (It's definitely been suggested before ;)
>
I'm not sure how much management does the desktop support, and how it
maps to user goals? There should be high level management tools so
that changing user goals doesn't require manual tweaking of the whole
desktop configuration - some automation should be available. For
example, if I have in my desktop a "incoming" section where I store
mails and IM conversations, and I want to change its contents into two
folders "with photos" and "without photos", I shouldn't be forced to
move each document by hand.


> I agree that separate desktops should be able to store different
> plasmoids/files/etc. It becomes a logistial nightmare though. "Which
> desktop was computer monitoring on? Oh, yeh. It's on the dev
> desktop.", or other stuff like "Where did I store that file?".

That's what system-wide search is for. You can retrieve some files by
position, but you can also find them by keyword, by content, date or
any other attribute. Applets/plasmoids/active windows should also be
searchable with the universal search tools.


> > On 30/09/05, Zak Jensen <coolguyzak@gmail.com> wrote:
> > > 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" ;-)
>
> True. I'm not sure how to respond to this. I know I would much rather
> have 1 than the other, but I have no clue how to express it. (Maybe
> there is no difference).

There isn't. The hated paperclip would really be a (somewhat) useful
tool where it not for the false positives (i.e. it activates when it
shouldn't). What happens if you wanted to edit *two* files? Then your
proposed behavior to restore the workspace is getting in the way, and
is as bad as Clippy.



> > 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?
>
> Well, the show desktop tool doesn't perform different actions. The
> desktop does different things dependent upon how you interact with it.
> Eg. the *desktop* will re-maximize windows when you run an application
> or open a file, but it will keep them shrunken when you interact with
> a plasmoid or another "desktop" element.

Its quite difficult to see that "the desktop" maximizes windows. The
most obvious way to see it is that the action performed by the "show
desktop" button is undone after interacting with the desktop. But this
doesn't happen always.



> Easy overridability would be the difficult part. The obvious solution
> (to me) would be to provide several buttons (not by default) which
> perform the action in a different manner. So, for instance, there
> would be the intelligent button, the "minimize all windows" button,
> etc.

I have a proposal for an interface that could do the trick. Where is
the best forum to explain it and attach some mockups? The kde-artists
forum has several threads with suggestions for new features, but I
don't know if there's enough usability people there or I should post
it to this mailing list.



>
> > 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.
>
> Yeh, as I said above ;) I want the intelligent option though. ;)

You might have it, but it definitely should be an optional and
separate command, not the default.



>
> > > 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?
>
> Oops. Apparently I combined some stuff and came up with that. What I
> was talking about doesn't exist. Largest complaint I've seen is that
> it would be highly unfamiliar.

Unfamiliar isn't that bad when you use standard lore about human
interaction. iTunes was unfamiliar when it came out and became a great
hit because of its superior song management capabilities. Mezzo is
different to other desktops, but it's quite similar to kiosk help
systems that you find in public places; and it has a simple two-level
structure that doesn't put any burden on user memory. Contrast this to
the several layers deep hierarchical K-menu in KDE.


> So, you're saying we provide default options of KDE, Mac, Win, and
> Mezzo?

Yes, why not? The initial configuration wizard of KDE makes it easy to
add several different system defaults. You could call the Mezzo
default "Appliance Computer" or something like that, suggesting an
interface for beginners, and say in the description that it's used for
simple, straightforward computer use.
_______________________________________________
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]