Hallo Stefan Münz, alle Devs und SELFer!

Ich habe diesen Eintrag aus mehreren Gründen mit gemischten Gefühlen gelesen.

1. Ich schätze die SELFHTML-Seiten (Forum ausgeklammert) sehr, weil man sich auf die Informationen verlassen kann. Die Autoren (Devs) arbeiten gewissenhaft an diesem Projekt, geben "Pre-RC's" zur Korrekturlesung aus und sind auch später stehts bemüht "kleine Schnitzer" schnell zu beseitigen.
2. Wenn SELFTHTML ein Wiki wird kann jeder, oder fast jeder, schreiben was er will, ohne aufgehalten zu werden. Einzig die Devs, deren Aufgabe dann auch die Kontrolle der neuen/bearbeiteten Artikel wäre, könnten den größten Unfug wieder entfernen und mit genau dem Problem komme ich zu
3. Sparen die Devs durch ein Wiki-System wirklich Arbeit und bleibt die Qualität auf dem heutigen Niveau?

Ich wage drittens zu bezweilfeln...

Ein Wiki-System ist für viele Webprojekte sicher eine Zwischenstation in der Projekt-Evolution, aber diverse Medien haben uns in den vergangenen Monaten am Beispiel Wikipedia aufgezeit, wo die Schwachstellen bei Wiki-basierten Web-Projekten stecken.

Meiner Meinung nach sollte der Faktor "Troll" und vor allem der Faktor "Kontroll-/Korrektur-/Lösch-Aufwandt" unbedingt nochmal überdacht werden.

Mit "SELF-verständlich" freundlichem Gruß
Basti

Auch von mir einen Gruß an die Autoren und Leser dieser vorzüglichen Werk zu HTML & Co.

Ich würde gerne meine Stellung zu meinem Vorredner darstellen. So sehe ich immer gerne die Öffnung von Projekten, genauso wie ich diese Nachricht über SELFHTML gerne gelesen habe. Denn es gibt genug Beispiele, wie qualitativ hochwertig und umfangreich eine von der Community erstellte Wissensdatenbank sein kann.

Zwar ist in der heutigen Real-Welt aus den täglichen Erfahrungen zwar nicht zu erwarten, dass ein Wikisystem funktioniert. Doch das tut es. Es gibt nur sehr wenig Vandalismus.

Ich sehe dem Vorschlag und der Umsetzung positiv entgegen.

Ein hoch auf SELFHTML

Allgemein Begrüße ich die Öffnung und bin gespannt was sich in der Wiki tun wird. Ich frage mich allerdings welche Zielgruppen angestrebt werden und auf welche Themen sich das Wiki beschränkt. (Siehe auch Diskussionseite zu SELFHTML.)

Hey die Idee ist super, denn nach einigen Jahren Benutzung von SelfHTML (als Referenz) verspüre ich immer wieder das Bedürfnis, selbst Hand anzulegen, um Newbees auf "Gefahren" hinzuweisen. Als ich Anfang 2000 anfing, mich mit CSS zu befassen, übernahm ich ohne nachzudenken sämtliche CSS-Eigenschaften in meine erste Webseite und schaute mir dann die Seite im NN 3 und 4 an, das war natürlich eine Riesenenttäuschung. Gott seid Dank hat sich da mittlerweile einiges getan, aber:

1. Es muss noch mehr auf Browser-spezifische Unterschiede hingewiesen werden (siehe Quirksmode.org). 2. JavaScript sollte noch intensiver eingeführt werden.

Das Wiki bietet dazu perfekte Gelegenheit, eure Aktion kann ich nur loben!

Lieben Gruß,

Andi aus Ulm

Ich glaub, das erste mal hab ich 1998 SelfHTML entdeckt. Kann das sein? Es war auf irgendeiner Zeitschriften-CD. Gerade die Anwendungsbeispiele haben mich vorangebracht. Auch heute weiß ich SelfHTML zu schätzen, insbesondere bei Javascript.

Sicher gibt es Bedarf, die Artikel auf Webstandards auszurichten, und es dürfen gute Traditionen wie die Browsersymbole nicht verlorengehen. Ob das in einem Wiki tatsächlich funktioniert, weiß ich nicht. Ich bin eher ein Fan von fundierten Anwenderkommentaren, wie es bei php.net umgesetzt ist.

