[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] Deprecation of the "Window" Metaphor



On Sun, Jan 2, 2011 at 11:56, Thorsten Wilms <t_w_@xxxxxxxxxx> wrote:
On Sun, 2011-01-02 at 06:55 +0100, frederik.nnaji@xxxxxxxxx wrote:
> now here's a list of example solutions how one can design something
> without
> "window" in mind:
> * OLPC's Sugar: http://www.collabora.co.uk/services/case-studies/olpc
> * Ubuntu's: http://blog.canonical.com/?p=379
> * http://www.youtube.com/watch?v=hxpzNGppcbs ( XMONAD Demo on Compiz
> 0.9 )

You keep talking about the window metaphor as if it was clearly defined.
At the core a window is a usually rectangular area that tends to have a
frame, size and position handled by a system component and a content
area controlled by an application.

The term "window" quite likely came to be because you have a view onto
something.

Disallowing overlapping to have only full-screen or tiling instead thus
sounds like a weak reason to call them something else.

This is not about replacing the "window" metaphor with another term. It is about leaving the predominating WIMP paradigm behind us eventually.

"window" is simply a staller, it is 2d, it is flat, it is contraint-per-definition, not a metaphor that inspires me to think of content, an object relatiionship or network, dynamic repositioning of objects or conditional nesting of objects and so on and so forth.
"Window" at best reminds me of the needs of an accountant, who has a relatively flat and static document before him, someone who is neither interested in compositing managers or semantic scaling.

> I don't think that windows as they are getting in our way at all, i
> just think we have already chosen to go along another path, as above
> design documents and demos sufficiently indicate.

Here, first you state there is no motivation to change.

Oh yes there is, for decades now!
 
Then you talk about a "we" that doesn't exist.
Then you claim a decision has been made and a path has been stepped on,
but both is far from being clear.

To be clearer, this is about moving on, thinking beyond 2d windowing, building a greater paradigm that will hopefully greatly outlive the limited experience we have been presented with since the early seventies [1].
Compiz offers much of the raw functionality needed for the next upcoming steps into the great beyond ;)
This is why i think it is time to address the topic in such an open fashion now. Compiz is not called a "window manager", it is a compositing manager.
Since compiz is the soil in which Ubuntu's Unity UI is growing, i think it is time to get out of the all-infectuous "Window" metaphor a bit, time to clear our minds of it as good as we can, because it has no proper meaning outside the disturbing toolkit implementation of it, and it is a major staller when it comes to innovating UIs.

I might be pedantic, but a little more intellectual discipline would
really help.

Indeed, a valid point..

The window metaphor was first taken to market by Apple in 1984, when the Mac was made popular. Yes, back then it was great in order to have *some* form of implementation for the appliances of the time. Those were accounting, lists, tables and presenting flat documents on a flat screen.

Today, the concept doesn't fit well anymore as a dominating element e.g. within the "object-oriented interface" [2] proposed by Jakob Nielsen.
The whole point about "deprecating" the usage of this early and even so blurry HCI metaphor now is that Nielsen wrote his text more than 17 years ago, already reminding "us" of the real purpose and potential of the interface, which is being forgotten quite often in "window" and "window management" focused design discussions even today.

We no longer use computers for "flat" experience, so windows are extremely inconvenient in our times, since they always guide design into the 2d direction, whilst our applications are far beyond that for years already now.
 
Lke usual, this should be about why to change something, what to change
and how.

I think this should be about change, yes, but discussion is not at all harmful, since many of "us", as yourself, would like to object to the very notion of letting go of this ancient metaphor for the better parts of our time. And of course, the "how" is meant to be a collaborative achievement, i could lay it all out by myself, but it wouldn't be 1% as good as what we can elaborate, discuss and specify together, if "we" want to.

The advantage of using as much of the screen as possible for a single
application is obvious, at least to anyone who ever worked with a
graphics application.

exactly, that's why words such as "workspace" or "space" or "screen" are more valuable metaphors than "window", and the metaphor "window" tends to have a certain magnetism, which is unrelated to its disputable value. The magnetism of the metaphor "window" is more related to how widespread it got due to short-sighted revenue oriented visions of those stakeholders who made it popular, "window" is otherwise not popular. I encountered "window" in a signal processing class, it was synonymous to "frame" or "slice" and had no further metaphorical relevance.

The need to have more than one thing/application/task on the screen at
once should be clear, too. You might have to compare documents, need a
reference for something you are drawing, be following a tutorial,
discussing a website on IRC ...
It seems all of this can be handled with tiling and does not call for
overlapping windows.

overlapping what?
overlapping content? overlapping documents? overlapping objects?

With overlapping windows, you need to have a z-stack and you have to
define raise/sink behavior. That's quite a price to pay. So what's the
advantage of overlapping windows over tiling?

with windows you need to think about these things, with objects, workspaces, content and interaction (dialogs), there are less problems in design, than with ancient "windows" in mind.
 
Sometimes you might need to see only part of another window. A tiling
approach could allow that, too, but it might increase complexity.

true. that's why i would like to see few tiles as possible, perhaps 2 for starters.
Windows7 has 2 afaik, and i like that approach even though i personally don't like its implementation in MSW7.

A partly obscured window is in a state that is kind of between fully
shown and hidden. For me personally, the most interesting aspect is
being able to change between 2, maybe 3 or 4 windows very quickly, due
to having very large target areas. But them I use focus-follows-mouse
and auto-raise without delay, settings I can't recommend, as common
window-managers do things that mean you have to use alt-tab (or similar)
in combination to get out of some unfortunate situations.

Your auto-raise without delay is a very special configuration, i could afford that when i had a larger display, today, i can't :P

I'm quite happy to see partial transparency implemented in compiz upon "move".
These are the things i mean, and seeing them implemented just shows me that everything is on the right path.
Now partial transparency should also be implemented for those scaled representations we see in the "scale" view, aka the "window picker".
That way we could easily know that a window is afloat and not sensitive to keyboard input.
Also, it doesn't make sense to have window controls or title bars on those scaled "objects" in the scale view, not even on hover.
What we should have is the close button mark proposed, and it should be big enough for grandma not to have to go through an extra course on hand eye coordination for the elderly to be able to aim at and click.

Thank you thorwil for your patience and for getting into this thread, even though you and i both know that i didn't really start it off well.
I also think that if nobody else contributes here, this is a good moment to just let the thread die ;)

 
[1] http://en.wikipedia.org/wiki/WIMP_(computing)

[2] http://www.useit.com/papers/noncommand.html