Closed noxilixon closed 9 months ago
Wir könnten mal zur Orientierung andere Communities anschauen und überlegen was wir gut/schlecht finden;
Und wir müssen uns überlegen welche Inhalte welchen Zweck haben und dies entsprechend strukturieren. In diesem write the docs talk werden vier Arten der Dokumentation unterschieden:
Ich hätte weiter noch vorgeschlagen das wir auch unterscheiden welche Zielgruppen/Usecases es gibt die auf die Website kommen. Ich hatte das bisher grob an folgendes gedacht:
User/Clients/Interessierte:
Standort Verantwortliche:
Aufbau / Konfiguration / Einrichtung:
*Entwicklerinnen**
Ich habe mal geschaut was es alles im Wiki gibt um einen Überblick zu erstellen, welche Inhalte wir mit in die neue Seite umziehen wollen und was veraltet/irrelevant ist. In der Bestandsaufnahme-Wiki.csv sind alle Artikel gelistet die https://wiki.freifunk.net/Berlin:
als Präfix haben. In der ersten Spalte unterscheide ich grob die verschiedenen Typen der Inhalte. In der zweiten und dritten Spalte eine Einschätzung dazu ob die Inhalte auf die Website übernommen werden sollen. Dabei ist nicht eine eins zu eins übernehmen. Ich denke alle Seiten müssen mindestens umstrukturiert und die meisten auch aktualisiert werden. Damit meine ich ob die Inhalte die in dem Artikel stehen prinzipiell irgendwo auf der neuen Website/Dokumentationsplattform zu finden sein sollten. Bei der Angabe -
müssen die Seiten nochmal genauer angeschaut werden.
Ich habe einen Branch angelegt und angefangen die Inhalte zu migrieren: https://github.com/freifunk-berlin/berlin.freifunk.net/tree/hugo
On my laptop with tiny screen a lot space is wasted. This is what I see:
I think the navigation can be smaller. Headings as well. And we don't need that much spacing between headings etc.
I'm not sure if the "gray" text color is a good choise on a gray background.
Wir hatten uns irgendwann mal dazu entschieden bestimmte Inhalte absichtlich im Wiki zu belassen, weil sie dort einfacher von allen Mitglieder des Projekts editiert werden können. Eine statische Webseite fällt nicht jedem leicht zu ändern. Ich verstehe aber auch den Wunsch bestimmte Inhalte auf der Website hervorheben zu wollen.
On my laptop with tiny screen a lot space is wasted. This is what I see:
I think the navigation can be smaller. Headings as well. And we don't need that much spacing between headings etc.
I'm not sure if the "gray" text color is a good choise on a gray background.
Nach meinem Verständnis geht es im Moment erstmal darum die bestehenden Inhalte von der aktuellen Seite umzuziehen und sich dann im Anschluss step by step an eine Überarbeitung zu machen - inhaltlich und designtechnisch. Wenn wir hier eine schicke Pipeline haben lässt sich das ja auch alles in kleine Häppchen aufteilen und wir müssen nicht ein Jahr im stillen Kämmerlein arbeiten um dann die große neue Seite zu präsentieren.
Soweit ich weiß hat aber @noxilixon auch schon weiter an dem Thema gearbeitet, da sollten dann ein zwei Sachen auch schon ein bischen anders aussehen.
Wir hatten uns irgendwann mal dazu entschieden bestimmte Inhalte absichtlich im Wiki zu belassen, weil sie dort einfacher von allen Mitglieder des Projekts editiert werden können. Eine statische Webseite fällt nicht jedem leicht zu ändern. Ich verstehe aber auch den Wunsch bestimmte Inhalte auf der Website hervorheben zu wollen.
Über diesen Punkt haben wir neulich auch beim Communiytreffen kurz diskutiert. Das Thema kam etwas auf, weil die Inhalte im Wiki semi-aktuell sind zum Teil und deshalb ohnehin einer Überarbeitung bedürfen würden. Außerdem stand die Frage nach einer besseren Übersichtlichkeit im Raum, ein positives Beispiel dafür ist für mich die Dokumentation vom New Yorck City Mesh. Die Analyse der Änderungen die in der letzten Zeit im Wiki vorgenommen wurden ergaben, dass ein Größteil der Inhalte, wenn er verändert wird, ohnehin von einem relativ kleinem Kreis von Leuten über größtenteils Texteditoren erfolgt. Da schien ein Umstieg auf Markdown o.ä. ein nicht so großer Schritt, zumal ein Großteil der aktiven Community ohnehin Git verwendet.
You can find the current state at https://github.com/freifunk-berlin/berlin.freifunk.net/tree/hugo
You can find the current state at https://github.com/freifunk-berlin/berlin.freifunk.net/tree/hugo
That is quite clear but I have to compile the site first. That is maybe out of reach for some users. Especially if you ask the broader community on the mailing list for feedback.
You can find the current state at https://github.com/freifunk-berlin/berlin.freifunk.net/tree/hugo
That is quite clear but I have to compile the site first. That is maybe out of reach for some users. Especially if you ask the broader community on the mailing list for feedback.
There is a Markdown editor with preview available in the github web interface. We want to add a CI so that the rendering will be done automatically. This is not the perfect solution for people without tech know how (because the github preview looks different than the final result) but I think it is good enough.
Some nice hugo themes i found:
Right now the development page is accessible via website.ff.berlin and dev.ff.berlin/hugo.
When the rewrite is deployed, the state of main will be on berlin.freifunk.net automatically. And for each branch the state would be accessible at dev.berlin.freifunk.net/<BRANCHNAME>
, to make development easy.
It would be great if the new site kept these features:
Once #84 is merged, we should go over the things discussed here and create issues so we can keep track of the tasks.
I have tried to reflect the open points and discussions I have seen here in the chat in the new issues.
I did not create a issue for
location data available as machine parseable data (i.e., location pages have their table data available programmatically at https://wiki.freifunk.net/Spezial:Durchsuchen/:Berlin:Standorte:Alboinkontor etc.)
because I would do it the other way around, as proposed in #97. The data should be available as JSON (at a place to be decided), and the website should pull this data and use it to build the location page.
As far as I can see the different points of this discussion are in separated issues now.
The website should be renovated so that it is up to date and an easy entrance for new users.
Criteria we already collected:
This was discussed on the community day 16.9.23