[Lumiera] Interface Concept (1) -- "view and perspective?"

[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,

with this mail, I'd like to continue the discussion towards an UI / Interface
concept. You might recall the contribution by Christoph Varga last spring, which
I see as a chance to keep that discussion going, even while topics more related
to implementation and technical matters are more in focus at the moment.

Related to our interface, we're still at the point to understand the basic
elements we need and want. To further that, I'll have a look at some existing
concepts to organise view contents and behaviour (we also still have the
unresolved problem that Christoph's concept uses the term "view" with a meaning
that does not seem to be entirely compatible with the technical term "view" as
commonly used in "Model-View-Controller")

Interface modes come to mind. Transient presentation state.
For a long time, almost a generation by now, it was the hallmark of good UI
design that an interface, as a whole, must not hide and obscure what you're
able to do, exhibit behaviour dependent on a global or even implicit "mode"
of operation. Like an text editor with a "writing mode", a "selection mode"
and a "command mode" (hello vi). Where common keystrokes lead to blatantly
different behaviour, depending on a global mode, and the user is locked in
and prohibited to do something obvious, because we're not in the right mode,
sorry can't do that, dave. In a similar line of thought, modal dialog boxes
where frowned upon, since they lock the user into a fixed process, with
"abort" being the only escape path.

Well, any true principle can be brought into a realm where it flips to the
dark side. When you just continue to add and add stuff just sometimes useful
for someone, matters aren't improved, but turn into a mess. When announcements
and attention are the unit of measurement, for some reason its more rewarding
to invent yet another feature, plug-in or App. And while we're unwilling even
to recognise the underlying tendency, we make it an "interface problem" and
rediscover the old anti-patterns of ill-guided interface design as a remedy.

As such this might be saddening, yet more relevant for our topic here is to look
at some offspring of this development, solutions to use interface modality
for better structuring and focus, to defeat clutter and information overkill.
Especially, I'd like to look at two concepts which seem to be related to
the "screens" and "views" proposed by Christoph.

The *Blender* UI, known as tiled windowing interface, is based on /splitting the
usable space/ of the underlying OS-window(s) repeatedly into sub-sections, each
of which can be occupied by a view. Blender provides a fixed and limited set of
views, which are views in the usual sense of UI terminology. By using a specific
gesture (key + mouse drag), you can always drag in yet another sub division into
any given section. Each sub-section gets a combined menu/toolbar, which is
located on the horizontal splitting element. Most notably, this view-bar begins
with a drop-down selector to choose the kind of view to be presented in this
part of the window. Examples for views would be 3D View, Timeline, Graph Editor,
Dope Sheet, UV/Image Editor, Node editor, VideoSequence Editor, Properties,
Python console...). All of the views expose the same underlying data model (in
fact, the whole blender architecture is built around a huge global data block
structure) and engine state; when you do something in one view, the effect and
result is visible in all views which happen to expose
this specific element just manipulated. If you render, all views share one
global current frame number and any play back animation corresponding to
this very frame.

But now the interesting point is that Blender allows for several so called
"screens". What I've described above, the splitting of a single window and
the allocation of some (provided) views to each of the segments, together
would be what comprises one screen. Each top-level OS-Window has a drop-down
selector for the screen to use within this window (but any given screen can
always be just active in /one/ window at any time). Blender comes with a
preconfigured set of screens and hotkey-bindings to select one of these
(Default 3D, Animation, Compositing, Game Logic, Motion Tracking, Scripting,
UV Editing, Video Editing) -- but since the screens are saved in the *.blend
file, you can always add/delete and rename screens, and, of course rearrange
the layout of a given screen to your heart's desire. Each screen remembers
the precise splitting proportion and order, the views allocated to each segment,
and the presentation state related to each view. For example, you could have
several 3D views (maybe located in different screens), and each of these
might be attached to a different camera and thus show a different location
within your 3D model.

For another, somewhat similar concept I'd like to look at the *Eclipse IDE*,
which is a plug-in based application platform, frequently used to implement
programming language editors and tooling. Eclipse is written in Java, but
uses a native "platform runtime binary" to connect to the windowing system
of the underlying host OS. That is, the UI possibilities are limited to
the common denominator of the typical modern desktop UI toolkit set, which
is adequate for the kind of stuff usually done within Eclipse applications.
In Eclipse, /docking/ is the foundation of screen space organisation: you
drag a given view either at some border, where it creates a split, or you
drag it into a existing segment, where it will be added to a tabbed stack.
Eclipse again uses the common notion of a view, examples being the code
editors, code outline, project tree, type hierarchy, call stack, processor
registers, variables inspector, git history, compilation errors,....

The relevant concept in Eclipse, related to the "screens" of Blender, is called
a "perspective". Again, a perspective remembers which views are opened and
allocated to which area and, how the docks were arranged. However, the
individual view instance has an identity on its own in eclipse, and when a given
view is present in several perspectives, e.g. a code editor opened on specific
source code file, it will retain its common presentation state. So, when you hit
F11 to launch a debug session on the current project, Eclipse will first call
out to the build system, and on success switch to debug perspective.
At that point, your current source code editor will maybe move to another place
in the screen layout and get another size or shape, but the current line and
selection (or whatever you can do with the given kind of view) will remain
unaffected, which is very relevant when navigating code. Another point worth
mentioning is that in Eclipse each perspective activates or deactivates some
action sets, which especially inject menu items, toolbar buttons and, most
importantly, special keybindings. Eclipse is based on the OSGi plugin
architecture, and features you want to use are delivered as plugin bundles.
For example C++ editing is such a plugin bundle, which contributes one or
several perspectives, specialised views and action sets. The user is then
able to customise each perspective, add/remove actions and keybindings,
open further views provided by other plug-ins and the like. Unfortunately,
the Eclipse project failed to come up with a sufficiently capable concept
for storage, backup and exchange of these customisations, so each plug-in
started to roll its own solution, turning each Eclipse installation into
a fragile and unreproducible unicum.

At this point, I've probably written enough (too much) to give a perspective on
the kinds of decisions we're faced when we want to build a similar UI concept.
For the actual usability it is of uttermost importance to get those questions
of identity, attachment, relation and storage right -- where "right" means
adequate for the task at hand. So yes, I am positive we eventually need to
describe and clarify those tasks we intend to do with an editing application.