unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

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