contents
Wouter Verwijlen
Benny Lyons
Hermann Voßeler
To produce a design document.
This Meeting is based on the document »Lumiera Workflow Proposals« by Wouter Verwijlen. Wouter travelled to FrOSCon to meet the core team in person. This meeting discussed some of the core workflow schemes that would be embedded in the Lumiera GUI and form the way users interact with Lumiera. We discussed problems, resolved various issues and came to agreement on many design points. We then concluded to produce a design document. In the following we attempt to recapitulate the original meeting.
We agreed upon the importance of a magnetic timeline,
as introduced by Final Cut X.
However, our Placement concept (2008)
which predates FCPX’s release,
[Final Cut Pro X was
released in 2011, and the »Magnetic
Timeline« is generally considered to be a novel concept which was introduced with this update.
The initial reception was somewhat 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; however it is more oriented towards use
of the mouse and does not support several Control Systems
[
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 → more.
The most relevant control systems are: Mouse, keyboard, pen, hardware controls, …]
on an equal footing, which is our vision.
Modes are generally frowned upon in the User Interface Design discipline; however, they do enjoy considerable popularity in video editing applications. Tools and Views were introduced to improve the usability of Modes. We agreed to adopt tools as the more preferable system, but only if we succeed in developing a suitable handling mechanism that can be integrated in as natural a way as possible throughout all the Control Systems.
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 on the introduction of a top-level tool which would allow navigation throughout the UI. Wouter expressed some concerns on how effect parameters and mixer stripes might be accessed. This remains a problem that needs to be resolved. We agreed that this default navigation tool should map down naturally to the conventional use of the mouse.
We discussed that a consequence of that decision might be to introduce a special tool that is dedicated to dragging and moving clips; but we were concerned that such a mode might hamper fluid working with the UI. It would appear to be more advantageous to implement moving clips in the navigation tool as a sub-mode with the ability to lock moving clips as an option as might be desired.
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 then be possible to switch between trim-, roll-, slide- and slip-edit after activating the edit tool. Similarly, the gear switch as was proposed in a previous online discussion would be integrated as a sub-mode into various other modes if a user decided to manipulate any setting value.
The language of the UI is English. This does not mean that we exclude any language (and contributions to translations are welcome). Certain words and terminology should never be translated however, e.g., Track, Clip, Placement, … . We have no plans to support translations that require a re-ordering of UI elements such as languages written right-to-left. This is due to priorities that we define.
The use of fine-grained placement constraints is plagued with overwhelming the user with excessive relationships. This can be improved by using a small number of prototype set-ups: magnetic, relative and music anchored. Wouter points out that a similar scheme can be applied here as with the flavours of editing: A placement prototype can be pre-selected for a newly added clip — with the ability to adjust through the tool palette. Moreover, we require a diagnostic mechanism to reveal the reason why a given clip is positioned at its current location.
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.
The layering order is usually arranged according to track sequence in the UI. To retain this configuration we would have to put some content into a track which can be located at a distance from other related content: not an ideal situation. One way to alleviate this problem is to allow the user to configure the layer ordering for a single track so that all content is always fixed to be above a reference clip. While this promises to be an interesting mechanism to improve the track sequence dilemma and provide the user a greater track arrangement freedom, it will be necessary to carry out extra tests to ascertain its feasibility.
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 a single unit. 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 proposal by Wouter was to use segments to arrange the narrative at the top level. There are, however, two negative aspects associated with such a proposal: it would require a sizeable developer effort to implement and it would not fit smoothly into the Lumiera core design, as it would be a very specific extension in contrast to being a homogeneous building block inherent within Lumiera.
Hermann proposes to use nested sequences to implement this feature which has 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 be used to construct a transition between adjacent chapters of a film while still retaining 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, especially if it were necessary to expand or collapse these elements repeatedly. One counter-measure to relieve the incessant opening and closing of elements would be to expand the elements step wise while still retaining the ability to edit the contents. Furthermore, rendering a condensed preview of a virtual clip’s internal structure could help to avoid having to open and expand the clip in many situations.
It is important to accurately identify our target audience so as to be able to obtain a definitive perspective that encompasses those features which are best suited to being prioritised and incorporated into Lumiera, as well as those which are less suitable for this purpose. Defining such groups will allow us to fine-focus into the particular needs of these groups and provide us with a mechanism to curtail our long feature list. Eventually we might even have a list of features that are ordered according to priority.
In his »Lumiera Workflow Proposals«, Wouter identified six groups which would most likely be attracted to Lumiera and its goals.
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 all-round contract editor who handles all aspects of post-production.
The all-round artistic filmmaker who also edits.
The all-round social media creator who appreciates the use of visual effects, motion graphics and sound effects.
The free-flowing editor without a fixed idea of the edit, who prefers to explore the footage and move things around, and who might not work in a linear fashion: such editors might, for example, perform some colour correction to acquire a feel for a scene and then return to coarse-grained editing.
The editor who has the film already cut in their head and have a very strong sense of what they want to do and progress through structured and precise steps towards realising their vision.
These groupings are naturally provisional and will most likely change — which is very good — as we add important features that are deemed essential but fit to no group in our selection.
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 that 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.
While we reached agreement on many points, the goal is to produce a design document for the GUI workflow. This task will require many details to be set down, thereby exposing our ideas to scrutiny and the viability of these 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 attach 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.