gudn tach!

pro lemma ein artikel ist grundsaetzlich erst mal richtig. aber ein lemma muss ja nicht "font-familiy" oder (ums mal zu uebertreiben) "Tahoma" oder "5pt" heissen, sondern kann ja auch "Schriftformatierung" oder "Liste von CSS-Formatierungen" heissen.

Die Referenz ist schon deutlich mehr ein stichwortbasierendes Nachschlagewert als der ausführliche Teil. Insofern sollte da schon ein Thema = eine Seite gelten.

ja, schon. die frage ist halt, auf welcher stufe man das thema ansetzt.

Ich sehe auch keinen Sinn in dieser Übertreibung, die bringt die Diskussion nicht voran.

die sollte nur verdeutlichen, dass wikiseiten nicht winzig sein muessen und auch nicht sein sollen.

Für Zusammenfassungen kann man jedenfalls Zusammenfassungsseiten erstellen - als Linkliste oder auch mit Einbindung der Einzelseitentexte.

kommt auf verschiedene sachen an.

Wenn du eine große Seite erstellst, dann musst du diese immer als Monolith betrachten [*]. Die Anwender müssen sie immer (wieder) vollständig laden, selbst wenn sie mittels Anker auf nur einen Abschnitt geleitet werden.

das geht heutzutage in sekundenbruchteilen. viele wikipedia-artikel sind mehrere hundert kB gross. der groesste derzeit knapp 1MB. bei den ganz grossen merkt man dann auch einen gewissen kleinen geschw.-unterschied beim laden. aber bei <250kB-seiten ist das fast vernachlaessigbar. und wir koennen davon ausgehen, dass das internet kuenftig nicht wesentlich langsamer wird...

Einzelseiten hingegen können auch einzeln verlinkt und aufgerufen werden. Zusätzlich kann man sie in andere Seiten einbetten, damit den Monolith emulieren und so ohne Verzicht auf die anderen die Vorteile einer großen Seite haben, beispielsweise die Suche innerhalb der gesamten Seite mittels der im Browser eingebauten Find-Funktion nutzen.

aus erfahrung in der wikipedia kann ich sagen: viele kleine seiten lassen sich wesentlich schwerer warten als wenige groessere seiten. im self-wiki haben wir derzeit noch den luxus, dir globalen recent-changes beobachten zu koennen. das wird aber nicht zwangslaeufig so bleiben, sondern irgendwann werden sich die meisten nur noch mit der persoenlichen watchlist vergnuegen und dabei koennen dann sachen sehr leicht uebersehen werden.

in unserem wiki sehe ich teilweise die tendenz und gefahr, zu viele, extrem kleine artikel und entsprechend viele uebersichtsseiten zu erstellen. das blaeht das ganze nur auf und vermittelt einem user (egal, ob leser oder autor) ein gefuehl von unuebersichtlichkeit. in selfhtml 8.1.2. gibt's teilweise sehr lange artikel, aber ich habe sich noch niemanden darueber beschweren hoeren/lesen, dass ihm die seiten zu lang waeren (auch wenn ich nicht abstreiten moechte, dass es vielleicht einzelnen leuten so gehen mag). dagegen habe ich persoenlich schon haeufig gemerkt, dass ich bei hilfe-seiten, die nur eine kleinigkeit erklaeren, erst mal nach dem kontext _suchen_ musste. ein beispiel dazu: auf http://perldoc.perl.org/functions/index.html erwarte ich eigentlich auch einen hinweis auf http://perldoc.perl.org/functions/rindex.html und eigentlich sind diese beiden funktionen so nah beieinander, dass man sie gleich am besten auf einer seite erklaeren sollte.

was wir uns aber auf jeden fall mal ueberlegen koennten, ist, ob/wie wir zusaetzliche indexe auf die seiten klatschen. ich glaube, ich habe das auch schon mal irgendwo (auf einer der viel zu vielen meta-seiten) im wiki praezisiert. ein beispiel, wie so ein index aussehen kann, sieht man z.b. auf https://de.wikipedia.org/wiki/Hilfe:Poem (rechts der kasten).

prost
seth