Das ist ein Meinungsartikel.
Ich habe mal wieder etwas auszusetzen. Es geht um die Todo-Anwendung List von Vlad Krupinski. Dabei handelt es sich um eine einfache und sehr schöne Aufgabenverwaltung, basierend auf Gtk4 und Libadwaita. Nun gut, solche Anwendungen sehen auf dem GNOME-Desktop immer schön aus. Die Produktivitäts-App läuft unter der MIT-Lizenz, ist in Python geschrieben und besteht aus ca. 400 Zeilen Code. Man findet sie auf Flathub.
Bevor ich mit dem Gejammer beginne, möchte ich zuerst die Features und positiven Aspekte dieser Anwendung betonen. Was List kann, erkennt man im Titelbild ohne, dass ich etwas dazu schreiben muss. Man kann Aufgaben und Unteraufgaben anlegen. Ausserdem können erledigte Tasks abgehakt und die Hauptaufgaben können eingefärbt werden. Zudem kann in den Einstellungen zwischen hellem, dunklem und dem System-Thema umgeschaltet werden. That's it, folks!
Was ist gut finde
Aufgrund der eingeschränkten Funktionalität und der vorbildlichen UX/UI, dürfte die Anwendung viele Anwender:innen ansprechen, die nach einer ganz einfachen und hübschen Aufgabenverwaltung suchen. Das Einfärben der Hauptaktivitäten halte ich List zugute; das gefällt mir.
Da List in Python geschrieben ist und im Wesentlichen aus zwei Dateien besteht, die nur 400 Zeilen Code enthalten, eignet sich die Anwendung als Lernbeispiel für Python, Gtk4, Libadwaita und eine Flathub-Publikation. Das ist für mich der grösste Vorteil. Danke Vlad! Wir brauchen noch viel mehr Boilerplate Anwendungen, die dem Lernen dienen.
Was mir nicht gefällt
Ich finde es immer quälend, wenn ich mich über Anwendungen kritisch äussere. Deshalb versuche ich meine Kritik so objektiv wie möglich zu schreiben.
Die Beschreibung auf GitHub ist nicht hinreichend. Wer Freie Software entwickelt, sollte stolz darauf sein. Drei Sätze zu Clone, Install, Run zeugen nicht vom Stolz des Entwicklers für seine Software. Den Anwendern ist damit auch nicht geholfen; insbesondere nicht den Einsteiger:innen. Meine Daumenregel ist: "Wenn deine Dokumentation kürzer als dein Code ist, stimmt etwas nicht."
Da ist noch etwas, was mir nicht gefällt. Lohnt es sich, eine Anwendung zu programmieren, die man mit jedem Texteditor umsetzen kann? Ich bin mir nicht sicher, ob das wirklich ein Kritikpunkt ist. Sobald es eine Anwenderin gibt, die sagt, hey, das ist eine ganz tolle App, mit der ich meine Todos organisieren kann, ziehe ich meine Kritik gerne zurück. Dann wäre es vielleicht unsere Aufgabe der Person zu vermitteln, dass man ein solch triviale Aufgabe mit einfacheren Mitteln lösen kann. Wo liegt die Grenze zur Trivialanwendung?
Mein dritter Kritikpunkt bezieht sich auf die Persistenz von List. Wie und wo speichert die Anwendung ihre Daten ab? Diese Information gehört nach meiner Meinung zwingend in die Dokumentation. Gerade bei einer Todo-App, möchte man das wissen, um die Daten kopieren, sichern und synchronisieren zu können. Schaut man in den übersichtlichen und einfachen Source-Code, sieht man schnell, dass die Daten in XDG_DATA_HOME/data.json landen, was für viele Neulinge auch ein Buch mit sieben Siegeln bedeutet. Insbesondere, da es sich um ein Flatpak handelt, welches die Datei nicht unter ~/.config/list/data.json speichert. Es ist nicht meine Aufgabe zu erklären, wo die Daten von List tatsächlich gespeichert werden; das ist die Aufgaben des Entwicklers Vlad Krupinski.
Um es klar zu sagen: List ist für mich eine gute Anwendung, um zu lernen, wie man eine Gtk4-Applikation in Python entwickelt und als Flatpak bereitstellt. Da die Anwendung aus wenigen Dateien und wenig Code besteht, ist sie eine gute Lernanwendung. So klein die Anwendung ist, so klein ist auch die zugehörige Dokumentation, was bedauerlich ist.
Ich teile deine Kritik, insbesondere fehlende Dokumentation ist nicht schön. Dennoch denke ich, dass es immer besser ist, wenn Programmierende ihren Code – zur Not auch unkommentiert – veröffentlichen.
PS: Wandern in den Cinque Terre lohnt sich, aber besser im Frühling oder Herbst und nur wochentags. Grüße aus Genua!
Hi Ralf und Danke für den Artikel. Bei vielen Punkten stimme ich zu. Besonders der Punkt mit der Datenablage schmerzt sehr, besonders für Leute wie mich, die gerne Daten über Nextcloud synchronisieren oder diese Angabe für gezielte Backups benötigen. Die Frage "wie viel Dokumentation ist genug" ist wahrscheinlich genau so alt wie das Schreiben von Code (was auch auf "wieviel Test ist genug" zutrifft) und daher bin ich zwar dankbar für Deine Faustregel, denke aber auch dass diese nur bedingt zutrifft. Beim Dokumentieren sollte man sich immer vor Augen halten, wen ich adressiere. Andere Entwickler? Dann reichen normalerweise in-code Kommentare und ggf. ein readme zu dependencies und build-Anweisungen. Anwender interessiert das nicht, ebenso haben sie selten die Kenntnisse um sich die nötigen Infos aus dem Code zu ermitteln, daher sollte man sich nicht auf das Handbuch "wie-mache-ich-was" beschränken sondern auch ein Grundgerüst an logistischen Infos aufnehmen. Was mir in diesen Fällen hilft, ist die Orientierung am "EVA-Prinzip" (Eingabe, Verarbeitung, Ausgabe): Was sind die Voraussetzungen, wie läuft das Programm ab? Damit hat man im Prinzip schon eine minimale Mindmap die man dann mit Inhalt füllen kann (bspw. ableitend zum Thema "wo liegen die Daten?") und meist ergibt sich daraus auch schon eine Struktur und Inhaltsangabe der Dokumentation. Für kleine Dinge reicht das völlig. Sobald man bemerkt, dass es zuviel wird muss man sich Gedanken machen ob die Dokumentation nicht besser aus einem Textabschnitt besteht die auf Wiki, FAQ etc. verweist und dort die Infos pflegen. A propos trivial Anwendungen: Hier haben wir die nächste epische ewige Frage. "Wieviele Features braucht ein Programm?". :) Diese ist für mich irgendwie auch gekoppelt an technische Gegebenheiten. Am Anfang war Speicher und Prozessorleistung knapp. Also hat sich auf das nötigste beschränkt. Usability war quasi nicht vorhanden. Mit der Zeit wurde das anders bis zu dem Punkt wo galoppierende Featuritis zum Verkaufsargument wurde. Office-Suiten sind da ein gutes Beispiel. Dann wurde das Smartphone aus der Taufe gehoben und plötzlich war nicht nur Speicher wieder knapp sondern auch Prozessorleistung und Bildschirmgröße, also drehte sich der Trend um: Weniger ist mehr, Aktuell sind wir scheinbar wieder auf dem Weg hin zu eierlegenden Wollmilchsäuen im Bereich mobil aber im Desktop-Bereich hin zu kleineren, spezialisierten Apps die sich aber integrieren lassen (API, offene Datenformate). Ich habe nichts gegen trivial-Apps, solange sie mich nicht dazu zwingen meine Arbeitsweise zu ändern oder die Hoheit über meine Datenformate übernehmen wollen. Oder wenn sie aus ein paar Zeilen code bestehen, für dessen Ausführung ich drölfzigtausend dependencies oder ein gigantisches Framework installieren muss.
"Wenn deine Dokumentation kürzer als dein Code ist, stimmt etwas nicht."
Das kann man genau andersherum sehen: Eine App die sich selbsterklärend benutzen lässt - und deshalb keinen Blick ins Handbuch erfordert, also eigentlich keines benötigt - ist immer anwenderfreundlicher und besser.
Valide Punkte. Insbesondere zur Dokumentation. Ich nehme an du hast einen PR eröffnet mit den angesprochenen Verbesserungen; die Community dankt.