Bei den Wiki-Diskussionen in der Vergangenheit konnte ich mir keine rechte Meinung bilden. Ich hatte sowohl für die Befürworter als auch die Gegner Verständnis. Schon nach dem ersten Durchklicken durch das WIKI vor ein paar Tagen war ich spontan der Meinung, hier die optimale Form der Dokumentation gesehen zu haben. Mit SELF + WIKI haben sich zwei gefunden, die zusammengehören. ;-)

In der bisherigen Dokumentation beschlich mich immer das Gefühl, in der Vergangenheit zu lesen, weshalb ich das Forum als Lernstätte vorzog. Viel zu vieles, was im Forum als richtig dargestellt wurde, fand sich nicht in adäquater Form in der Doku. Hier kann das Wiki-Konzept wesentlich zeitnaher auf aktuelle Strömungen reagieren. Der größte Kritikpunkt ist ja die wirkliche oder auch nur scheinbare Anfälligkeit für Vandalismus. Die Entscheidung sollte in zwei Fragestellungen aufgeteilt werden.

Dann lautet die erste Frage, Wiki ja oder nein. Stefan scheint mir einer der Befürworter des Wikis zu sein und seinem Engagement auf den Diskussionsseiten nach zu urteilen mit Feuereifer bei der Sache. Wenn jemand das SELF-Projekt auf eine neue Struktur umstellen kann, dann Stefan. Und sei es auch nur, dass das Projekt seinen Segen hat und er die Schirmherrschaft übernimmt. Ich mit meinem bescheidenen technischen Hintergrundwissen sehe zum Wiki keine Alternative.

Die Zweite Frage lautet dann, wie groß soll der Teilnehmerkreis werden. Arbeiten nur die bisherigen Devs am Wiki, ist die Gefahr von Vandalismus ja wohl gleich null. Von hier ausgehend könnte man überlegen, wie weit der Mitarbeiterkreis gezogen werden soll oder kann, ohne sich weit von Null weg zu bewegen. Ich würde ungern – womöglich gestresst wegen plötzlich aufgetretenen Fehlern in einem eigenen Projekt – in einer technischen Dokumentation lesen und über unsinnige Eintragungen stolpern wollen. Mit anderen Worten, ich wäre sehr dafür, nicht jeden mitschreiben zu lassen. Ich denke, in der Redaktion sitzen genug fähige Köpfe, um sinnvolle und praktikable Zugangsbedingnugen zu kreieren. Eine Beschränkung fände ich allemal besser als die Arbeitskraft der Redaktion mit Vandalenjagden zu verheizen.

Nachdem ein „heise-DDOS“ den Zugriffs aufs Wiki erst einmal vereitelt, möchte ich in der Zwischenzeit meine Erfahrungen mit der Arbeit in der Wikipedia darlegen und mögliche Konsequenzen für SELFHTML (was heise übrigens fälschlicherweise als »SelfHTML« bezeichnet) aufzeigen:

Wie bereits oben genannt ist mit der großen Bekanntheit von Wikipedia Vandalismus ein ernsthaftes Problem. Es wäre sehr schade, wenn die „hauptamtlichen“ Entwickler und engagierte Autoren einen Großteil ihrer Zeit opfern müssten, um grobe und absichtliche Fehler aus SELFHTML wieder zu entfernen. Wie ein Spiegel-Interview mit Jaron Lanier letzte Woche (Ausgabe 46/2006) zeigte, ist dabei auch „Autoren-Vandalismus“ ein Problem: Lanier sagt im Interview, dass im Wikipedia-Artikel zu seiner Person lange Zeit stand, er sei Filmemacher, was damals noch nicht der Wahrheit entsprach. Seine Korrekturen wurden allerdings immer wieder rückgängig gemacht – vermutlich, weil man sie für „Wiki-Vandalismus“ hielt.

Um solchen Problemen zu entgehen, scheint es meiner Meinung nach sinnvoll, im SELFWiki das Konzept der so genannten stabilen Artikelversionen einzuführen, d.h. der Ratsuchende liest von einem Artikel immer eine Version, die korrekt ist. Erleichternd kommt dabei hinzu, dass sich SELFHTML praktisch immer auf veröffentlichte Spezifikationen stützen kann, d.h. Angaben sind stets verifizierbar.

