Benutzer Diskussion:Hirnbrand

Hinweis:

Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.

• Deshalb sollten Diskussionen über den Artikel zum Thema „Hirnbrand“ besser im SELFHTML-Forum geführt werden.
• Unter https://forum.selfhtml.org/self/new kannst du einen entsprechenden Beitrag erstellen.
• Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

Hinweis:

Link auf Perl entfernt -- Matthias (Diskussion) 18:16, 21. Apr. 2017 (CEST) --

Herzlich willkommen, Hirnbrand

Herzlich willkommen im SELFHTML-Wiki. Mitarbeit ist gern gesehen, dort wo du deine Stärken siehst. Einige wichige Dinge findest du auf der Seite SELFHTML. Für den CSS-Teil habe ich den Handlungsbedarf auf der Seite Baustellenseite spezifiziert. In den anderen Themenbereichen muss zunächst gesichtet werden.

Diese Seite hier ist deine Diskussionsseite, auf der dir andere Autoren Nachrichten hinterlassen können. Wenn du selbst eine Anfrage an einen anderen Autor hast, schreibe ihm bitte auf seiner Diskussionsseite. Bitte füge am Ende jeder Mitteilung auf Diskussionsseiten deine Unterschrift durch Eingabe von --~~~~ ein, beachte jedoch, dass Artikelbearbeitungen nicht unterschrieben werden.

Auf der Seite Spezial:Einstellungen kannst du unter anderem das Aussehen des Wikis festlegen.

Schön wäre es, würdest du deine Benutzerseite, zum Beipiel durch Verwendung der Vorlage Autorbox individualisieren.

{{Autorbox|(in)|Name|e-Mail|Internetseite}}

Auf gute Zusammenarbeit

Matthias 08:28, 30. Mai 2012 (CEST)

Hallo Matthias,

danke für die nette Begrüßung. Wollte eigentlich was im Bereich JavaScript machen und sehe gerade, dass Klaus Quappe da schon dran ist.

--Hirnbrand 21:56, 31. Mai 2012 (CEST)

JavaScript

Hallo Hirnbrand,

was JavaScript betrifft, lies mein Posting an Dedlfix.

-- Matthias 06:38, 1. Jun. 2012 (CEST) --

Ich bin mir da gar nicht so sicher, ob so eine 1:1-Verschiebung sinnvoll ist. Wenn ich das richtig sehe (ich habe es mir allerdings nicht genau angesehen), sieht mir Klaus' Arbeit wie eine Wikifizierung der statischen Version aus. Ob und in welchem Maße er dabei die Texte aktualisiert hat, entzieht sich meiner Kenntnis. Der Grund, dass wir die „alten“ Texte nicht mit einem Automatismus ins Wiki übernommen haben, war ja eigentlich die Idee, sie beim händischen Übernehmen auf Aktualität zu untersuchen und gegebenenfalls zu überarbeiten. Zudem existieren im jetzigen Bereich Doku:Javascript bereits Texte in unterschiedlicher Qualität, so dass es beim Verschieben in einem Stück zu inhaltlichen Dopplungen und inkonsistenten Seitenbenennungen kommen wird beziehungsweise kann. Bevor ich das mache (Matthias hat übrigens dazu ebenfalls die Berechtigung), hätte ich gern eine Einschätzung der möglichen Nebenwirkungen. Andererseits ist mir auch klar, dass es eine Heidenarbeit ist, alles per Hand an die richtigen Stellen zu schieben. Wenn das Verschieben am Stück nicht möglich ist, käme noch der Einsatz eines Bots in Frage. So einen habe ich zwar da, aber dem müsste auch erst noch gesagt werden, was genau zu tun ist, nebst Testen, dass er alles richtig macht.

Weiterhin denke ich, ist für eine richtige Wikifizierung sowieso noch mehr Arbeit notwendig. Die Philosophie der Mediawiki-Software ist – ganz nach Wikipedia-Art – dass jedes Ding seine eigene Seite hat, was sich auf die Findbarkeit mit der Suchfunktion und weitere Funktionalität auswirkt. (Beispielsweise zeigen Links auf Anker (sprich Zwischenüberschriften) unbemerkt ins Leere, wenn die Überschrift geändert wird. Dafür hat Mediawiki keinen nachziehenden Mechanismus eingebaut.) Die bisherige Dokumentation hat ja sehr häufig zum Beispiel eine Seite zu einem Objekt, und nach dem einleitenden Text folgen auf derselben Seite alle Eigenschaften in jeweils eigenen Abschnitten. In Mediawiki würde jede Eigenschaft ihre eigene (Unter-)Seite bekommen. Wenn man dann eine allumfassende Seite braucht, kann man ja alle Unterseiten als Vorlage einbinden. Und, kleinere Texte lassen sich einfacher bearbeiten als Monsterseiten.

