LINK Topics - 5) Authoring Environment

[a_a_a_a]

5) Authoring Environment

vvvv is a multipurpose toolkit, VL is even much more general. Too general for some. What future target groups can be identified, what are their specific needs, how to best work towards those.

[baxtan]

One would need to understand the properties and characteristic of a toolkit to comfortably keep using it.
On one hand abilities and functionalities, Community and forums, UI and UX, etc… and on the other hand the narrative it offers to think with!
One can get in and get addicted to vvvv’s attitude, once they know how it wants them to behave with.
I found VL different. It is transparent. Its something I’d call under the hood, not only under vvvv’s hood but possibly many other similar toolkits.
What interesting to picture are:
How might its narrative come near?
Does it require a certain structured language when an absolute beginner is willing to learn it?

[baxtan]

DAY 1

The following text is an abstraction of keywords/topics/thoughts for this category in LINK.

Needs to be mentioned that:
*There was often drifting back and forth on VL & vvvv’s authoring environment in general.
**There will be a conclusion after the last meeting where credits of comments and ideas will be mentioned.

//General

• Documentation
• Use cases for vvvv & VL
• Concept formation: defining differentiation and similarities for vvvv & VL

//VL related

• Getting VL to higher level(defining a road-map)
• Integrating following items:
  a)IObox
  b)Interface
  c)Importing assets
  d)Multiple windows
  e)Patching structure
  f)Accessibility for beginners, playfulness for advanced users
  g)What’s the best way[out of many] to achieve a goal?

[gregsn]

concerning assets and editing them: Thirdparty extensions

[baxtan]

DAY 2

The second session was mostly around VL and often exampling how participant would imaging or expect to handle different scenarios in VL in comparison with vvvv.

Topics:

• Orientation for patching
  a) In VL dependencies should be taken care.
  b) Dependencies can be in a document patch as nodes.
  c) Patching in a root patch of a document> double click opens an “instance”.
  d) Idea of having a “main document”
  e) Document patch could look different.
  f) Visual tags for different patches.

• Navigation in project

• Project structuring

• Saving
  a) Easier readability for menu in VL
  b) Possibility for saving the lay out as a “user lay out file” which opens the program as it’s customized lay out.

Topics for next(3th) session:

• Ideas of authoring environment in VL:

a) “Editors” are placed in the root>> the lay out of those editors are saved in the “user lay out file”. within projects you can have instances of them (e.g: Timeline instance which can be selected in that editor)

b) A “Patch Editor” as another example of such editor with defined and/or saved ‘properties’(e.g. of properties: position, tabs[zoom level, patch address, etc…])

c) “Inspektor”

d) “Previews”

[gregsn]

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?
    • 2. 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!