Activity Layout

[pmattmann]

Activity Layout

Dies wird wieder zum Thema, da es die Entität ActivityType nicht mehr gibt. ActivityType hat bisher das zu verwendende Layout bestimmt. Bisher haben wir nur ein Layout "General", welches alle ActivityContents in einer bestimmten Reihenfolge linear darstellt.
Im PR #833 wurde das Layout "General" fixiert (da ActivityType nicht mehr existiert).

In diesem Issue soll diskutiert werden, wie zukünftig mit der Idee Activity-Layouts umgegangen werden soll.

Ein Layout: General

Als erste muss die Frage beantwortet werden, ob ein allgemeines Layout ausreichend ist.
Falls Ja, kann das Issue geschlossen werden.
Falls Nein, sollen hier einige Ideen diskutiert werden.

Varianten

Falls es mehrere Layouts geben soll, stellt sich die Frage der Granularität. Hier die Möglichkeiten

• Layout pro ActivityCategory
• Layout pro Activity

Vor- und Nachteile anhand der Anwenungsfälle (Desktop, Mobile, Print) pro Variante:

Anwendungsfall	Layout pro ActivityCategory	Layout pro Activity
Allgemein	➕ Einfacher in der Handhabung	➕ ActivityContent-Instancen könnten individuell platziert werden
Desktop (Spalten Layout sinnvoll)	➖ Gleiches Layout für alle Activities einer Category ➕ Für Leser einfacher, da alle Activities einer Category gleich aussehen	➕ extrem flexibel
Mobile (Nur 1-Spalten Layout)	➖ Gleiche Reihenfolge für alle Activities einer Category	➕ flexible Reihenfolge
Print (Spalten Layout sinnvoll)	➖ Gleiches Layout für alle Activities einer Category ➕ Für Leser einfacher, da alle Activities einer Category gleich aussehen	➕ extrem flexibel ➖ unklar wie Benutzer-Handling funktioniert (evtl. Desktop-Layout verewnden? Ist das korrekt?)

Folgende scheinen für mich gewichtig:

• ➕ Pro ActivityCategory ist einfacher in der Handhabung
• ➕ Pro Activity ist extrem flexibel
  • Die Flexibilität hat bei Desktop & Print viel gewicht / bei Mobile-Layouts weniger. Diese sind trivial (1-Spalten-Layout mit Reihenfolge)
  • Bei Desktop & Print geht es darum, ein Layout zu gestallten, welches auch gut aussieht, wenn bestimmt ActivityContents fehlen.

Möglicher Ausweg
Damit verschiedene Activities der gleichen ActivityCategory verschiedene Layouts haben können, könnte ich mir auch eine Layout-Collection pro ActivityCategory vorstellen, aus welcher pro Activity gewählt werden kann.

Dank einem möglichen Ausweg welcher einen grossen Teil der Flexibilität zurück bringen kann, wird hier die einfachere Variante weiter verfolgt.

Layout pro ActivityCategory

Auf der Ebene ActivityCategory ist unklar, welche und wieviele ActivityContents es geben wird. Es können daher "nur" ContentTypes platziert werden. Alle ActivityContents des gleichen ContentTypes werden an derselben Stelle dargestellt.
Die Reihenfolge der ActivityContents soll auf der ebene Activity definert werden können.

Es gibt somit zwei Themen zu beleuchten:

• Anordnung der ContentTypes
• Reihenfolge der ActivityContents

Anordnung der ContentTypes

Das Problem der Anordnung stellt sich für alle 3 Anwendungsfälle:

• Desktop
• Mobile
• Print

Für Desktop und Print sind Mehr-Spalten-Layouts denkbar. Bei Mobile sollte das definieren der ContentType-Reihenfolge ausreichend sein.

Desktop & Print

Hier sind komplexere Layouts denkbar. CSS-Grids könnten hier weiter helfen.
Im Falle von CSS-Grids müssen zwei Informationen erfasst werden:

