[Lumiera] Interface Concept (3) -- "state vs space"

[Ichthyostega]

Am 15.04.2015 um 18:42 schrieb Ichthyostega:
> Today I'd like to bring to your attention a new contribution by Christoph 
> Varga: the draft version for an Interface and Workflow concept.

> http://lumiera.org/documentation/design/workflow/InterfaceConcept_Varga.html



Hello all,

in the past, I've written several messages with thoughts about Interface
and workflow, inspired by the Contribution from Christoph Varga. In lack of
a real discussion, I'll continue to talk to myself this way; hopefully you'll
understand.

Interfaces are simple and satisfactory, as long as there is really not more
to consider than fits into a single window. Think a mail client. I mean *just*
a mail client, nothing more. Get mail, compose new message, delete, forward,
flag, put into folders, filter, search. Set up your account credentials.
That's it. Easily fits into a single window, around a single content area.

The pain starts when we need to fold away stuff. Enablement means to have
those things at hand, which you need to carry out the task at hand, adequately.
Which allows you to move along, with a speed still commensurable with that task.

Probably you know the famous old blogpost by Joel on Software from 2000
"Controlling Your Environment Makes You Happy"
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

His observation is to the point; but the problem does not end with just
tiny little frustrations and a bad mood. As far as film editing is concerned,
we're talking about a creative task, and we're talking about a task usually
performed under pressure. In such a situation, it matters if you consider
something doable, or just, well, doable. Because, in the latter case, you'd
better stick to the established and proven.


What actually is getting in our way? Stuff that is there, and stuff that isn't.
Stuff is there because you might use it, because someone thought you might
use it, because otherwise you might not be able to find it, you might
not even be aware it is there and might be of use. What a waste.

And stuff is not there, because someone thought you do not need it.
At least not here, in that context, in that way. Interestingly enough, there
is yet another reason why something isn't at hand: due to matters of scale.
In principle, what you need is there, but it is just to damn hard to
get at it, using the canonical way. You'd need a shortcut. And it
is just too damn hard to establish a shortcut the canonical way.

To put this into some practical context: in editing, it is a constant
low-level frustration that it is so damn hard to reach out for that
other piece of material, which you just might want to have a look at,
for reference, be it to relate to it, or be it for inspiration.
More often than not, this piece of material is even another part of
the edit. You know it is there, but it will cost you several minutes
at best to get out, navigate there, drill down, navigate back and
re-establish your current context.

The common theme underlying all those frictions and obstacles is
dependency on context. What needs to be at hand, depends on the context.
It can not be derived from first principles. And it can not be established
empirically, by observation and statistics. For that reason, all our proven
methods of construction break down on that kind of problem. So we tend to
ignore it. Context dependency cross-cuts any orderly organisation.


Yet when considered the other way round, matters do not look so grim
altogether. The person involved in the task in question, because it is *his*
task, knows very well what needs to be at hand. So we need to look for ways to
let that person keep in close proximity what needs to be in close proximity.
The point to note and to stress is: *that person*, no one else.

What we see all the time is something different. We see industrial entities hire
herds of mindworkers to cook up blessings and enablements and mind blowing
experiences for "the user", which is assumed to consume them and be happy. We
see the emergence of artificial "intelligences" to figure out magically what you
want and need, before you even know you want and need it. While such is
well meant, certainly, it is apt to create just more and more stuff
that gets into the way.

Enablement through software does not mean that it has to thrill and entertain
you, it does not need to inspire you, it needs to stay out of your way. It needs
to be passively supporting, and that is very hard to achieve, from a view angle
of construction. Not to build that cool stuff you could imagine, and to keep
it open for something you can't really imagine. Because it's up to someone
else to do it.


A way to approach that difficult task is to rely on the metaphor of space.
More in the topological sense: things connected here and there. When an editor
works on a movie, the material will be unfolded. This creates such a topological
space. And from the side of interface design and construction, we need to ensure
that was was there, seems to remain there. In fact this runs quite against the
nature of software construction; it is something to be build actively, to create
that notion of persistence. The ability for the user to return to a place as
mapped out by the material. Where, more or less by coincidence, an context
has been formed, we need the ability to carry that context along, which for
the user translates into the capability to stay in a familiar environment,
while the work proceeds. This is how I understand the importance of those
screens and stages and views, as laid out in Christoph's contribution.