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

Ichthyostega prg at ichthyostega.de
Mon Apr 27 05:38:56 CEST 2015


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

> Feel free to comment or start a discussion; personally I intend to comment in
> more detail on some aspects the next days.


Hello all,

as promised I'd like to comment on some aspects of the Interface Concept
of Christoph Varga. To me, the outstanding trait of this contribution is
that it tries to take a novel approach, and it tries to approach the editing
work in a more holistic way: as a process within a working environment.
This contribution does not so much focus on proposed "cool" features,
and thus we should try not to take the described elements too literal,
(the way a technician would do normally). Indeed, we should be aware
that there is some kind of an "impedance mismatch". For one, Christoph
is not a developer, and thus does not know most of the inherent structuring
present within the elements of modern graphical computer interfaces.
Actually, I'd prefer to take that as an advantage, at least to give us
a new view angle. Of course, at times there are discrepancies, and those
who /are/ familiar with GUI technology could just help to bridge the gap.
And, secondly, this concept attempts to do things better, or more suited
to the actual working situation as current editing software does. Such an
attempt in itself is always ambivalent.

Anyway, the first thing I'll take from reading this concept is the concern
regarding terminology. It should be a *goal* that -- once we got more ahead
with our workflow effort -- we should have also created a glossary of clearly
defined terms. Right now, we don't have such a thing, and thus we better be
careful. There is a limited set of terms, which are in use and well suited to
describe matters of computer interfaces, and of film editing alike -- and those
terms are often overloaded with several meanings. So the challenge it partially
also a challenge of mapping mental concepts.

A good example for this issue is the term "view", which plays some crucial
role within this concept, as located within the "stages" (see Page 7). Now,
besides having a philosophical meaning, this term has a technical meaning
related to film making and imaging in general. It has a (verbal) meaning
related to one of the most crucial tasks of film editing: namely to view
the material. From this latter meaning, the term (noun) "viewer" is derived.
Such a viewer is the software equivalent of the viewing monitor in the editing
machine (Moviola, Steenbeck, KEM...), or the monitor hooked up to camera or
video tape deck. While these usages are not really problematic (since they
can be discerned by context or usage pattern), a much greater concern is the
fact that "view" is a very fixed and precise technical term in the realm
of graphical computer interfaces. This usage is more related to the
usage known as database view: it is a pre-defined procedure to extract
and pre-process and augment the raw data of the underlying data model,
with the goal of presenting that data, with focus on a specific aspect
or property. A view brings raw data into presentation form, and typically
is limited to showing data, not editing it. Based on and derived from that
notion, the core architecture of most (if not any) modern UI systems is
defined as "the separation of Model, View and Controller". In this context,
a view means a window-like component within the GUI, which has its own
decorations, buttons, scrollbars and commands. And this view presents
a certain view (pun intended) onto the underlying data. For example,
the timeline would be, technically speaking, a view component. The
viewers to watch the video, together with the play, ffd, rew, pause, stop
buttons, would be another view component. The "project explorer", with
a tree of folders (bins) and clips within would be yet another view
component (a so called tree view component). Each of these components
might have an associated controller component. And there is most likely
a master controller component, which coordinates the view state and
any access to the data model (data storage structure). Btw, all the
"components" mentioned here are pieces of software, not hardware.

Probably this is enough of technical details, to highlight the problem
anyone familiar with that technology has with grasping the notion of
"view" in Christoph's concept. It is very hard to 'get' a novel idea,
maybe even still vague, if you attach a very fixed and settled meaning
to the very same word since years. Of course, one can exchange words,
but it is much harder to exchange the mental patterns behind the words.

So -- please bear with me as I'm trying to understand that different idea
of a "view"! Of course, I am inclined to approach that by sharpening
the differences, thus --

within each of the "stages" mentioned in the concept, there will be --
technically speaking -- a set of GUI view components (timeline, media viewers,
tree explorer(s), property editors). Just, each stage will have a slightly
different selection of view components, and a different screen layout
(partitioning of window space) of these view components.

If this understanding is correct, then the "stages" of Christoph's text are very
much what is commonly known as "perspectives" (Blender uses the term "screen"
for the same concept). I am well aware that Christoph's proposal
adds some structure and meaning beyond what a perspective commonly is, but
that's another story. (I think this is also worth noting and will comment on
that separately)

So, starting from that understanding, I'd like to ask questions for
sharpening, verifying, falsifying, differentiating....

- is a "view" (Christoph's term) limited to a single GUI viewer component,
  or does it span several such components at the same time?

- what is the relation between a "view" and presentation state?
  The latter means the variable internal state of the viewer component, related
  to how things are presented: the position on the scrollbars (i.e. the so
  called "viewport"), the zoom setting, what nodes are expanded or collapsed,
  the level of details shown, etc.

- in the Mindmap, I find the following description "stages can have many view
  options, this are the 'views'. views are pre-configured by the system
  set-up or by the user". So does this mean, that a View is a set of
  presentation state settings, bundled together as an entity which can
  be assigned or switched and exchanged?

- what about multiplicity? can there be several "views" within a given "stage".
  I mean, generally, and as well at a given time (so basically these are two
  questions). Can views be combined or merged? (a third question)?

- why do we need a distinction between "views" and "sub-views"? Are sub-views
  essentially something different than "views". can a "sub-view" stand-in
  for a (full) view?

- where is a "view" actually attached? does it "stick" to the stage, or does
  it rather stick to the user's Session? Or does it "stick" to the data model?
  Has the stage a memory regarding the contained view(s)? So, that if we're
  returning back to a given stage, we'll find the same view(s), even while
  we have switched to other view(s) on the same GUI view component within
  another stage? (hehe, I know it is confusing)?


@Christoph, please understand that I'm not here for nitpicking. Intuitively,
guess I somehow grasp your proposed idea and I think it will be helpful.
More so, since you mention my idea of a "work site" in the same context,
which is also something not present in current software, and both ideas
seem to be somehow related. Basically, I think, what you propose here
matters and we should try to get it defined more clearly.

Cheers,
Hermann





More information about the Lumiera mailing list