LINK Topics - 5) Authoring Environment

wip
6

Here is a summary of what we covered in the 3 days:

A) What is an authoring environment?

  • Offers an overview over all parts of my project:

    Behavior & Design

    • Behavior → Patch Editor
    • 3D Assets → 3D Editor
    • Dramaturgie → Timeline Editor & Automata Editor
      (…)

    In Detail:

    • All these Editors offer windows that can be tabbed.

    • The window layout will be saved in settings files next to my project files. (Could be managed by version control system or not. Both has its use cases)

    • Editors offer an overview of the instances.

      • A Timeline Editor offers an overview of all loaded timelines.
      • A Patch Editor offers an overview o all patches (SolutionExplorer, ObjectGraphExplorer).
      • A 3D Editor could show all loaded 3D Assets at once…

    • Editors can be attached to instances

    • A user might want to have a root that comes with standard editors

  • Inspector & Preview windows are similar, they can contribute to the window layout. They react on what’s currently selected in the Patch Editor.

  • Visual Diff for patches

B) VL as an authoring environment

  • Mental Model

    • in vvvv it’s all about data flow

    • TODO:

        1. Find the different mental models / design patterns in VL and document them properly. Templates?
        1. Is there one high-level mode missing?
        • e.g. Automatic Spreading, Lazy Evaluation, Interpreter

    • Navigation Structure should support the mental model

      • Solution Browser for code

        • Show address bar

      • Object Graph Browser for the living nested Process Nodes

        • Show breadcrumbs

        • Can we name process nodes? → e.g. breadcumb: Level1->ActorB->LeftFoot

        • Can we see in which vvvv node we are?
          → Use “Descriptive Name” of vvvv node for that?

        • Within the patch editor you see the data of the current instance
          * Data in Tooltips, IOBoxes (& later on Inspector): beautify

      • Document patch

        • Either
          • Indicate that it works differently (e.g. via Background color)
          • Allow Dependencies as nodes
        • Or
          • Make it a regular entry point (Useful for Example patches)
            → Simplicity

    • Design pattern for working with mutable types is more advanced than pure data flow.

    • More UX ideas to make it look simpler

      • discuss: hide “Class”, “Interface” (…)
      • discuss: hide more nodes from Node Browser
        • Member Operations of Mutable Types

    • Make the UX more consistent (menu style, indicators on nodes)

Thank you for all the insights and very productive discussions!

4 Likes