Vor dem Verschieben würde ich auch gern noch wissen, wie sich die Links verhalten. Sprich: das müsste erst noch getestet werden (im Test-Wiki oder im stillen Kämmerchen). Keine Zeit habe ich auch in rauhen Mengen. Darf ich euch also zunächst um eure Meinung zu den angesprochenen Punkten bitten? --dedlfix 22:32, 1. Jun. 2012 (CEST)

Uns fällt jetzt wieder auf die Füße, dass wir (eigentlich du, denn ich meine, dass ich nicht die Kenntnisse und Fähigkeiten habe) es nicht geschafft haben, die Struktur des Wikis zu verändern. Wir bräuchten die Kategorie JavaScript statt Doku:JavaScript/Sprachelemente. Dann liegen eben alle Artikel in einer Ebene, auf die Brotkrumennavigation wird verzichtet und es gibt ggf. sehr viele "siehe auch". Die Namenskonvention wie sie in der Wikipedia ist, ist auch hier anwendbar, etwa disabled (Pseudoklasse) disabled (Attribut), zusätzlich noch eine Begriffsklärungsseite disabled. Die bisherige Doku:CSS wird die Seite CSS und Doku:CSS/Eigenschaften wird die Seite Liste der CSS-Eigenschaften.

Bitte entschuldige, dass ich die Beispiele auf CSS beziehe, aber da hab ich den besseren Überblick. Im JS-Bereich könnte das ähnlich sein und wir könnten endlich die Suchfunktion benutzen.

Meine Sorge hinsichtlich der Verschiebungen im JS-Bereich (ich weiß nicht, ob und wie man mehrere Dateien in einem Rutsch verschieben kann) liegt hauptsächlich in den von dir genannten inhaltlichen Dopplungen, das heißt man müsste schauen, ob es das ggf. anderswo schon gibt und ich befürchte, dass wir an der Heidenarbeit nicht vorbeikommen.

Die Verschiebefunktion erzeugt eine Weiterleitung, die dann irgendwann auch händisch (oder per bot = suche Links auf diese Seite und ändere zu neuer Seite) gelöscht werden können/müssen.

@Hirnbrand:

Artikel, die unter Doku:JavaScript zu finden sind, können geprüft und bearbeitet werden.

Artikel, die in Klaus Quappes BNR liegen (Benutzer:Klaus Quappe/Work 8.1.2/JavaScript) und die du gern verbessern möchtest, verschiebst du vorher in deinen BNR.

-- Matthias 13:53, 2. Jun. 2012 (CEST) --

Würde lieber nicht verschieben sondern Artikel für Artikel abgleichen und überarbeiten. Werde dazu [Referenz:JavaScript] und Benutzer:Klaus Quappe/Work 8.1.2/JavaScript in meinem BNR zusammenführen, dann kann ich auch testen, ob eine Aufteilung in Unterseiten sinnvoll ist.

--Hirnbrand 15:25, 2. Jun. 2012 (CEST)

Was meinst du mit Zusammenführen?

Ich halte es für sinnvoll, abzugleichen und zu überarbeiten und was fertig ist, dann unter einem geeigneten Namen zunächst nach Doku:JavaScript zu verschieben. Vielleicht gibt es ja schnell eine Einigung, was den Hauptnamensraum betrifft, dann kann es auch in den HNR.

-- Matthias 16:19, 2. Jun. 2012 (CEST) --

Du willst die Referenz also unter Doku haben?

--Hirnbrand 14:17, 3. Jun. 2012 (CEST)

Das, was momentan unter Referenzen:JavaScript zu finden ist, ist für eine Referenz viel zu umfangreich und gehört deshalb mMn in die Doku. Die (neuen) Referenzen müssen deutlich kürzer sein. Vergleiche hierzu etwa [HTML/Textstrukturierung/Überschriften] und [Referenz:HTML/h1].

-- Matthias 14:52, 3. Jun. 2012 (CEST) --

Ich hab nochmal etwas genauer hingeschaut. Die Seite [[Doku:JavaScript/Objekte/window]] hatte ich ja vor einiger Zeit bereits einmal zerhackstückt. So ungefähr stelle ich mir das Ergebnis vor, allerdings im Hauptnamensraum, also ohne einleitendes Doku:. Durch diese Hierarchie im Namen (JavaScript/Objekte/window) ergibt sich auch keine Kollision mit den Bezeichnern (hier window und dessen Eigenschaften und Methodennamen) aus anderen Gebieten. Allerdings ist das für die Suchfunktion ungünstig. Man kann nicht einfach „blur“ eingeben, um dann direkt auf JavaScript/Window/blur zu landen (angenommen es gäbe nur ein einziges blur). Hier würde ich zugunsten der Suchfunktion entscheiden und für Einzelseiten (nebst Begriffsklärungsseiten, falls notwendig) plädieren.

