barbalex
commented
3 years ago Also grundsätzlich: sehr schwierig. Das Problem ist, dass der Strukturbaum von der URL abhängig ist und umgekehrt. Die URL ist ein zentrales Element der App. Da hängt vieles zusammen.
Bei apflora haben wir an einem einzigen Ort etwas Ähnliches: wo die Ziele pro Jahr zusammengefasst werden. Das hat geschätzt:
- 15 mal mehr Arbeit für die Erst-Implementation gegeben, als "normale" Strukturen
- Haufenweise Probleme, die später (oft nur von mir) entdeckt und behoben wurden
- Wenn ich raten müsste, wo am ehesten noch unbemerkte/nicht gemeldete Probleme liegen: ich würde auf diesen Knoten tippen
- Ich hatte schon mehrmals Ideen, wie der Aufbau des Baums modularisiert werden könnte. Das wäre die Methode, um die Menge benötigten Codes drastisch zu reduzieren. Und das Hinzufügen neuer Äste zu vereinfachen. Aber das ist nur machbar, wenn der Baum natürliche Strukturen innerhalb der Daten abbildet. Die von dir jetzt erwähnten sind das nicht. Im Fall von apflora scheiterte das an dem erwähnten Knoten
- Ich kann dir nicht sagen, wie oft ich es bereut habe, dass wir das so implementiert haben
Ein Beispiel, dass durch die Gruppierung von Listen nach dem Inhalt einzelner Felder VIEL schwieriger (und damit auch leistungshungriger) wird: Filtern. Wenn ihr einen Filter setzt, ist es sehr aufwändig, die gruppierte Liste zu filtern. Wenn ihr z.B. nach Jahr gruppiert. Und dann nach etwas anderem filtert: Dann muss zunächst mal herausgefunden werden, welche Jahre im gefilterten Satz von Listen-Elementen existieren. Bevor der Navigationsbaum aufgebaut werden kann. Ist der Baum nach logischen Einheiten der Datenstruktur aufgebaut, kann man hingegen einfach den Filter übernehmen, der auf dieser Tabelle gesetzt wurde. Womit sich die ganze Filtrierung modularisieren lässt, was sie heute auch ist. Und sonst nicht möglich wäre.
Grundsätzlich ist der Navigationsbaum ein RIESENDING:
- Der Code, der seinen Aufbau steuert, ist hier enthalten. Schau mal, wie viele Zeilen das sind: 2'192!
- Dazu kommt Code für jeden Knoten im Baum, also so viele Dateien, wie es Knoten gibt. Dieser Code ist oft nur 15 bis 30 Zeilen lang. Aber das läppert sich zusammen. Da es offenbar 91 Knoten gibt, dürfte das noch mehr Code sein, als oben erwähnt
- Zusätzlich gibt es Code, der den Zustand des Baums verwaltet (welche Knoten sind sichtbar, welche sind aktiv, welche sind im aktiven Strang)
Nicht zu vergessen: Jede zusätzliche Stufe bedingt auch zusätzliche Listenformulare, weil man mobil auch ohne den Navigationsbaum navigieren können soll.
Plus: zusätzliche Stufen heissen auch: Mehr Klicken (statt Scrollen oder Filtern), um zum Ziel zu kommen. Bzw. in der Mobilansicht: mehr Formulare, durch die man sich bewegen muss.
Änderungen wollen daher gut überlegt sein. Und finanziert. Machbar ist hingegen vermutlich fast alles. Zumindest kannst du sagen, was ihr ideal fändet. Und ich kann überlegen, ob es einen vernünftigen Weg gibt, das zu implementieren.
Wir sollten offen sein, auch andere Lösungen zu finden. Daher ist es wichtig, dass ihr klar ausdrückt, was aktuell mühsam ist. Dazu ist es wichtig zu wissen, wie ihr arbeitet. Und wir offen überlegen, wie das verbessert werden kann. Und ich darum auch mitdenken kann. Denn mir fällt vielleicht etwas ein, an das ihr nicht denkt.
Spontan habe ich den Eindruck: Am Einfachsten wäre es, wenn die Filterung dafür optimiert werden könnte. Aber ich greife schon vor, was gefährlich ist.
jmenzi
Seraina1
Der Strukturbaum ist grundsätzlich gut, jedoch fehlt eine gewisse Übersicht beim Ausklappen der Äste. Hier erscheinen lange Listen mit viel Information. Diese Informationen müssten irgendwie gebündelt und übersichtlicher dargestellt werden können. Wir erarbeiten aktuell gerade einen Vorschlag, welchen wir dir bald unterbreiten werden. Dazu noch eine Rückfrage, wie einfach ist es neue Unteräste einzufügen? Beispielsweise eine Gruppierung gewisser Daten nach Jahreszahl, Gemeinde oder Art?