Der klare Vorteil des Wikikonzepts ist weiterhin, dass der Kreis der Mitwirkenden größer wird, die „Hemmschwelle“ zur (hoffentlich konstruktiven) Mitarbeit wird geringer. Wenn sich der „heise-Sturm“ gelegt hat, werde ich mal vorbeischauen.

Hi,

leider ist der Server immer noch nicht erreichbar :-(

SELFHTML (habe ich gerade gelernt) ist meine erste Quelle bei Fragen zu HTML oder CSS. Ich bin sicher, dass das Team auch die Probleme eines Wiki in den Griff bekommen wird. Gibt es so etwas wie ein 4-Augen-Prinzip? Einer schreibt und ein anderer kann den Artikel dann freischalten?

Ansonsten einmal vielen Dank für das Projekt an dieser Stelle.

Ciao, Mike

Hi,

gute Idee!

Vorschläge

1. Code-Beispiele sollten nur von eingeloggten Usern bearbeitbar sein.

2. Auf Dauer bleibt eine gewisse Autoren-Hierarchie nicht aus. Hier gibt es für selfhtml besondere Möglichkeiten: Aktive Webautoren haben eigene Seiten im Netz, diese wiederum haben ein Impressum. Möglichkeit zu höherer Vertrauenswürdigkeit gegenüber anderen?

3. Erfolg von Wikis hängt von der Menge der aktiven Autoren ab. Kleinere Wikis ziehen nicht so Autorenmassen an wie Wikipedia. Das Augenmerk sollte daher auf eine möglichst offene Einladung an potentielle Autoren sowie eine niedrige Einstiegsschwelle gelegt sein. Bspw. läd ein schneller Server eher zum mitschreiben ein als ein langsames System; Log-ins erschweren es mal schnell ein Komma zu setzen; eine einfache Wiki-Syntax erleichtert das Schreiben...

Viel Erfolg!

Ich habe den Artike schon am Erscheinungstag gelesen und hatte daher schon die Wiki angegucken. Ich finde es beeindruckend wie gut sich SELFHTML in eine Wiki einfügen läst. Gut finde ich auch das das Layout sofort an das „klassische“ SELFHTML erinnert.

Eine Sache die ich mich frage ist: Wie kann man sich die Inhalte zum Offline lesen runterladen?

Servus Stefan, liebe SELFler,

ich möchte euch erst einmal zu diesem Schritt beglückwünschen und einfach viel Erfolg und frischen Mut zu seiner Realisierung wünschen. Ich denke, SELFHTML ist eines der wenigen Projekte im deutschsprachigen Internet, das die notwendige kritische Masse sowohl an engagierten Mitarbeitern als auch an interessierten Benutzern (den potentiellen Mitarbeitern) mitbringt, damit das Wiki-Prinzip funktionieren kann. Die Arbeit wird dadurch für die bislang Beteiligten wohl kaum weniger, sie verlagert sich mehr ins Koordinative u.Ä., doch die Doku bekommt wieder mehr Leben und Aktualität. So richtig und nachvollziehbar viele der geäußerten Bedenken auch sind, was wäre denn längerfristig die Alternative? Ich sehe keine (ohne die internen Diskussionen zu kennen).

So wie ich die SELF-Gemeinde in all den Jahren (aus der Ferne) kennen gelernt habe, wird es dem Projekt auch in Zukunft nicht an ebenso akribischer wie kritischer Begleitung mangeln. Diese ist wichtig und gut (und eine "deutsche Tugend", die ich hier im fernen Mexiko allzu oft schmerzlich vermisse), sie soll aber auch nicht dazu führen, das Eigentliche, diese wunderbare Doku + X, letztlich nicht mehr weiter zu pflegen. Ich würde durchaus dafür plädieren, die redaktionelle Kontrolle nicht zu eng zu fassen. Zumindest ich verliere schnell die Lust zum Mittun, wenn ein Vorschlag erst einmal diverse institutionellen Hürden zu nehmen hat. Nimmt man den Perfektionismus allzu ernst, hält er nur davon ab, überhaupt etwas zu beginnen. Wenn ich mich nicht sehr täusche, wird die Öffnung zum Wiki Raum schaffen für ganz neue Subprojekte - die wir heute wohl gerade mal erahnen können.

Also noch einmal: Ich wünsche euch viel Mut zum Nicht-Perfekten, zum Unfertigen, zur steten Bewegung. Macht einfach mal, besser machen kann man es später immer noch. Und dann werde ich mich trotz permanenten Zeitmangels wohl doch dazu verführen lassen, hin und wieder an SELFHTML mitzuarbeiten - und sei es in der Funktion des Tippfehlerfressers...

Hallo zusammen,

ich hätte einen Vorschlag, wie man die verschiedenen Konzepte (redaktionelles Werk wie bisher und Wiki) sinnvoll miteinander vereinen kann, um die Vorteile aus beiden zu bekommen (Qualität und Aktualität):

Am Wiki sollte sich jeder unkompliziert beteiligen können. Wenn ein Artikel ausführlich genug (vgl. "exzellenter Artikel" bei Wikipedia) und auf Korrektheit überprüft ist, dann kann die Redaktion ihn in die Dokumentation übernehmen.

Das setzt natürlich voraus, dass das Wiki nicht das bisherige SELFHTML ersetzt, es könnte vielmehr als Ergänzung und Entlastung der Redaktion dienen.

Was meint ihr?

Ich frage mich, warum man auf PHP setzt und nicht MoinMoin [1] einsetzt?

http://moinmoin.wikiwikiweb.de/

Juhu selfhtml mit blog und jetzt sogar mit wiki!

Hmm, ich stehe WIKI-Konzepten eher skeptisch gegenüber. SELFHTML, für mich DIE Referenz auf ihrem Gebiet ist qualitativ sehr hochwertig. Daher kommen in mir Befürchtungen hoch, dass sich diese Qualität nicht halten lassen wird.

Performanceprobleme hmm

Fragt doch mal bei Atlassian an, ob Sie nicht vielleicht für ein Prestigeprojekt im deutschsprachigen Raum eine Lizenz rausrücken.

Für OpenSource Projekte ist ja Confluence frei, weshalb es gerade bei Java-OpenSource libs zunehmend beliebter wird. Da Selfhtml sehr frei ist und definitiv eine Community vorweisen kann, sollten Ihre Anforderungen für eine freie Lizenz für OpenSource Projekte gegeben sein.

Da bei euch Performance das Problem ist, würde ich hier im speziellen nachfragen ob man nicht vielleicht ein Referenzprojekt für die anstehende Release "Massive" sein könnte, denn die hätte Cluster-Skills. Befindet sich aber soweit ich weiß noch im Beta Stadium und ist eigentlich noch nicht öffentlich erhältlich ;o) Zudem kann es mit allen gängigen Datenbanken als Backend umgehen.