Der nächste Punkt ist, dass ausgerechnet diese Seite zwar nicht vollständig ist, aber ungeachtet der Lücken nochmal in einer Version von Klaus existiert. An der gefallen mir einige Dinge nicht. Zum einen ist es eine Monsterseite. Die Zwischenüberschriften sind durch die Klammern und Erläuterungstexte nicht sehr prägnant und sehen als URL bescheiden aus. Überschriften würde ich auch nicht unbedingt anders formatieren als das allgemeine CSS vorgibt. (Im Fließtext sehe ich eine Auszeichnung als speziellen Begriff als sinnvoll an, damit er sich vom anderen Text drumherum etwas abhebt.) Und dann sind ihm beim Copy&Paste die alt-Texte der Symbole in den Text gekommen, die er nicht immer beseitigt hat. (Beispiel blur: „Diese Methode macht ein Fenster inaktiv. Das Gegenteil von nach unten focus().“ Das „nach unten“ ist der alt-Text vom Symbol.) Ich sehe also eine Menge erforderliche Handarbeit, so dass das Verschieben an den (vorläufig) endgültigen Platz der geringste Aufwand scheint. Wenn sich aber eine eindeutige Regel finden lässt, nach der ein Bot Handarbeit abnehmen kann, bin ich gern bereit, meinem dafür die notwendigen Programmfunktionen zu spendieren. --dedlfix 15:19, 3. Jun. 2012 (CEST)

Denke so langsam wird's klarer. Habe jetzt mal analog zu HTML eine Einstiegs-/Portalseite erstellt (JavaScript). Es geht erstmal darum ein Gerüst zu haben, wo auch andere Autoren ansetzen können. Es ist halt schwer bei mehreren unterschiedlichen Anlaufpunkten (Referenz, Doku, Klaus und auch Alt-Doku) zu entscheiden, wo eigentlich zu arbeiten ist. Die Megaseiten finde ich auch nicht gut. Denke eine weitere Aufteilung ist für den Leser und Suchmaschine gleichermaßen von Vorteil. Sagt mir ob das jetzt so ok ist, dann könnte ich anfangen die Artikel einzubauen und aufzuteilen. Eine inhaltliche Überarbeitung wird dann zu einem späteren Zeitpunkt erfolgen. Und vielleicht findet sich auch noch ein begabter und williger Mit-Helfer.

--Hirnbrand 22:29, 3. Jun. 2012 (CEST)

Die Frage sollte stets im Raume stehen: Wann nimmt man Unterseiten und wann lieber eine eigene Seite? Unterseiten sind meiner Meinung nach für allgemeine Fließtexte empfehlenswert, also HTML/Grundlagen, JavaScript/Grundlagen etc. anstatt Grundlagen (HTML) und Grundlagen (JavaScript). Konkret benennbare Dinge, die auch als Suchbegriff verwendet werden können (Objekte, Unterobjekte, Eigenschaften und Methoden), sollten stattdessen jeweils eigene Hauptseiten bekommen (gegebenenfalls mit Begriffsklärungsseiten). Also JavaScript/Objekte als Zusammenfassungsseite der Objekte finde ich ok, aber Array bekäme bei mir eine Hauptseite (zuzüglich kurzer Einleitungstext, um den Kontext herzustellen, siehe Absatz beginnend mit "Nochwas:")

Hierarchien bei Unterseiten würde ich bedingungslos straffen. Zum Beispiel kann es auf der JavaScript-Portalseite ruhig die Punkte „Sprachelemente“ und „Weiterführende Informationen“ geben, und einige Themen darunter einsortiert sein. Aber in den Seitentiteln würde ich diese Zwischenschritte weglassen: „JavaScript/Ajax“ statt „JavaScript/Weiterführende Informationen/Ajax“. Die beiden Punkte könnten auch einfach nur Überschriften sein, wie auf der Portalseite Startseite (verlinkt, wenn es dazu Text gibt, oder einfach unverlinkt).

Während ich so diesen Text schreibe, kommt mir noch eine weitere Idee, wie man die Vorteile der hierarchischen Seitenbenennungen mit denen von Hauptseiten aus Sicht der Suchfunktion vereinen kann. Mehr dazu unter Benutzer_Diskussion:Dedlfix#Begriffsklärungsvorlagen.

Vorschlag für Methodenseiten

Hallo Hirnbrand,

ich habe an JavaScript/Objekte/Array/splice viel verändert. Schau dir das mal bitte an. Die Verwendung von dl reduziert die Anzahl der Überschriften, eine eigene Überschrift slice ist denke ich auch nicht nötig, an Stelle dessen habe ich einen einleitenden Satz gesetzt.

