gudn tach!

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.

Ich dachte, du schätzt deine Gesprächspartner für so intelligent ein,

dich schon. aber hier lesen ja auch ganz viele andere leute mit. unter anderem vielleicht auch leute, die noch keine oder nur sehr wenig wiki-erfahrung haben.

und bei so relativen begriffen wie "gross" und "winzig" helfen einem (extreme) beispiele normalerweise zum verstaendnis.

Einzelnen Werten eigene Seiten spendieren zu wollen wird sicher niemand forderen.

hoffen wir's mal. aber ein paar faelle sind mir (und dir ja auch) schon aufgefallen, in denen die meinungen im wiki auseinandergingen.

aus erfahrung in der wikipedia kann ich sagen: viele kleine seiten lassen sich wesentlich schwerer warten als wenige groessere seiten.

Wenn ich mal in die andere Richtung übertreiben darf, dann wäre quasi eine einzige Wikipedia-Seite mit allen Artikeln drauf am wartungsfreundlichsten.

jein. es gibt, wie angedeutet, auch obere grenzen. ab derzeit etwa 1MB beginnt's schon langsam ungemuetlicher zu werden. (was aber auch nicht heissen soll, dass ich der meinung bin, dass man alle seiten auf etwa dieses maximum bringen sollte, bevor man splitting in erwaegung zieht.)

Bei Einheiten, die sich sinnvoll voneinander abgrenzen lassen, sehe ich nicht unbedingt pauschal den Bedarf, sie ständig gemeinsam warten zu müssen. Für Massenänderungen kann man einen Bot ensprechend programmieren.

es geht auch um kontrolle.
es passiert leicht, dass irgendjemand (egal, ob absichtlich oder im irrtum) auf irgendeiner unterseite ein paar sachen abaendert, sodass auf der seite anschliessend etwas falsches steht. je weniger leute dann eine solche tiefe unterseite auf ihrem radar haben, desto laenger dauert es im mittel, bis sowas bemerkt und behoben wird.
(und je mehr unterseiten es gibt, desto geringer ist normalerweise die anzahl der user pro seite, welche die seiten in ihren watchlists haben.)

in unserem wiki sehe ich teilweise die tendenz und gefahr, zu viele, extrem kleine artikel und entsprechend viele uebersichtsseiten zu erstellen.

Dann erheb bitte Einspruch in konkreten Fällen. Ich sehe weder die eine noch die andere Richtung als pauschal richtig an.

ja, pauschal kann/darf man das nicht beurteilen. aber man muss auch aufpassen, dass das nicht in strukturierungsanarchie ausartet.

dagegen habe ich persoenlich schon haeufig gemerkt, dass ich bei hilfe-seiten, die nur eine kleinigkeit erklaeren, erst mal nach dem kontext _suchen_ musste.

Das ist ein inhaltliches Problem, wenn der Leser den Kontext nicht erkennen kann oder keinen gescheiten Einstieg ins Thema bekommt. Mit der Seitengröße hat das meines Erachtens nicht viel zu tun.

darauf will ich ja hinaus. die seitengroesse sollte nicht als so wichtiges strukturierungskriterium herangezogen werden (mal abgesehen von den besagten seiten jenseits von 1MB). aaaber: die groesse laesst sich ja nicht voellig unabhaengig vom inhalt betrachten. ich fand bisher an selfhtml unter anderem so gut, dass man funktionalitaeten themenbezogen gruppiert auf (grossen) seiten gefunden hat und sehr gut stoebern konnte nach irgendwie verwandten funktionalitaeten. das wird schwieriger, wenn man sowas zerhackt.

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.

Da fehlt also ein "See also", was ein inhaltliches Problem ist.

richtig. wobei ich nicht nur ein "see also" moechte, sondern eben auch gleich die erklaerung, was das andere zeug so macht. und das moechte ich, ohne die seite wechseln zu muessen. wenn ich nur scrollen muss, verliere ich als user weniger die orientierung, weil ich die abschnitte aehnlich wie bei einem buch bildlich/geografisch ordnen kann und nicht im kopf die sitemap in teilen nachbilden muss. aber vielleicht bin ich da auch altmodisch?

Wenn beides auf einer Seite steht, hast du ein Verlinkungsproblem. Entweder .../index.html und .../index.html#rindex oder .../rindex.html als Weiterleitung auf .../index.html#rindex.

nein, das ist kein problem. bezogen auf unser wiki wuerden wir einen artikel [[Perl/Funktionen fuer Zeichenketten]] anlegen und zusaetzlich zwei redirects z.b. [[Perl/index]] und [[Perl/rindex]] (oder/und eine bks [[index]] und einen redirect [[rindex]]) auf die entsprechenden abschnitte.

was wir uns aber auf jeden fall mal ueberlegen koennten, ist, ob/wie wir zusaetzliche indexe auf die seiten klatschen [...] z.b. auf https://de.wikipedia.org/wiki/Hilfe:Poem (rechts der kasten).

Ja, bin dafür, wenns dem Leser nutzt.

da, das gilt es herauszufinden. meiner erfahrung nach helfen diese index-boxes den lesern sehr, vor allem wiki-newbies.

Aber auch das steigert wieder beides, die Übersichtlichkeit und die Komplexität beim Warten.

ja, definitiv. templates in wikitext sind bzgl. wartung fast so usability-unfreundlich wie deren namensvetter in c++. aber das ist etwas, das man zum glueck ganz gut vom eigentlich inhalt getrennt betrachten kann.

prost
seth