• Grid-Layout
• Platzierung von ContentTypes im Grid

Grid-Layout

Hier würde ich möglichst einfach vorgehen.

• V1) Vordefinierte Layouts
  • 1 Spalte
  • 2 Spalten 30% / 70%
  • 2 Spalten 50% / 50%
  • 2 Spalten 70% / 30%
  • 3 Spalten ...
  • ...
• V2) Spalten-Editor

Platzierung von ContentTypes

Im Falle von CSS-Grids ist dies im Prinzip nur eine Reihenfolge mit allfälligen Zusätzinformationen (Col-Span; Row-Span).
Die Herausforderung hier besteht darin, dies dem Benutzer verständlich zu machen.

Mobile

Technisch reicht hier eine sortierte Liste der ContentTypes. Die Liste definiert, in welcher Reihenfolge die ContentTypes bei der Anziege einer Aktivität erscheinen sollen.
ContentTypes, welche nicht in der Liste enthalten sind (jedoch in der Aktivität vorhanden sind) werden am bei der Anzeige am Ende hinzugefügt (sortiert nach ContentType-Id (TBD)).

Datenmodel

Wenn möglich, soll das Backend nichts über das Frontend "wissen". Es soll daher nicht die Layout-Struktur eins zu eins in der Datenbank abgebildet werden.

Ich schlage daher folgendes Datenmodel vor:

Pro ActivityCategory können mehrere ActivityLayouts erfasst werden (anfangs vielleicht nur eines).
Beim erstellen eines neuen Lagers werden diese (analog zu ActivityCategory) von ActivityLayoutTemplate kopiert.

Ein ActivityLayout umfasst 3 Konfigurationen (Desktop, Mobile, Print). Damit im Backend keine Wissen vom Frontent verborgen ist, schlage ich vor, dass dies 3 JSON-Felder sind.

Layout-Data

{
  "columns": [
    {
      "width": "200px"
    },
    {
      "width": "10%"
    },
    {
      "width": "auto"
    }
  ],
  "contentTypes": [
    {
      "contentType": "Storycontext"
    },
    {
      "contentType": "Storyboard"
    }
  ]
}

Notizen:

• Für Mobile-Layout darf Key "columns" fehlen; falls doch vorhandne, wird dieser ignoriert.
• Falls Mobile-Layout leer, wird Desktop-Layout verwendet (fallback)
• Falls Print-Layout leer, wird Desktop-Layout verwendet (fallback)

Vergleich zu heute:
Heute wird das Layout durch General.vue bestimmt.
Dies definiert im wesenltichen die Reihenfolge der ContentTypes. Ansonsten enthält es keine wesentliche Information.
Es sollte also nichts 'vergessen' gegangen sein.

Reihenfolge der ActivityContents

Hierzu soll auf der Entität ActivityContent die Spalte Pos ergänzt werden. Die ActivityContents werden sortiert nach der Spalte Pos dargestellt.

[carlobeltrame]

Danke fürs Aufbringen des Themas! Ich habe mich mal versucht grossflächig umzusehen wie andere Software dieses Problem angeht. Das Resultat ist leider: Es wird nur selten flexibel gelöst. Hier ein paar Inspirationen, kategorisiert nach Approaches:

Fixes Layout mit vorgegebener Anordnung für alle möglichen Contents

Die Seite ist in fixe Bereiche eingeteilt, alle Komponenten sind bereits einem fixen Ort darauf zugeteilt. Nicht verwendete Komponenten könnten optional versteckt werden, sodass sie keinen Platz auf der Seite einnehmen. Beispiele:

• eCamp v2 Blockinhalte

Lineares Layout

Alle vorhandenen Komponenten sind untereinander. Die Reihenfolge der Komponenten kann vom User bestimmt werden. Beispiele:

• Vorgeschlagener Approach für Mobile von @pmattmann
• die noch nicht öffentlichen MS Fluid Framework Components
• Coda und Notion - möglicherweise sind abschnittweise mehrere Spalten möglich
• Strapi Dynamic Zones

Komponenten mit mehreren fixen möglichen Grössen

Komponenten können in einem fixen Grid platziert werden und haben eine von n vordefinierten Grössen, welche der User umschalten kann. Beispiele:

• Evernote Home
• swissmeteo App
• Touch Timetable in der SBB Mobile App
• Vorgeschlagener Approach für Desktop und Print von @pmattmann (konfigurierbare colspan und rowspan sind die fixen Grössen, plus die Spaltenbreiten könnten definiert werden)

Layout-Komponenten

Die Applikation bietet mehrere Container-Komponenten an die mehrere Bereiche haben in denen Komponenten platziert werden können. Beispiele:

• Wordpress Gutenberg Post Layouts Plugin
• JSON Forms Layouts
• Java Swing Layouts
• elemental list in Silverstripe Elemental

Grid Layout

Habe ausser CSS3 selber noch keine Software gefunden die dies dem User direkt so anbietet (CSS Grid ist aber auch noch nicht so alt). Am nächsten kommen dem wohl die Komponenten mit mehreren fixen möglichen Grössen wie oben beschrieben.

Vorschlag

Von den obigen Optionen gefällt mir die Variante "Layout-Komponenten" am besten, denn sie erlaubt es, bei Bedarf mit machbarem Zusatzaufwand alle anderen Layouts ebenfalls abzubilden. Konkret schlage ich folgendes vor:

• ActivityContents sind innerhalb einer Activity grundsätzlich linear geordnet (z.B. via pos Property).
• Es existieren spezielle ActivityContents, die nicht direkt der Erfassung von Inhalten dienen, sondern Slots für weitere ActivityContents enthalten. Denkbar wäre zum Beispiel ein Dreispalten-ActivityContent, ein HolyGrail-ActivityContent, ein PBS-Blocklayout-ActivityContent, ...
• Die Slots eines ActivityContents sind eindeutig geordnet, können also nummeriert und durch-iteriert werden
• Innerhalb eines Slots sind die ActivityContents ebenfalls linear geordnet (z.B. via pos Property)
• Es steht dem jeweiligen Frontend (Desktop, Print, Mobile, third-party) frei, wie diese Layout-Komponenten gerendert werden. Die Mobile-Ansicht kann z.B. wählen, die ActivityContents in einer Zweispalten-Layout-Komponente trotzdem einfach linear untereinander anzuzeigen. Lineare Anzeige wäre wohl auch ein sinnvoller Fallback, falls eine Layout-Komponente mal in einem Frontend nicht implementiert ist.
• Aus praktischen Gründen wäre es wohl gut, wenn wir standardisieren, unter welcher Beziehung die Slots von Layout-Komponenten abrufbar sind. Zum Beispiel: myLayoutActivityContent.slots[0][1] könnte der zweite ActivityContent im ersten Slot von myLayoutActivityContent sein.
• Denkbar sind auch "hybride" ActivityContents, die teils Inhalte enthalten können und teils Slots für Sub-ActivityContents haben. Ein triviales Beispiel wäre ein ActivityContent der eine Überschrift sowie einen Body-Slot mit weiteren ActivityContents enthält. So oder so müssen wohl einige Layout-ActivityContents auch eigene Daten speichern können, z.B. die Breiten der Spalten bei einem GridLayout-ActivityContent.
• Damit das Ganze mit dem Template-System funktioniert, müssten wir vermutlich defaultInstances auf dem ContentTypeConfig ablösen durch eine materialisierte, klonbare ActivityContent-Struktur ohne ausgefüllte Inhalte. Die Diskussion dazu steht noch aus, und am letzten Meeting hatten wir mündlich diskutiert dass wir Post-MVP möglicherweise sowieso in diese Richtung gehen.