Ich denke, das ist insgesamt besser so. Ob wirklich jedes einzelne Beispiel erläutert werden muss, ließe sich sicher diskutieren. Da dies jedoch die Doku und nicht die Referenz ist, sollte es zu _jedem_ (Programmier)beispiel auch eine Erklärung geben.

Keinesfalls möchte ich dich dadurch in deinem Tatendrang bremsen. Wenn du grundsätzlich damit einverstanden bist, sollten wir alle Seiten zu Methoden strukturell ähnlich aufbauen. Du kannst dann auch immer gleich eine Seite im HNR anlegen und durch #WEITERLEITUNG [[...]] eine Weiterleitung anlegen. Sollte es das für andere Programmiersprachen auch geben, muss man sich dann Gedanken machen, was Begriffsklärungen angeht. -- Matthias 10:19, 10. Jun. 2012 (CEST) --

Hallo Matthias,

ein Grund warum ich Arrays erstmal aufgenommen habe ist ja, dass ich was mit tiefere Seitenstrukturen habe und auch ein Gefühl bekomme, wie man damit am besten umgeht. Prinzipiell stimme ich den Veränderungen zu. Ein Einletungstext mit "Die Methode xxx" oder "Die Eigenschaft xxx" schafft auch gleich einen guten Bezug. Definitionslisten für die Parameter wollte ich ürspünglich auch, habe aber die Wiki-Syntax dazu nicht gefunden. Das mit dem ausgiebigen Beschreiben der Beispiele finde ich nicht so gut. Stefan Münz hat auch immer ellenlange Texte da reingeschrieben. Da steht teilweise mehr drin als im Hauptext aber nichts dem Thema nützliche. Ich gehe meistens davon aus, dass einfache Beispiele selbsterklärend sind und komplexe Beispiele sollten beschrieben werden. Da werde ich nochmal drüber nachdenken.

Über die Array-Seite sollten wir uns auch mal unterhalten, ich werde aber zuerst von unten die bestehenden Seiten für Methoden und Eigenschaften hochziehen bzw. inhaltlich und vom Layout her anpassen. Wie schaut's eigentlich mit der Schreibweise bei Links aus, also zum Beispiel slice()-Methode zu slice-Methode. Diese leeren Klammern stören mich schon lange sind aber überall in der alten Doku drin.

Das mit der Weiterleitung mußt du mir leider doch mal erklären, da weiß ich jetzt nicht weiter wie genau das geht.

--Hirnbrand 13:54, 10. Jun. 2012 (CEST)

Ich finde es gut, dass du überhaupt bereit bist, im Wiki zu arbeiten, insofern gibt es keinerlei Kritik daran, wo du arbeitest. Es ist vollkommen klar, dass es "unterwegs" immer mal wieder Lücken und Inkosistenzen gibt. "Ellenlange" Erklärungen zu den Beispielen sollte es bei Programmiersprachen immer geben, im HTML- und CSS-Bereich braucht es die nicht. Unsere Zielgruppe sind auch Anfänger der Programmierung und die sollten auch verstehen, warum diese Parameter jetzt genau das bewirken.

Die Klammern unterscheiden in CSS eine Eigenschaft von einer Funktion, in JavaScript eine Eigenschaft von einer Methode. Insofern sind sie wichtig und müssen dabei sein.

Du hast jetzt die Seite JavaScript/Objekte/Array/splice fertig gestellt, die mMn allerdings nach JavaScript/Objekte/Array/splice() verschoben werden sollte. (siehe auch SELFHTML Diskussion:Umstellung auf die neue Struktur#Methoden im Seitentitel mit Klammern|Disk) Im Hauptnamensraum sollte es eine Seite splice() geben, die folgenden Inhalt hat:

#WEITERLEITUNG [[JavaScript/Objekte/Array/splice()]]

In Perl gibt es Splice auch. Irgendwann wird die Seite Perl/Listen bzw. Arrays#splice() erstellt werden. Dann muss man sich überlegen, ob die Seite splice() die Weiterleitungsseite bleiben soll oder ob diese Seite eine Begriffsklärungsseite wird, also

{{Begriffsklärungsseite}}

--Matthias 14:21, 10. Jun. 2012 (CEST)--

"Ellenlange" Erklärungen zu einfachen Beispielen sind eher selten. Soetwas findet man fast gar nicht auf MSDN noch auf MDN Seiten. Ist eher unüblich. Komplexe Beispiele müssen erläutert werden aber nicht jede Codezeile. Beispiele müssen treffend ausgewählt werden.

--Hirnbrand 18:15, 10. Jun. 2012 (CEST)

einmal bitte in die SELFHTML Diskussion:Umstellung auf die neue Struktur#Methoden im Seitentitel mit Klammern|Disk schauen, nur für den Fall, dass du nicht regelmäßig in deine Beobachtungsliste oder die letzten Änderungen schaust. -- Matthias 21:47, 11. Jun. 2012 (CEST) --