DOC: rework the "Target audience" and add an overall conclusion
- included the list of "Personas", quoting from Wouter's document - add some details from the ensuing discussion - close the document with a section "Conclusions" to list the most relevant open points
This commit is contained in:
parent
e2d9fea710
commit
a021fe1189
2 changed files with 66 additions and 26 deletions
|
|
@ -1,7 +1,7 @@
|
|||
Meeting at FrOSCon 2025
|
||||
=======================
|
||||
Date: 2025-08-17
|
||||
Author: Benny Lyons and Hermann Voßeler
|
||||
:Date: 2025-08-17
|
||||
:Author: Benny Lyons and Hermann Voßeler
|
||||
:toc:
|
||||
|
||||
Present::
|
||||
|
|
@ -19,11 +19,19 @@ and decided to produce a design document. Here we attempt to reconstruct and doc
|
|||
|
||||
Points discussed
|
||||
----------------
|
||||
We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X. However, our
|
||||
Placement concept [TODO Link] which predates FCX's release [TODO source] shares similar goals but
|
||||
its scope is more far-reaching. We consider _Magnetic Timeline_ to be an important advancement to
|
||||
legacy track oriented GUI schemes; but it is more mouse confined and does not support several Control
|
||||
Systems footnote:[Mouse, keyboard, pen, hardware controls] on an equal footing, which is our vision.
|
||||
We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X.
|
||||
However, our link:{ldoc}devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)]
|
||||
which predates FCPX's release,footnote:[Final Cut Pro X was
|
||||
link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic
|
||||
Timeline« is generally considered a novel concept introduced with this update. The initial reception
|
||||
was rather controversial.]
|
||||
shares similar goals but its scope is more far-reaching. We consider _Magnetic Timeline_ to be an
|
||||
important advancement to legacy track oriented GUI schemes; but it is more mouse confined and does
|
||||
not support several Control Systems footnote:[The term »Control System« refers to one technical
|
||||
realisation of an human-computer-interface, which is used coherently and can coexist with other
|
||||
such interfaces -> link:{ldoc}/design/gui/InteractionControl.html#_foundation_concepts[more]. +
|
||||
The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...]
|
||||
on an equal footing, which is our vision.
|
||||
|
||||
Modes, Tools and Views
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -32,9 +40,9 @@ popularity in video editing applications. Tools and Views were introduced to imp
|
|||
of Modes. We agreed to adopt tools as the more preferable system, but only if we manage to develop
|
||||
a suitable handling mechanism that can be used naturally throughout all Control Systems.
|
||||
|
||||
Taking inspiration from Blender, Hermann proposed a fundamental shift by extending the scope of tool usage
|
||||
Taking inspiration from Blender, _Hermann_ proposed a fundamental shift by extending the scope of tool usage
|
||||
to the entire UI. To do this, we agreed to introduce a top-level tool to navigate throughout the UI.
|
||||
Wouter expressed some concerns on how effect parameters and mixer stripes could be accessed. This
|
||||
_Wouter_ expressed some concerns on how effect parameters and mixer stripes could be accessed. This
|
||||
remains a problem to be resolved. We agreed that this default navigation tool should map down
|
||||
naturally to conventional usage of the mouse.
|
||||
|
||||
|
|
@ -43,9 +51,9 @@ to dragging and moving clips, but we were concerned that such a mode might hampe
|
|||
with the UI. It seems preferable to introduce the moving of clips as a sub-mode into the
|
||||
navigation tool, with the option to lock moving of clips.
|
||||
|
||||
Wouter introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI.
|
||||
_Wouter_ introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI.
|
||||
The ability of Tools to support sub-modes is a simple extension of this proposal.
|
||||
With this functionality, it would be then be possible to switch between trim-, roll-, slide- and shuffle-edit
|
||||
With this functionality, it would be then be possible to switch between trim-, roll-, slide- and slip-edit
|
||||
after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion
|
||||
would be integrated as a sub-mode if a user decided to manipulate any setting value.
|
||||
|
||||
|
|
@ -64,9 +72,8 @@ excessive relationships. This can be improved by using a small number of prototy
|
|||
magnetic, relative and music anchored. Moreover, we require a diagnostic to reveal the reason why
|
||||
a given clip is positioned at where it is.
|
||||
|
||||
Routing
|
||||
^^^^^^^
|
||||
Hermann explained how the routing in Render Engine is based on Placements.
|
||||
.Routing
|
||||
_Hermann_ explained how the routing in Render Engine is based on Placements.
|
||||
All data streams are grouped according to the medium (video, audio,...) by default.
|
||||
Mixing-groups can be automatically established if resources are tagged.
|
||||
|
||||
|
|
@ -84,16 +91,16 @@ feasibility.
|
|||
|
||||
Grouping Devices
|
||||
~~~~~~~~~~~~~~~~
|
||||
One idea presented in Wouters document was the introduction of a light-weight grouping device.
|
||||
One idea presented in _Wouter_'s document was the introduction of a light-weight grouping device.
|
||||
This would solve some problems, for example, a number of objects can be collectively moved
|
||||
as one unit together. Hermann proposed to use placements to achieve the same effect.
|
||||
as one unit together. _Hermann_ proposed to use placements to achieve the same effect.
|
||||
It is yet to be resolved how this grouping can be visually represented.
|
||||
|
||||
One important issue proposed by Wouter was to use segments to arrange the narrative at the
|
||||
One important issue proposed by _Wouter_ was to use segments to arrange the narrative at the
|
||||
top level. To implement this feature would require on the one hand a considerable effort
|
||||
by developers, on the other hand, it does not naturally fit into the Lumiera core design
|
||||
as it would be a very specific extension instead of a homogeneous building block in Lumiera.
|
||||
Hermann proposes to use nested sequences to implement this feature which is already been
|
||||
_Hermann_ proposes to use nested sequences to implement this feature which is already been
|
||||
planned for the session model. All these nested sequences will have their own track structure,
|
||||
which is a tree relationship. For example, expanding one structure would not necessarily
|
||||
expand neighbouring structures. Another advantage of using this mechanism is that it can
|
||||
|
|
@ -101,7 +108,7 @@ be used to construct a transition between adjacent chapters of a film while stil
|
|||
the ability to reshuffle chapters to explore various narratives. We can thus solve two
|
||||
problems with the same feature.
|
||||
|
||||
Wouter was concerned that it might be tedious to navigate between different chapters,
|
||||
_Wouter_ was concerned that it might be tedious to navigate between different chapters,
|
||||
especially if it is necessary to expand or collapse these elements repeatedly. One
|
||||
countermeasure to relieve constant opening and closing elements would be to expand
|
||||
the elements step wise while still retaining the ability to edit the contents.
|
||||
|
|
@ -119,17 +126,50 @@ important in determining whether a feature is implemented or not, e.g., effort
|
|||
required to implement a feature; but we focus solely on identifying our target
|
||||
audience here.
|
||||
|
||||
Wouter identified five groups which mould most likely be attracted to Lumiera
|
||||
and its goals. During our discussions, we ordered these groups according to, in our
|
||||
opinion, those who would be most interested too those he would be less interested.
|
||||
In his »Lumiera Workflow Proposals«, _Wouter_ identified five groups which mould
|
||||
most likely be attracted to Lumiera and its goals.
|
||||
|
||||
These groupings are naturally provisional and will mostly likely change--which
|
||||
is very good--as we add important features that are deemed essential but fit to
|
||||
- The highly specialised editor who works in an environment where different parts of the
|
||||
post-production of a film are handled by different people: assistant editors, colourists,
|
||||
audio engineers, etc.
|
||||
- The allround contracted editor who handles all aspects of post-production
|
||||
- The allround artistic filmmaker who also edits
|
||||
- The allround social media creator who values the use of visual effects,
|
||||
motion graphics and sound effects.
|
||||
- The free-flowing editor who does not have a fixed idea of how the edit should be
|
||||
and instead wants to play and move things around, and who might not work in a linear
|
||||
fashion: they might do a bit of colour correction to get a better sense of how a scene feels,
|
||||
then go back to editing, etc.
|
||||
- The editor who has the film already cut in their head and have a very strong sense of
|
||||
what they want to do and work in a very structured way towards accomplishing this vision.
|
||||
|
||||
These groupings are naturally provisional and will mostly likely change -- which
|
||||
is very good -- as we add important features that are deemed essential but fit to
|
||||
no group in our selection.
|
||||
|
||||
We identified the following groups:
|
||||
_Benny_ proposed to order these groups according to, in our opinion, those who would be
|
||||
most interested to those he would be less interested. In the following discussion, we
|
||||
identified the first group (the specialised editor within an industrial work environment)
|
||||
and also the social media creators to be a more challenging audience, since these require
|
||||
rather specialised tools to perform their tasks.
|
||||
|
||||
|
||||
Conclusions
|
||||
-----------
|
||||
While we reached agreement in many points, the goal is to produce a design document for
|
||||
the GUI workflow. This task will require to spell out many details, thereby validating
|
||||
the viability of our ideas.
|
||||
|
||||
- it remains to be shown that a generic _gesture concept_ can be mapped onto different
|
||||
control systems coherently
|
||||
- it is not clear yet to which extent it is possible to include other UI elements like
|
||||
the effect property settings into an overarching _navigation mode_
|
||||
- a scheme must be worked out which allows to add a _placement prototype_ to each clip
|
||||
added to the timeline; furthermore we need to develop a representation that exposes
|
||||
the detailed _placement constraints_ in an understandable way
|
||||
- the proposed mechanism to control the layering order should be actually implemented
|
||||
and put into practical use to determine its feasibility
|
||||
- we need to consider in more detail how the proposed _light-weight grouping_ can be
|
||||
represented graphically and what actual features can be attached to such a new device.
|
||||
- a detailed analysis is required to establish gradual steps of expanding / collapsing,
|
||||
so that the overall timeline remains balanced and excess complexity can be hidden.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Lumiera Workflow Proposals
|
|||
==========================
|
||||
Date: 2025
|
||||
|
||||
//MENU: Workflow Proposals Verwijlen
|
||||
//MENU: label Workflow Proposals Verwijlen
|
||||
|
||||
- TODO include full text of from Wouter
|
||||
- link:FrosconMeeting.html[Discussion at FrOSCon 2025]
|
||||
|
|
|
|||
Loading…
Reference in a new issue