Ein Mockup, wie das Ganze für den User aussehen könnte:

Vorteile

• Für die Implementation können wir mit einzelnen Layouts beginnen und später nach Bedarf laufend ausbauen, i.e. kein Big Bang
• Weniger / kein JSON in der DB. Je nach dem ob alle Layout-ActivityContents hintendurch dieselbe Strategy zum Speichern verwenden (dann bräuchten wir JSON für Details wie Spalten-Breiten etc.) oder möglicherweise separate Strategies (dann kein JSON in der DB)
• ActivityContent-System ist bereits vorhanden, kein Neubau von Meta-System mit LayoutTemplates etc. nötig. Stimmt nicht ganz, ein Umbau ist möglicherweise trotzdem nötig um auf standardisierte Art und Weise eine Baumstruktur von ActivityContents zu speichern.
• Im Frontend passt die verschachtelte Architektur gut zum Aufbau mit Vue Components

Nachteile

• Inhalt und Layout werden vermischt. Ich sehe das aber nur bedingt als Nachteil, weil ich die Layout-ActivityContents eher als "Richtlinien" des Users sehe, wie die Inhalte visuell gruppiert werden sollen, und das Frontend immer noch entscheiden kann wie es dann wirklich gerendert wird. Diese Variabilität der Anzeige je nach Frontend haben wir so oder so bereits vor, zum Beispiel wird der Print Renderer vielleicht Kommentare oder Notizen gar nicht rendern.

[pmattmann]

Ich finde die Idee sehr spannend.
Ich habe eine technische Frage, für welche ich mir noch eine elegante Lösung wünschen würde.
ActivityContents, welche innerhalb einer anderen ActivityContent drin stecken, dürfen dann auf der äussersten Schicht nicht gerendert werden. Wie kann die äusserste Schicht dies erkenne?

Erste einfache Idee:

• ActivityContent-Propery "renderOnRoot"

[pmattmann]

Für mich stellt sich noch eine zweite Fragen.
Ich glaube, man sollte bereits auf der Ebene ActivityCategory ein Layout vorgeben können. Andernfalls muss jede Activity neu gelayoutet werden.

Hier stellt sich ebenfalls die Frage, wie dies abgebildet werden soll.

[carlobeltrame]

Erste Frage

ActivityContents, welche innerhalb einer anderen ActivityContent drin stecken, dürfen dann auf der äussersten Schicht nicht gerendert werden. Wie kann die äusserste Schicht dies erkenne?

Erste einfache Idee:

* ActivityContent-Propery  "renderOnRoot"

Gute Frage. Auch denkbar wäre es, in jedem ActivityContent den Parent zu speichern, oder null wenn es direkt an der Activity hängt. Aber mir fällt momentan kein Use Case ein wo wir diesen Parent brauchen würden und er uns einen Vorteil über ein einfaches Flag bieten würde. Das scheint mir aber auch nach einem Detail, welches ich demjenigen der es implementiert überlassen würde, vielleicht taucht dann ja noch ein Argument für die eine oder andere Variante auf.

EDIT: Da es sich um eine baumartige, theoretisch beliebig tiefe Struktur handelt, wird es so oder so nötig werden, die Struktur abzuspeichern und wieder aus der Datenbank zu holen. In meinem UML Diagramm unten habe ich ja auch eine Beziehung von ActivityContent auf sich selber eingefügt, das ist ja genau der parent link.
Bei grossen Baumstrukturen in relationalen Datenbanken performt allerdings bekannterweise nested set besser als parent-links. Dazu gibt es auch bereits fertige Implementationen [1] [2], von denen man zumindest abschauen könnte. Allerdings müssten wir diskutieren, wie diese Daten dann in der API angeboten werden: Als flache Liste sodass alle ActivityContents auf einmal geladen werden können? Oder bereits in der verschachtelten Struktur, mit _embedded bzw. _links?

