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

List:       kde-usability
Subject:    Re: Idea for KDE 4 - global, smooth zoom feature.
From:       "Diego Moya \(a.k.a. TuringTest\)" <turingt () gmail ! com>
Date:       2005-05-26 18:58:31
Message-ID: 11ee049405052611583d0091fc () mail ! gmail ! com
[Download RAW message or body]

I'll try to cut out irrelevant themes for brevity.


On 26/05/05, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Thursday 26 May 2005 04:55, Diego Moya (a.k.a. TuringTest) wrote:

> > In a search interface you can't see things in advance. You start with
> > an empty screen and you have to recall the object properties from
> > memory.
> 
> actually, this isn't true at all. this is a common misconception which i've
> dispelled many, many times on this list. you only need a starting point or to
> be "near enough"
Could you provide a pointer to the discussion? I can't find it in the
archives. What does "near" or "starting point" means? Those sound a
lot as physical space properties, don't they? ;-)

If I understand what you are saying, a search could use the properties
of an already located object as the query terms, incrementally
tweaking them to get the desired result  ("find all objects of the
same type as this one, created earlier and which contain the same
image"). Then why wouldn't you want to use "placement" as one of those
initial properties? That's what an spatial interface is all about.


> 
> the biggest mistake so many spatialites make is to head for the file manager
> when that's the least compelling argument they could hope to make.
> 

Actually I'm not that interested in the file manager. My main concern
is unifying within a single interface the idea of virtual desktops
(i.e. separate local working environments) and the management of
object micro-placement (drag and drop inside the ZUI navigation
system).

A traditional file manager tool *could* be still used to find objects
in a hierarchy, but when found you could place them in the near
environment like you can place them on the desktop now, to have them
ready for direct manipulation without the need for constantly moving
windows out of my way.

We use the inner area of windows for direct manipulation now, but they
can't accept all kinds of objects, and this process can't be extended
to work between different apps. So your workflow gets limited to
whatever the application can do, you don't have an universal container
(the desktop was supposed to be just that, but it's always hidden
-because of windows- and cluttered -because there's only one, and it's
small).


> > (think again of
> > Firefox incremental text search - that's both spatial and efficient).
> 
> how is it spatial, exactly? and the only efficiency it gains is that it
> doesn't cover the results, which is great, but hardly to do with spatial
> representation of information.

The behavior of Firefox incremental search is spatial. A web page is a
*long, vertical* paper stream. Typing characters *moves* you through
the page an *stops* at the *first nearby* matching presence of those
characters.

How exactly do you define spatial? Thinking of it, for me it boils
down to two conditions:

1) the computer doesn't change the position of objects unless you request it
2) new content doesn't replace the previous content of a container,
it's wrapped into a new container and placed somewhere else on the
screen (maybe overlapping the previous one, but in a way that you can
easily recover it with point-and-click).


> > But you can also have a non spatial "find files" Continuous-Filter
> 
> which doesn't require changing the entire desktop mataphore. "you can fix the
> problems of the infinite plane the same ways you can fix our current
> problems"... then why change the current metaphore?

Because the current metaphore has the problem of covering the
inter-application universal container, the desktop, and it can't be
properly used.

Maybe a compromise idea between the two designs could be virtual
desktops with limited-scope zooming, similar to the bigger-than-screen
viewports of the older window managers?


> 
> > The ZUI is a better replacement for the current spatial paradigm (a
> > desktop with windows) which we agree is quite broken nowadays - it
> > doesn't work well for huge information volumes.
> 
> i don't believe its broken for reasons of spatial representation, however. and
> i believe this is easily demonstrated and has been many times over. we have
> the web and libraries to look at for two examples.

No, it's broken
1) because of clutter - everything goes into those same 1024x768 pixels. And 
2) it also has a steeper learning curve than single unified spaces
(because different containers -desktop, panels, windows, dialogs-
behave in different ways).