Ist allerdings eine Java Webapp, weshalb Ihr einen dedicated Server zum hosten benötigt. Wobei ich aber davon ausgehe das es möglich sein sollte einen Hoster zu finden, bei dem Ihr einen Tomcat installieren könnt ;o)

mfg Bernhard, der im übrigen nicht bei Atlassian angestellt ist

Hallo,

um den Vorschlag von josh ein wenig weiter zu führen: Im heise-Artikel steht, dass es einen Konverter geben soll, der immer eine Downloadversion erzeugt. Da dieser eingebaut werden muss, stellt sich die Frage, ob dieser Konverter nicht gleichzeitig eine Onlineversion erstellen kann, die dann die aktuelle Doku ist. Da ich nicht glaube, dass ihr in der Downloadversion irgendwelche fehlerhaften Beiträge haben wollt, wäre es wohl nötig, dass das Script nur als "gut" gekennzeichnete Artikel aufnimmt. Die Onlineversion könnte dann eben die Primäre Anlaufstelle sein, allerdings immer mit Verweisen auf die Wikiversion (das Script kann ja in der DB des Wiki schauen, ob es Änderungen in der Datenbank zu diesem Artikel gab, seit er in der aktuellen Version in der Doku steht). Das ganze würde meiner Ansicht nach SELFHTML deutlich dynamischer, weitreichender und aktueller machen, als es im Moment trotz der Bemühungen der Autoren ist. Gleichzeitig würde durch die Beschränkung auf die "guten" Artikel für die Doku die Qualität nicht leiden.

