Inhaltsverzeichnis
Allgemeine Möglichkeiten für eine Konvention eines Wikis bei der StuVe
Zweck
Die Konventionen sollen eine grobe Anleitung sein, welche Konstrukte für welche Anwendung "normal" verwendet werden. Je nach Nutzungsart und Konfiguration eines Wikis können diese Konventionen unterschiedlich ausfallen. Dementsprechend sollen hier nur Anwendungen und alle möglichen Konventionen vorgestellt werden. Eine feste Lösung muss von den Nutzern jedes einzelnen Wikis selbst fest gelegt werden.
Beispiele für Umsetzung
Ihr könnt euch die Umsetzung bei den bereits existierenden Wikis anschauen.Zum Beispiel findet sich auf der Seite HilfeWiki/Konvention die für dieses Wiki gültige Konvention.
In der folgenden Liste sollen alle verfügbaren Konventionen gesammelt werden. Sind sie nicht global, also ohne Anmeldung in dem entsprechenden Wiki lesbar, erstellt bitte eine Unterseite nach dem Schema: /Konvention_Wikiname.
Computer-Wiki: HilfeWiki/Konvention
- AStA-Wiki: noch nicht veröffentlicht.
Mitarbeit
Normal ist in einem Wiki die Mitarbeit aller erwünscht. Es wird am Anfang schwierig sein die Nutzer dafür zu öffnen, das sie selbst überall mitarbeiten sollen bzw. das ihre Inhalte auch von jemanden anderen angefasst werden können. Die AktuellenÄnderungen und die Info Seite zu jeder Seite helfen alles zu verfolgen.
Soll auch jeder vermeintliche Rechtschreibfehler auf den Unterseiten eines Projekts korrigieren mit dem er nix zu tun hat? Darf man auf der ToDo Liste von jemanden einfach Sachen hinzufügen wenn man findet das er das mal machen sollte?
Inhalt
Abkürzungen
Verweise
Links auf andere Wikiseiten sind immer in zweifache eckige Klammern [[ ]] zu setzen.
Bei Verweisen ist es möglich an Stelle des Ziels einen anderen Text anzeigen zu lassen ([[ziel|link-text]]) . Je nach Nutzung geht damit dann aber auch Information verloren. Wenn man bspw. auf eine Unterseite in einem bestimmten Bereich verlinkt, und dann als Link Text eine Beschreibung des Themas angibt, dann wird die Struktur vor den Nutzer versteckt. Es sollte für ein Wiki fest gelegt werden, ob die Link Ziele allgemein versteckt werden dürfen oder nicht.
- Beispiel:
Struktur sichtbar: [[Druck/Kostenstelle]]
Struktur hinter Beschreibung versteckt: [[Druck/Kostenstelle|Druck beim KIZ über Kostenstelle]]
- Natürlich kann man in der Beschreibung besser darstellen was sich hinter einem Link verbindet. Allerdings ist die Frage ob man das für alle Links konsistent durchsetzen kann. Eine Mischung aus beidem ist natürlich einfach möglich:
Struktur und Beschreibung sichtbar: * [[Druck/Kostenstelle]]: Druck beim KIZ über Kostenstelle
- Beispiel:
Sprache
Bei Wikis die allgemein verständlich sind sollte Fachbegriffe erklärt oder sogar vermieden werden. Bei einem Wiki das genau für ein Fachthema ausgerichtet ist, muss man auch die Begriffe verwenden können.
Struktur
Benennung von Seiten
Umlaute in Seitentiteln sind erlaubt und erwünscht.
Leerzeichen sind nicht erlaubt. Ersetzt sie bitte mit einem Unterstrich _.
Doppelpunkte in Seitentiteln haben erzeugen InterWiki Links und sind daher nicht erlaubt.
Umbenennen von Seiten
Beim Umbenennen von Seiten muss man berücksichtigen das alte Verweise dann nicht mehr auf die Seite mit dem neuen Titel zeigen. MoinMoin versucht zwar umgezogene Seiten wieder zu finden und bietet Seiten mit ähnlichem Namen an, das ist aber keine perfekte Lösung. Um zumindest alle Verweise innerhalb eines Wikis zu finden ist folgendes Vorgehen hilfreich:
SeiteBeispiel soll umbenannt werden in SeiteBeispielNeu
umzubenennende SeiteBeispiel besuchen
- Seiten die darauf verweisen suchen
- auf den Titel im oberen Bereich klicken
- -oder -
Suchen nach linkto:"SeiteBeispiel"
alle Seiten die aufgelistet werden editieren und den Verweis auf den neuen Namen SeiteBeispielNeu abändern
Hierarchie
Eine geschachtelte Struktur von Seiten darf nur verwendet werden, wenn es von der Bennenung her nötig bzw. sinnvoll ist. Dazu ein Beispiel:
Im AStA-Wiki gibt es eine eigene Seite für das BAföG-Referat und das Wohnreferat, beide Referate sind allerdings Teil des Sozialreferats. Dementsprechend gibt es zu den Themen der Referate nicht die Seite
Sozial
mit den Unterseiten
Sozial/BAföG Sozial/Wohnen
sondern
BAföG Wohnen
sind eigene Seiten in der obersten Hierarchie Ebene, genau so wie Sozial wobei von dort aus natürlich auf die beiden zugehörigen Seiten verwiesen wird.
Die Unterseiten werden nur dazu genutzt allgemeine Seitennamen in der oberen Ebene zu vermeiden, die für mehrere Themen verwendet werden könnten. Wieder am Beispiel:
Das o.g. Wohnreferat möchte eine Seite für seine ToDo Liste und seine Rechenschaftsberichte haben. Es verwendet dafür nicht die Seiten mit den folgenden Namen in der obersten Hirarchie
Rechenschaftsberichte ToDo
sondern fügt diese Seiten in die eigene Hierarchie ein, weil auch andere Bereiche "Rechenschaftsberichte" oder ToDos haben werden:
Wohnen/Rechenschaftsberichte Wohnen/ToDo
Dies soll unter anderem auch wilde Konstruktionen und Lange Seitennamen unnötig machen, wie Rechenschaftsbericht_des_Wohnreferats_aus_2009; diese Seite sollte eher so verlinkt sein: Wohnreferat/Rechenschaftsbericht/2009
Standardisierte Unterseiten
/ToDo /Diskussion /Kalender
Diese Seitennamen sollten für die entsprechende Anwendung genutzt werden, um die Kollaboration zu vereinfachen, indem jeder der an dem Thema mitarbeiten will z.B. einfach die ToDo-Liste findet und nicht erst über den Link zur Unterseite /was es hier noch zu tun gibt stolpern muss. Natürlich muss man für die o.g. Anwendungen nicht immer eine Unterseite erstellen, sondern kann auch getrost nur einen eigenen Abschnitt auf der entsprechenden Seite erstellen.
Benutzerseite
Auf der eigenen Seite und den Unterseiten kann man tun und lassen, was man will. Auch kann man hier Rechte selbsständig vergeben; siehe hier Wiki/AdminDoku und hier HelpOnAutoAdmin.
Seitenquelltext
Der Quelltext einer Seite ist sauber und übersichtlich zu halten und die Leserlichkeit dieses "unformatierten" Textes hat Vorrang. Siehe auch Überschrift "GUI Editor" weiter unten.
Zusätzliches
Kalender
TODO die Verwendung von Kalendern.
Include
TODO Verwenden des Include-Makros zum Einbinden von anderen Seiten; Kenntlich machen, wo editiert werden muss.
GUI Editor
Editieren mit dem GUI-Editor erfolgt auf eigenen Gefahr. Es kann beim Verwenden des GUI-Editors dazu kommen, dass der Quelltext für das Editieren in diesem praktisch unlesbar wird. Der Quelltext ist aber der kleinste gemeinsame Nenner für die Editierung im Wiki und hat somit Vorrang vor dem Editieren in der GUI.
Achtung!
- Postulat: einfache Regeln (3 Stück oder so) mit ein paar Bsp., damit jeder Nutzer die neue Konvention leicht verstehen kann.
- tbd
Seitennamen
Möglichkeit 1
"Leerzeichenersatz"
Hausbeck_Treffen
Pro
Kontra
Möglichkeit 2
"Prosa"
Einstiegsportal IT-Themen
Pro
- Klar lesbar, keine umständlichen individuellen Konstruktionen.
Wenn jeder die eckigen Klammern [[ ]] benutzt, kein Problem.
Kontra
- In manchen Broweser Adressleisten sind die Leerzeichen nicht schön anzuschaun, aber wollen wir dann auch auf Umlaute und Co. verzichten?
Möglichkeit 3
"Camelwords / Binnenmajuskeln"
BestellenHuss
Pro
- Funktioniert auch ohne eckige Klammern.
Kontra
Konstuktion eines passenden CamelWords ist oft umständlich.
Viele finden es beim editieren sowieso viel angenehmer alles Links in eckige Klammern zu setzen, um diese wiederzufinden, was den eigentlichen Vorteil von CamelWords wieder aufhebt.
Struktur
Möglichkeit 1
"Starke Hierarchie"
Veranstaltungen/FeBo/2008
Pro
Kontra
- Verlinken wird ab der 3. Eben immer komplizierter.
Widerspricht der eigentlichen Idee eines Wikis, verlinkung entsteht durch Hinweise im Text / auf anderen Seiten, so wäre die FeBo oben eigentlich ganz oben in der Hierarchie angeordnet aber z.B. würde darauf von der Seite Veranstaltungen aus verlinkt.
Möglichkeit 2
"Hierarchie nur wenn vom Benennen her nötig/sinnig"
AStA/Tagesordnung
Pro
- Man muss (vor allem bei länger werdenden Seitentiteln) nicht immer den ganzen Linktext schreiben, von der Elternseite her ist ein kurzer Link möglich.
- Die Zugehörigkeit wird aus der Hierarchie klar, es muss nicht ein aufwendiger Titel in der obersten Ebene gesucht werden.
Kontra
Möglichkeit 3
"komplett Flache Struktur" (als alternative zu Möglichkeit 2)
AStATagesordnung
Pro
Kontra
- Man braucht ein eher umständliches Schema, um alle Seiten nachvollziehbar zu benennen.
Seitenquelltext
- Hier sollte nicht alles in einer Wurscht geschrieben werden, eine oder mehrere Leerzeilen vor und nach Überschriften Schaden nicht und erhöhen die Lesbarkeit, um Absätze im Fließtext zu generieren muss man einfach eine Leerzeile lassen.