Ansel Design

Ansel wird designt, nicht gehackt. Hacker mögen es genießen, “zu arbeiten” an dem beschleunigten Untergang von Darktable, indem sie seine technische Schulden  erhöhen.

Was ist Design?

Design ist ein Prozess, bei dem eine Methodik entwickelt wird, um eine technische Lösung für ein menschliches Problem zu finden. Der Designprozess soll zur passendsten Lösung führen und gleichzeitig dem natürlichen Drang widerstehen, sich vorschnell auf die erste oder bequemste Idee zu stürzen.

Ohne Anforderungsdefinition und Design ist Programmierung die Kunst, Bugs in eine leere Textdatei einzufügen.

1. Design beginnt mit einem Use-Case: eine definierte Aufgabe, die von einem bestimmten Benutzer in einem bestimmten Zeitrahmen erreicht werden soll. Gibt es keinen Use-Case, dann gibt es kein zu lösendes Problem, also halte dich von deinem Code-Editor fern.
2. Design erfordert Kenntnisse über den Zielbenutzer: Ausbildung/Training, Niveau von handwerklichem Können/Mastership, etc.
3. Design erfordert, die Bedürfnisse zu verstehen: Im Kontext von Ansel wird oft Kunstgeschichte und Kenntnisse der Dunkelkammerfotografie benötigt,
4. Sobald das Problem und der Benutzer verstanden sind, muss Design spezifizieren:
   • die erwarteten Funktionalitäten der Lösung,
   • den Umfang der Lösung (wo in der Lebensdauer eines Bildes steht die Lösung?),
   • die Einschränkungen und Anforderungen der Lösung (Unterstützung von Standards, Möglichkeit zur Verarbeitung von n Bildern pro Zeiteinheit, etc.),
   • eine Reihe von Tests, die zur Validierung der Qualität der Lösung abgeschlossen werden müssen, um unproduktive Meinungen, Vorurteile und Subjektivität im Validierungsprozess zu begrenzen.
5. Erst dann können die Entwürfe und das Brainstorming beginnen, gefolgt von Prototypen.

Was ist Design nicht?

Design befasst sich nicht mit:

• vagen Anforderungen eines undefinierten, zukünftigen oder fantasierten Benutzers,
• “es wäre cool, wenn…” (so erstellt man inkonsistente Plugins-Sammlungen),
• was die Leute mögen (für alles, was jemand mag, wird man jemand finden, der es hasst),
• was die Leute denken, dass sie wollen (es ist oft nicht das, was sie brauchen),
• magischen Tech-Buzzwords, die “die Zukunft sind” und daher überall eingebaut werden müssen, unabhängig von ihrer Relevanz oder Machbarkeit (ja, ich spreche von KI, NFT, Blockchain etc.)

Was ist gutes Design?

Gutes Design ist:

• minimalistisch,
• robust,
• zukunftssicher,
• generisch und verallgemeinert,
• mit begrenzten Ressourcen wartbar,
• durch Wissenschaft informiert,
• kompatibel/interoperabel mit Industriestandards.

Da Ansel eine Workflow-basierte Anwendung ist, berücksichtigt gutes Design auch den Workflow als Ganzes und wo sich das Problem/die Lösung darin befindet.

Wie wird gutes Design erstellt?

Um den Designprozess zu unterstützen, sollte die Kommunikation prägnant und fokussiert bleiben, und die an diesem Prozess beteiligten Personen sollten sicherstellen, dass sie ein angemessenes Verständnis der Theorie und des technischen Hintergrunds im Bezug auf den Problem- und Lösungsscope haben.

Es sollte betont werden, dass, obwohl das Projekt softwaregesteuert ist, nicht alle Lösungen das Coden beinhalten. Manchmal (oft?) reicht eine bessere Ausbildung oder Dokumentation aus.

Der Zweck eines gesunden Designprozesses ist es, zu vermeiden, dass die Lösungen zu früh mit einem bevorzugten Design/Technik beeinflusst werden und sich in den technischen Details zu verlieren, sondern immer zu den Grundprinzipien zurückzukehren: die Nachbearbeitung möglicherweise großer Stapel von Rohbildern für alle Arten von Ausgabemedien.

Dies wird dadurch gestützt, dass Benutzer selten ihre eigenen Bedürfnisse kennen, oder vielmehr, die geäußerten Bedürfnisse selten der Kern dessen sind, was sie eigentlich wollen. Die schwierige Aufgabe des Designs besteht darin, durch die Äste zu schneiden, um zur Wurzel zu gelangen, da die Lösung des eigentlichen Problems normalerweise zu eleganteren, generischeren und minimalistischeren Lösungen führt.

Probleme kommen zuerst

Der erste Schritt im Ansel-Designprozess besteht darin, einen Feature-Request im Community Forum einzureichen. Feature-Requests wurden von Github auf das Forum verlegt, da diese Plattform nicht einladend für Nicht-Programmierer und Nicht-Englischsprachige ist (obwohl das Forum nur Französisch und Englisch unterstützt).