Und hier noch ein Vorschlag: um zu verhindern, dass Anfänger durch die Jetzt schon beeindruckende Größe der Doku "erschlagen" werden, sollte der Konverter vielleicht mehrere Offline Versionen erzeugen. Ein Anfänger muss sich zu Beginn mit Ajax herumschlagen, er sollte erstmal lernen, was HTML überhaupt ist. Das würde auch die Größe der Version etwas reduzieren und könnte so helfen Traffic zu sparen.

Gruß Carl

Sehr erfreulich, dass man seit langem mal wieder etwas über SELFHTML 9 erfahren kann - wenn auch nicht inhaltlich. Ich weiß nicht, ob die Idee mit dem Wiki gut ausgehen wird, aber die strengen Bedingungen für das Akzeptieren von Änderungen, die ich auf den Wiki-Seiten gelesen habe, bevor sie vom Netz genommen wurden, finde ich den richtigen Schritt. Sonst wird die Qualität darunter leiden.

Die Frage ist nur, wieso man so lange gewartet hat mit einer Entscheidung oder zumindest einem Testlauf? SELFHTML 9 muss doch schon lange geplant sein. Der derzeitige Stand von SELFHTML zeigt schon heftige Alterssträhnchen ...

So richtig und nachvollziehbar viele der geäußerten Bedenken auch sind, was wäre denn längerfristig die Alternative?

Eine Alternative wäre die Aufgabe der strengen Versionierung, einhergehend mit kürzeren Update-Zyklen. SELFHTML wird derzeit via Subversion verwaltet, das Ergebnis liegt bereits im HTML-Format vor. Man könnte dies so weit treiben, Korrekturen bwz. Ergänzungen quasi in Echtzeit vorzunehmen, sodass die Online-Version dem aktuellen Stand der Redaktion entspricht. Seit der Veröffentlichung von Version 8.1.1 wurden sehr viele Korrekturen vorgenommen, die für die Nutzer nicht verfügbar sind. Das vermittelt leider den falschen Eindruck, Korrekturvorschläge würden nicht ernst genommen. In regelmäßigen Abständen könnte man stabile Download-Versionen anbieten, die den zu diesem Zeitpunkt aktuellen Stand beinhalten.

Und dann werde ich mich trotz permanenten Zeitmangels wohl doch dazu verführen lassen, hin und wieder an SELFHTML mitzuarbeiten - und sei es in der Funktion des Tippfehlerfressers...

Eine Hundertschaft an Tippfehlerfressern wird allerdings keine neuen Inhalte produzieren. Die Gretchenfrage ist, ob man künftig auf die breite Öffentlichkeit und Detailarbeit oder eine fixe Redaktion mit Gesamtüberblick baut.

Hallo,

hab gehört, dass es auch vom neuen Wiki-Selfhtml eine gedruckte Version geben soll. D.h. für die Wandlung von MediaWiki -> Buchformat muss erst mal etwas entwickelt werden, nehme ich an. Es wäre schön, wenn diese Entwicklung also freie Open-Source publik gemacht würde. Es gibt bestimmt viele MediaWiki-Betreiber, die ihr Wiki auch gern z.B. in pdf-Form sehen würden. Nur so als Anregung ...

schließe mich Rekire mal an... > Eine Sache die ich mich frage ist: Wie kann man sich die Inhalte zum Offline lesen runterladen?

... und, gibt's für 8.1.2 schon n ungefähren erscheinungstermin?

Ich hätte da noch einen Tipp,wie man das am Besten realisieren könnte. Man macht praktisch auf der Originalseite einen Link,z. B. Text ändern oder neuen Text erstellen,dann klickt man auf "zur Redaktion senden",die überprüfen dann den Artikel auf Richtigkeit und geben ihn dann frei. Das Wiki sollte aber nur eine Ergänzung zum Originalwerk sein,denn mancher versteht Autorentext bestimmt besser als Text von irgendeinem Hobbyprogrammierer.

Einen Gruß an die Autoren zu HTML & Co. schön zu hören die Öffnung zu Projekten (Wiki), gleiches gilt zu SELFHTML, zwar sehe ich mögliche Gefahren, doch Schwarzmalerei sei hier nicht angebracht, insofern sehe ich der Umsetzung positiv entgegen