Zweite Frage

Ich glaube, man sollte bereits auf der Ebene ActivityCategory ein Layout vorgeben können. Andernfalls muss jede Activity neu gelayoutet werden.

Hier stellt sich ebenfalls die Frage, wie dies abgebildet werden soll.

Da stimme ich absolut zu. Meinen Vorschlag hierzu hatte ich versucht in folgendem Abschnitt zu beschreiben:

Damit das Ganze mit dem Template-System funktioniert, müssten wir vermutlich defaultInstances auf dem ContentTypeConfig ablösen durch eine materialisierte, klonbare ActivityContent-Struktur ohne ausgefüllte Inhalte. Die Diskussion dazu steht noch aus, und am letzten Meeting hatten wir mündlich diskutiert dass wir Post-MVP möglicherweise sowieso in diese Richtung gehen.

Vielleicht hilft ein rudimentär abgeändertes UML-Diagramm (Details gern offen zur Diskussion).

Ich habe darauf die DefaultInstances aus ContentTypeConfigTemplate und ContentTypeConfig entfernt, sowie die neuen Entities ActivityCategoryTemplateContent sowie ActivityCategoryContent hinzugefügt (plus slot und pos und rekursive relation auf ActivityContents und den parallelen Entities). Die ActivityCategoryContent und ActivityCategoryTemplateContent entities sind sehr ähnlich wie ActivityContents, nur werden sie in den meisten Fällen keine echten Inhalte drinhaben (höchstens verschachtelte ActivityCategoryContents um eben die Struktur eines neuen Blocks vorzugeben). Also soll heissen, zum Beispiel die ActivityCategoryContents für einen LS-Block könnten ein Storyboard mit drei (leeren) Abschnitten und ein leeres oder generisches SiKo enthalten, und diese beiden könnten vielleicht in einem Zweispalten-Layout sein:

Langsam stellt sich hier die Frage, wie weit es sich lohnt, für all diese Klassen Doppelgänger für das Templating zu führen. Vielleicht wäre es auch früher oder später einfacher, die Template-Versionen der Entities mit den "echten" Versionen zusammenzuführen. Ist aber eine unabhängige Diskussion.

[pmattmann]

Mir gefällt das vorgeschlagene Datenmodel relativ gut. Ich möchte dennoch eine Vereinfachung zur Diskussion stellen:

Edit

ActivityCategoryContentTemplate / ActivityCategoryContent / ActivityContent

• Baumstruktur
  • Parent übergeordneter Knotenpunkt
  • Position platzierung innerhalb vom übergeordneten Knotenpunkt
    • Biespiele: left#1 / middle#3 / right#2
    • Ein Feld sollte hier reichen. Slot + Pos scheint mir sehr spezifisch. Falls ein struktureller ContentType für die Anordnung andere Infos bedarf, ist ein Feld generischer.
• Required
  • Pro ActivityCategoryContent mit required-Flag muss ein ActivityContent vorhanden sein
    • So kann von einem ContentType auch zwei/drei Instanzen gefordert werden
  • Strukturelle ContentTypes sollten nicht required sein
• Multiple
  • Ist Entfernt. Wieso soll ein ContentType nur einmal erlaubt sein?

ContentType

• Kann Struktur oder Inhalt enthalten (theoretisch auch beides)
  • Struktur
    • ContentType ist verantwortlich alle seine direkten Nachfolger (Parent-Zeiger) darzustellen
  • Inahlt
    • ContentType ist verantwortlich seinen Inhalt darzustellen

[manuelmeister]

Meeting Discussion

• Variante Cosinus:
  Edit
• position (als json) wird gemanaged von Parent auf ActivityCategoryContent / ActivityCategoryContentTemplate (slot gibt es nicht mehr)
• multiple & required weg
• flag für rein Sturkurelemente

xxxTemplate als Naming

[pmattmann]

Lange rede, kurzes UML....

Edit