You can solve the first problem with virtual desktops, but then the
second one gets worse. A ZUI should solve both (but it's true that we
don't know enough to do a whole replacement - *yet*).


> overview of what? you don't need, nor really want, an infinite plane of
> everything for overview first. it's a really great way to show the results of
> specific contexts, but to provide a global view or to try and present _a_
> representation of things ... no.

An overview of all your available tools. That's what the current
starting point (the K menu) is for. With a ZUI, instead of a
difficult-to-navigate several-submenues-depth menu with an ad-hoc
search widget, you could have an ordered placement of applications,
navigable with the standard movement tools and searchable with the
standard search function.

Also one of those tools could be an overview of all your previously
open "local contexts", an unification of the "virtual desktops" Pager
and the "open windows" Taskbar. But yes, that would be mixing the
spatial with the concept of "workplaces" as separate subspaces.


> > Self-locating is the same as "I'm forced to use search to reach it,
> > even if I used the object ten minutes ago"?
> 
> no. if you used it 10 minutes ago, chances are good that unless you took some
> specific action, it's still nearby. 
> > Actually, spatial is an additional attribute which you can use for
> > search. "Find all the web pages that I opened yesterday near the KDE
> > mailing list".
> 
> this is a contextual link, not a spatial one. you can map this in terms of
> spatial coordinates, but that's a mapping only, and one that doesn't scale
> (e.g. when you have 1000 web pages associated with your KDE list) nor one
> that is inherently better than a simple listing once you have defined your
> parameters. spatial is a way to encode search parameters. if you aren't using
> it to encode pathways, don't bother. 
>so: how do you define a spatial search
> for "web pages i opened yesterday nere here" without optimizing for that
> particular search?

Ok, I think now I understand your point better: "nearby" is not only
for space and time: it can be defined over any relation, and it will
need to be done on-demand.

Of course you'll need to optimize for new searchs. My point is that
when that's done, the results of the search are *always* transformed
into a spatial representation (in order to show them on the 2D
screen).

So you should be able to save that visual representation together with
the new query terms. If you do that, the context in which the task was
performed can be easily recognized later. I don't only know that the
page I want was near the mailing list, I know that I put it *below it*
and *to the right* and that it had *yellow background*.

So if the search will show not only the pages, but also a visual
representation of the environment. This will allow you to recognize
those properties after the fact, when the results are shown. Otherwise
you should include "yellow background" as a query term a priori.

I believe that a ZUI can be used as a unified interface to solve the
problems that I've encountered so far with the WIMP desktop:

- easy context switching
- universal container
- visual recall


> i've been following as best i can the humane interface project's results and
> progress. while calling me ignorant may be a fun and easy reponse to muster,
> and while it is quite true that "ZUI"s have not been played with as much as
> possible, i'm not sure what that has to do with the fairly obvious challenge
> points there are to making the primary desktop metaphore a ZUI.

Wasn't trying to call you anything. I was trying to say that we *all*
are ignorant, because ZUIs aren't a mature idea yet. I believe they
have enormous potential, the same one that windows promised in the 80s
before they went into mainstream commercial computers.


> i have no problems with using spatial mappings where useful (e.g. calendars),
> i do have a problem with making it the central metaphore since it doesn't map
> consistently well.

Neither do windows, and they're the central metaphore now


> > No, you replace bad metaphors with better ones. The brain is hardwired
> > to use physical information,
> 
> limited amounts of physical information. LIMITED. this is what just annoys the
> hell out of me when discussing things with "spacionaughts" is that they
> conveniently ignore the fact that these evolutionary traits are optimized for
> dealing with a handful of items at once, and that the entire point of
> computers in the first place was (and is) to get us beyond that point. our
> physical information processing capacity is amazingly limited and highly
> environmentally reactive (versus useful for proactive organization; think of
> motion detection =)

Well, I think the WIMP environment does a terrible work at managing a
handful of items, because its too easy to mix information from
different contexts in the same location.

Also (before calling me names ;-) note that I never said "all tools
should be spatial", just "the same things that are spatial now (i.e.
the windows and the desktop) should be replaced with a better spatial
interface (the ZUI)". It's a matter of changing the universal
container, nothing else.


> computer. our linguistic capabilities and the ability to tell stories
> outstrips our spatial capabilities many times over. this is conceptual and
> has nothing to do with abstractions or mappings.

Until you say "she had a haircut the same as yours (looks at her), but
with this color [points with finger]. Wait, i'll show you a photo" :-P


> > > > In a ZUI you see everything at once

I should have added, "but you can filter things out and highlight only
the relevant ones".


> > You don't need to remember, you can see them from here - everything is
> > exposed.
> 
> i'm not sure how to get this through to you: i have too many things to make
> this practical. the vast majority of computer users have too many things to
> make this practical.

Not when you're under a local, limited context. For things inside the
context, spatial is better. Because the things that you have already
found are there, in front of your eyes.

For retrieving things outside the context and bringing them local,
THEN you'll need to use your conceptual search tools.



> 
> > If they're too small to actually see them, use search and it
> > will draw a big arrow pointing to the keys (and even a "zap" button to
> > move there instantly). Isn't that conceptually better that just
> > magically appearing them from nowhere?
> 
> no. google works just fine, thank you. and i don't really care where something
> came from when google returns a result. it's irrelevant.

And I suppose if you want to see several links you will open them in
tabs? Or will you repeat the query for every new page you want to
visit?

The tabs are the spatial representation of your query (filtered to the
items that you selected). With a ZUI, the pages could be open next to
the original link, inside a very small square. After reading that link
you could zoom out to go back to the results list (using the universal
navigation interface instead of the ad-hoc tabs).



> first, calendaring is perfectly suited to spatial organization for what should
> be pretty obvious reasons. 

Yes, because an abstract relationship ("before" and "after") has been
turned into a spatial representation


> a zooming interface is certainly good for certain things (like a city
> map, an organizational chart or a calendar), but discussions of making it the
> central desktop metaphore ignore that we don't use our computers exclusively
> or even primarily for these types of activities.

How do you characterize those activities not suitable to spatial
interfaces? I can't think of any, because all which I figure will be
transformed into a visual representation and located in a local
context.


> > Actually isn't Emacs exactly what are you advocating for with your
> > "get rid of spatial representation and bring more dimensions to the
> > mix!"?.
> 
> no, it's not. not in the least.

Then I can't figure what your ideal interface is. What's your idea of
"simultaneous managing of several dimensions"?

> 
> here: i'd love to see what you can do with a ZUI as the primary desktop
> interface. i've stated why i think it will fall on its face. i don't expect
> to convince you of that, though. please prove me wrong.
> 
> in fact, you know what i'd LOVE to see happen? i'd love to see people
> interested in spatial representations stop trying to wedge it into places it
> doesn't fit (e.g. the desktop as a whole) and start working with the places
> that it would be a PERFECT fit for within the desktop, e.g. search
> interfaces, calendaring, etc...

Could we start replacing the K-menu with a K-ZUI? ;-)
_______________________________________________
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] 

Configure | About | News | Add a list | Sponsored by KoreLogic