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

doc/design/workflow/Verwijlen/FrosconMeeting.txt

@@ -1,7 +1,7 @@
 Meeting at FrOSCon 2025
 =======================
-Date: 2025-08-17
+:Date: 2025-08-17
-Author: Benny Lyons and Hermann Voßeler
+: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
+We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X.
-Placement concept [TODO Link] which predates FCX's release [TODO source] shares similar goals but
+However, our link:{ldoc}devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)] 
-its scope is more far-reaching. We consider _Magnetic Timeline_ to be an important advancement to
+which predates FCPX's release,footnote:[Final Cut Pro X was
-legacy track oriented GUI schemes; but it is more mouse confined and does not support several Control
+link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic
-Systems footnote:[Mouse, keyboard, pen, hardware controls] on an equal footing, which is our vision.
+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
+.Routing
-^^^^^^^
+_Hermann_ explained how the routing in Render Engine is based on Placements.
-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
+In his »Lumiera Workflow Proposals«, _Wouter_ identified five groups which mould
-and its goals. During our discussions, we ordered these groups according to, in our
+most likely be attracted to Lumiera and its goals.
-opinion, those who would be most interested too those he would be less interested.
 
-These groupings are naturally provisional and will mostly likely change--which
+- The highly specialised editor who works in an environment where different parts of the
-is very good--as we add important features that are deemed essential but fit to
+  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.

doc/design/workflow/Verwijlen/index.txt

@@ -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]