Dieser Feature-Request konzentriert sich auf das zu lösende Problem und unterlässt es, eine Lösung vorzuschlagen. Das Problem wird in Bezug auf Aufgaben im Workflow eines Fotografen oder den erwarteten visuellen Ausgang des bearbeiteten Bildes definiert, also im Hinblick auf das zu erreichende Endziel, nicht im Hinblick auf die vermuteten erforderlichen Werkzeuge oder technischen Details. Dies könnte zu einer Diskussion führen, um die Wurzeln des Problems zu ergründen, die oft gut verborgen unter dem liegen, was der Benutzer für sein Problem hält.

In diesem Stadium wird kein Lösungsvorschlag akzeptiert.

Lösungen kommen als Zweites

Wenn die Definition und der Umfang des Problems zwischen den beteiligten Diskussionsteilnehmern vereinbart wird, können Lösungsvorschläge gemacht werden. Weitere Diskussionen könnten erforderlich sein, um die Nachteile und Vorteile jeder Lösung zu bewerten, was zur Annahme der besten Lösung auf Prinzipienführung führt. Lösungen werden durch ihre Funktionalitäten definiert (also, was sie tun sollten), nicht durch ihre Technologie oder Mittel (wie sie es tun sollten).

In diesem Stadium wird kein Prototypvorschlag akzeptiert.

Die angenommenen Lösungen führen zu einem neuen Eintrag im Projektmanagement-Kanban-Board .

Sie könnten einer theoretischen und technischen Recherche zur Beurteilung der Machbarkeit unterliegen, in diesem Fall werden sie in die Zu erforschen Spalte des Kanban-Boards einsortiert. Die Forschungsergebnisse werden dem ursprünglichen Thema hinzugefügt, bis die Machbarkeit der Lösung bewiesen ist. Wenn dies der Fall ist, wird das Thema in die “Zu erledigen” Spalte des Kanban-Boards verschoben.

Angenommene Lösungen könnten direkt in die Zu erledigen Spalte einsortiert werden, wenn nur bekannte Werkzeuge und Techniken erforderlich sind.

Idealerweise sollten die zu testenden Punkte und das Testverfahren zur Validierung des Prototyps geschrieben werden, noch bevor ein funktionierender Prototyp vorliegt. Zumindest sollten die Tests sicherstellen, dass es keine Regressionen bei verwandten Funktionen und Werkzeugen gegeben hat.

Prototypen kommen als Drittes

Nur die im Kanban-Board in die “Zu erledigen” Spalte einsortierten Themen werden bearbeitet, entweder von mir oder von jemandem, der sich ihnen widmen möchte.

Der Prototyp der Lösung wird in einem Pull Request eines Themenzweigs vorgeschlagen, der auf das ursprüngliche Thema verweist. Themenzweige müssen auf den master Zweig neu gebased werden, z. B. git rebase upstream master, oder wenn du deinen Zweig lokal mit neuen Master-Commits aktualisierst, git pull upstream master --rebase ausführen oder Git global einrichten , um durch rebase statt merge zu ziehen. Das stellt sicher, dass der Branch-Verlauf mit minimalem Aufwand sauber bleibt und der master Verlauf ebenfalls sauber bleibt, wenn dein PR zusammengeführt wird.

Wenn der Prototyp-Pull-Request überprüft wird und den Codequalitätsstandards entspricht (siehe unten), während er die Spezifikationen der angenommenen Lösung erfüllt, wird er genehmigt und automatisch in die “Zu testen/validieren” Spalte des Projektmanagement-Kanban-Boards  einsortiert.

Validierung kommt als Viertes

Genehmigte Pull Requests werden früh im candidate oder dev Zweig für Tests zusammengeführt, je nachdem, ob sie die Bearbeitungsgeschichte von Bildern unterbrechen könnten (indem neue Modulparameter hinzugefügt oder die Datenbankschemata geändert werden). Dieser Zweig wird immer der master Zweig mit allen ausstehenden Pull Requests zur Validierung sein. Dies soll das Testen von Personen erleichtern, die nicht unbedingt up-to-date mit der manuellen Zusammenführung von Git-Zweigen sind. Im Gegensatz zum dev Zweig sollte candidate deine Bearbeitungen nicht zerstören.

Wenn nach einiger Zeit keine Fehler oder Unterbrechungen gemeldet werden und der Prototyp seinen ursprünglichen Zweck korrekt erfüllt, wird er in master zusammengeführt und das zugehörige Thema wird abgeschlossen und in die “Erledigt” Spalte des Projektmanagement-Kanban-Boards  verschoben.

Wenn sich der Prototyp als unbefriedigend erweist, kann er abgelehnt werden und ein anderer muss entwickelt werden.