Frage zum Titel

Ich verstehe noch nicht, was hier als Band zählt. Bin aber echt gespannt. Daher mal eine Frage, die bitte nicht unfreundlich verstanden werden soll...

Sollte das Buch nicht "Websiteentwicklung in PHP" lauten?

Oder sind andere WebApp-Technologien auch geplant? Jeweils eigene Bände? CGI, Servlets, JSP, JSF, Cocoon, Struts, Python, Perl, Plone, ZPT, ... usw. Welcher Webserver? Allgemein ServletContainer auf Java Basis? Passt da Lotus Domino auch rein? Andere WebApp-Server?

Über alle Bücher des EDV Regals hinweg gesehen, sei bemerkt... es wird zunehmends langweiliger, je mehr Apache, PHP, MySQL Bücher hier geschrieben werden. Dass PHP als Webapplikationsumgebung HTML, XHTML, CSS oder sonstige Markups oder Markupdefinitionen grundlegend braucht, ist auch nicht gerade neu.

Ein Gag wäre ein Lehrbuch in mehreren Bänden, dass sich übergreifend all dieser Themen annimmt und explizit eine Erweiterung um Themengebiete erlaubt. Die Bände geben an, was eigenständig lesbar ist und können sich gegenseitig referenzieren, ohne dass die ganze Lehrbuchreihe für immer verdammt ist, als ein einzelnes immer unfertiges Lehrbuch zu erscheinen.

Solch ein Versuch ist ja in den Outdoor-Aktivitäten bereits drinnen. Vielleicht ähnlich machen? Vielleicht profitieren ja beide Projekte davon? Bei den Outdoor-Aktivitäten sind die Regeln oder auch nur Ideen, wann man etwas zu einem eigenen Band macht recht wage. Dazu eine Idee, wie es HIER lösbar sein könnte?

Oder wird es doch nur ein "Apache, PHP, MySQL"-Buch? --Oliver Merkel 23:37, 14. Jan 2005 (UTC)

Es geht mehr um die Grundlagen wie (X)HTML, CSS, JavaScript, XML und eventuell noch PHP. Die Themen sind eng miteinander verzahnt. IMHO macht es deshalb Sinn, die Bücher modular aufzubauen. Die Erweiterung um neue Themen sollten eigentlich keine Probleme bereiten, da man ja ein zusätzliches Buch leicht der Reihe hinzufügen kann. -- Daniel B 00:05, 15. Jan 2005 (UTC)

Was haltet ihr davon, Websiteentwicklung mit Bindestrich, also "Website-Entwicklung" zu schreiben. Die zwei e's hintereinander sehen irgendwie komisch aus. Ist für mich auch von meinem Sprach/Rechtschreibgefühl schöner. --aleχ 14:02, 30. Mär 2005 (UTC)

Aufbau

Ich hab mir schonmal sowas in der Art vorgestellt, kommentieren und ändern, wenn etwas nicht passt. --Progman 22:54, 14. Jan 2005 (UTC)

Inhaltsverzeichnis
- XHTML
  - Beschreibung
  - Geschichte
  - Aufbau
  - Grundgerüst
  - Block- und Inlineelement
  - Erste Seite
  - ...
  - Index?
- CSS
  - Beschreibung
  - Geschichte
  - Aufbau
  - Grundlagen
  - ...
  - Index?
- PHP
  - Beschreibung
  - Aufbau
  - Grundlagen
  - ...
- XML
  - Beschreibung
  - Syntax
  - DTD (?)
  - ...
- XSLT (oder war es XSL...)
  - Beschreibung
  - Syntax
  - ...
- JavaScript
  - Beschreibung
  - Syntax
  - ...

Es fehlen IMHO noch Bücher zu JavaScript und XML. -- Daniel B 00:16, 15. Jan 2005 (UTC)

So, oder sollte man XML (und XSL(T)) vor PHP packen?

Ich würde ehr die Reihenfolge in XHTML, CSS, JavaScript, XML, XSLT und dann PHP ändern. Aber das ist natürlich auch wenig Geschmacksache und man kann die Reihenfolge später ja immer noch ändern. Aber ich denke, der Themenbereich ist damit soweit abgesteckt. -- Daniel B 09:14, 15. Jan 2005 (UTC)

HTML

IMO sollten wir durchgehen XHTML 1.0 strict lehren. Desweiteren sollte man wie folgt einrücken:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf8" />
        <title>Meine Homepage</title>
    </head>
    <body>
        <p>
            Dies ist ein Beispiel.
        </p>
    </body>
</html>

--Progman 22:54, 14. Jan 2005 (UTC)

ACK. -- Daniel B 00:16, 15. Jan 2005 (UTC)

Wie wäre es denn, für die Einrückung zwei statt vier Leerzeichen zu nutzen? IMO genügend, um die Struktur zu erkennen, benötigt aber etwas weniger Platz und sollte zu weniger horizontalen Scrollbalken im Browser führen... --Underdog 13:23, 18. Mär 2005 (UTC)

Das sind jetzt natürlich persönliche Meinungen wie weit man nun Einrückt. 2 Leerzeichen find ich persönlich zu kurz um die Struktur zu erkennen, deswegen habe ich die Beispielquellcodes mit 4 Leerzeichen eingerückt. Es gibt keine Regel wie weit man einrücken soll aber die Beispiele hier sollten alle gleich tief eingerückt werden. --Progman 13:57, 18. Mär 2005 (UTC)

Ich schließe mich der Meinung von Underdog an. Bei mir bekomme ich auch immer wieder die Scrollbalken zu sehen. Die Struktur müsste auch mit 2 Leerzeichen noch gut zu erkennen sein.-- Daniel B 16:14, 18. Mär 2005 (UTC)

CSS

Die Beispiele sollten die folgende Form haben:

selector {
    eigenschaft: 'fooBar';
}

--Progman 22:54, 14. Jan 2005 (UTC)

PHP

Die Beispiele sollten den Pear-Coding-Standard erfüllen. --Progman 22:54, 14. Jan 2005 (UTC)

Artikelnamen

Folgende Artikelnamen?

Websiteentwicklung (So wie Mathematik, mit einem entsprechendem Bild)
Websiteentwicklung: Inhaltsverzeichnis (Alle Punkte aufgelistet)
Websiteentwicklung: HTML (Nur die HTML-Kapitel aufgelistet)
Websiteentwicklung: HTML: Beschreibung (Der einzelne Artikel)

--Progman 22:54, 14. Jan 2005 (UTC)

Ja, ich würde dann für die einzelnen Bücher wie in Mathematik noch einen Fortschrittsbalken einbauen. Mann kann ruhig erkenne, dass es sich noch um einzelne Bänder handelt, die aber modular aufeinander aufbauen. -- Daniel B 00:16, 15. Jan 2005 (UTC)

Navigationsvorlagen

Für die einzelnen Bände XHTML, CSS, PHP und

ganz oben in jedem Kapitel und im Inhaltsverzeichnis der Bücher. Also sowas wie

{{Navigation Reihe Buch|
 Websiteentwicklung|
 Websiteentwicklung: HTML|
 Websiteentwicklung: HTML: Grundgerüst}}
 ...content...
 {{Navigation_zurückhochvor_buch|.....}}

vorschläge, änderungen? --Progman 22:54, 14. Jan 2005 (UTC)

Titelbild

Wie wäre es, wenn wir noch ein ansehliches Titelbild gestalten würden? Nur Blau sieht irgendwie langweilig aus. Was denkt ihr dazu? --Swissgenie 21:02, 21. Jan 2005 (UTC)

Sollte man mal allgemein für die ganzen Bücher der Wikibooks drüber nachdenken. Aber hier wohl erst mal ein wenig Inhalt.

Ich nehme an, dass aus dem Inhalt heraus gute Ideen für so ein Titelbild, dass dann auch zum Buch passt, entstehen.

Aber wenn jetzt schon ein satter Vorschlag gestaltet wird... warum nicht? Lizenzprobleme bei der Motivwahl natürlich immer brav berücksichtigen. --Oliver Merkel 22:54, 21. Jan 2005 (UTC)

Interessant wäre auch, die Art der Nachbearbeitung von Screenshots und Fotos zu dokumentieren, um evtl. die Titelbilder mehrerer Bücher einander stilistisch anzugleichen und so den Wiedererkennungswert zu erhöhen. Quasi als Motto "Wikibooks ist ein Gemeinschaftprojekt"... Am besten hier auch wieder freie Software einsetzen... GIMP / OpenOffice. Nur erst mal als Idee. --Oliver Merkel 22:59, 21. Jan 2005 (UTC)

Auf dem dunklen Blau kann man die Schrift recht schlecht erkennen. Ist das nur bei mir so? -- Daniel B 12:02, 22. Jan 2005 (UTC)

Der Kontrast ist wirklich nicht gut gewählt. Sollte man vielleich ändern. Die Frage ist nur in was... --Progman 12:25, 22. Jan 2005 (UTC)

Hab mal die Farbe angepasst. Wie findet ihrs? -- Daniel B 14:38, 24. Jan 2005 (UTC)

Änderungsvorschlag

Hallo,

Erstmal kurze Vorstellung meinerseits: Ich heiße Alexander Koch, gehe jetzt in die zwölfte Klasse und bin XHTML-/CSS-Webseiten-Ersteller, der sich vor allem auf barrierefreie Webgestaltung spezialisiert hat. Ich mag sauberen Code nach XHTML-Strict, mit Augenmerk auf Semantik. Hier mein Versuch an der Mitarbeit an einem professionellem Buch, das XHTML und CSS von Grund auf sauber und klar darstellt, und gestalterische Aspekte (siehe Konzept) nicht außer acht lässt. :-)

Ich hatte mir schon früher mal ein Konzept für ein solches Projekt ausgedacht, und wollte ein WikiBook zu diesem Thema gründen. Leider hatte ich dann zum zweiten Schritt noch nicht so richtig Zeit. Um jetzt aber kein zweites Buch zu gründen, würde ich gerne an diesem mitarbeiten, jedoch versuchen, die Ideen meines Konzeptes einfließen zu lassen (an dem ich selbst mehrere Tage gearbeitet habe), da ich meine, dass in diesem interessante Anreize stecken. :-)

Da ich es nicht so gut finde, XHTML und CSS getrennt in verschiedene Bände zu machen, sondern vielleicht zu einem Buch, dass sich allgemein mit statischen Webseiten beschäftigt, und allem was dazu gehört. Ein zweiter Band könnte dann Erweiterungen wie XML, PHP, ECMAScript, (hier würde ich aber probieren zu vermeiden, zu viel auf einmal abdecken zu wollen) etc. darstellen, naja, hier mal mein Konzept:

Gliederung Band 1:

Einführung

(Einleitung, Aufbau, Werkzeuge, Architecture of the World Wide Web, Entwicklung, ...)

Part I: XHTML

(Betonung auf Semantik, Strictness, WCAG, ...)

Part II: CSS

(Inkl. Media-Types, Frameersatz, Browserspez. Hacks)

Part III: Grafik und Design

(Designregeln, Aufbau, Layout, Grafikformate)

Part IV: Zugänglichkeit und Benutzerfreundlichkeit

(Accessibility, Usability)

Part V: Schritte eines Web-Projekts

(Planung, Graf. Entwurf, ..., [Prüfung: Validierung, Barrierefreiheits-Check, Rechtliches], Hochladen)

Anhang

(XHTML, CSS, Entity-Referenzen, Sprachcodes, robots.txt, .htaccess, HTTP-Statuscodes)

Und dann Ideen für den Zweiten Band "Erweiterungen" (Der jetzt nicht in meinem eigenen Konzept vorhanden ist):

Gliederung Band 2:

Part I: XML und das Semantische Web

(XML, Semantic Web, RDF, RSS, Dublin Core)

Part II: XSLT

(...)

Part III: PHP

(...)

Part IV: ECMA-Script (JavaScript)

(Bin eher dafür, dass wegzulassen/bin nicht gerade so der JavaScript-Fan, weil es meist wirklich unnötig ist)

Anhang: RDF, RSS, Dublin-Core, PHP

Im ersten Band ist sozusagen alles untergebracht, was man so für eine "gescheite" statische Webseite braucht, da denke ich gehört auch Grafik, Entwurf, Barrierefreiheit und Usability dazu. Hier zeigt sich natürlich auch klar der Vorteil an einem Wiki-Projekt, da daran jeder mitarbeiten kann, u.A. auch Grafik/Design-Profis, die nicht umbedingt (X)HTML können müssen. :-)

Na ja, bitte sei mir böse, aber das Konzept des mehrbändigen Buches jetzt wieder umzuschmeißen halte ich für keine so gute Idee. Der Arbeitssauwand währe sehr hoch (Seiten verschieben, Navigationsleisten überarbeiten, entstandene Redirects löschen) und der Nutzen demgegenüber ist ehr gering. -- Daniel B 18:18, 29. Mär 2005 (UTC)

Klar, ich kann deine Argumentation verstehen. Guter Kompromiss sehe ich wahrscheinlich darin, die "Parts", bzw. "Teile" in meinem Konzept als Band zu interpretieren. Dann würde ich jedoch dafür plädieren, die Parts, die ich oben vorgeschlagen habe: also "Grafik und Design" (Für allgemeine Webdesign-Prinzipien) und "Zugänglichkeit und Benutzerfreundlichkeit" (Für Accessibility und Usability) nach dem Band über CSS einzuschieben, da ich dies für sehr wichtige Aspekte der Website-Entwicklung halte. Es gibt zu viele schlechte und nicht barrierefreie Webseiten im Netz, die Leser sollen es aber gleich von Anfang an richtig lernen. Allgemein sollte man im gesamten Buch auf Barrierefreiheit achten, der zweite vorgeschlagene Band sollte dann erweiterte Konzepte, und direkt Punkte der Web Content Accessibility Guidelines und Usability ansprechen. Wie denkt ihr darüber? --aleχ 13:59, 30. Mär 2005 (UTC)

Achso, hatte ich vergessen: Meine Idee für einen Teil "Schritte eines Web-Projekts" will ich nochmal unterstützen, weil ich denke, dass man hier viel mehr schreiben kann, als es im ersten Moment aussieht. Dieser Teil gehört aber eher ans Ende, also hinter dem dynamischen Teil (PHP, etc). Ich finde das sehr wichtig, da man meist nicht weiss, wie man jetzt vorgehen muss, wenn man eine Website entwickeln will. Hier das Konzept dazu:

Grob-Planung (Was wird gebraucht? dynamisch/statisch? Anforderungen? Wer arbeitet mit? Zeitrahmen, etc.)
Struktur-Planung (Navigationsebenen, Vorteile/Nachteile, Sitemap)
Grafischer Entwurf (In Gimp, Wichtige Elemente, Navigation, Logo)
Technischer Entwurf (Struktur des XHTML-Templates/der Datenbanksätze, ...)
... Andere Punkte, findet man sicher noch was
Prüfung
- auf Validität, CSS/XHTML, Schema validator
- auf Barrierefreiheit, Checkliste, etc.
- (evtl. Usability checks, Wie vorgehen, Mitarbeiter "Aufgaben verteilen, etwas auf der Website zu finden/machen", Feedback, Geschwindigkeit)
- auf Rechtliches (Hier kann man die WikiMedianer aus der Jura-Ecke bitten, ist denke ich ein wichtiges Thema, die Website danach auf rechtliche Sachen zu prüfen.
- etc.
Publizieren (Wie funktioniert das mit dem Webspace? Wie kann ich hochladen? [FTP, etc])
Promotion (Eintrag in Suchmaschinen, Linklisten, ...)
Wartung (Wie hält man die Seite aktuell, etc.)

--aleχ 14:39, 30. Mär 2005 (UTC)

Wenn ich dich richtig versteht, willst du ein Buch mit dem Titel "Schritte eines Web-Projekts" zusätzlich einfügen. Klar kann man das. Das ist überhaupt kein Problem. -- Daniel B 05:13, 31. Mär 2005 (UTC)

Lehrbuchdidaktik

Besondere Achtung auf Lehrbuchdidaktik (Wer den Stryer/Campbell kennt, weiss was ich mein) Gestaltung mit übersichtlichen Info-Boxen, Zusatzinformationen, Titeln, +Übungen, Literaturhinweise, Schlüsselbegriffe, Aufgaben, Überschriften, Gliederung, Abbildungen...

Ja, das gefällt mir sehr gut. Davon würde ich gerne noch mehr hören. Eventuell könntest du auch mal damit beginnen, ein beliebiges Kapitel nach deinen Vorschlägen umzugestalten, damit man sieht, was du genau meinst. Vielleicht wird man nicht alle Ideen übernehmen, aber ich bin mir fast sicher, dass einiges in das Projekt einfließt. -- Daniel B 18:18, 29. Mär 2005 (UTC)

Hier eine kleine Zusammenfassung, was ich aus eigenen Erfahrungen aus didaktisch erstklassigen Büchern (Alberts "Molecular Biology of the Cell", Stryer "Biochemie", Campbell, etc. in aktueller Auflage) herausgelesen und interpretiert habe (Wobei ich kein Profi auf dem Gebiet bin). Meine eigenen Ideen hab ich jetzt auch mal dazu geschrieben. Wenn sich andere Beteiligen wollen, könnte man den ganzen Text ja auf eine eigene Seite verschieben. --aleχ 13:20, 3. Apr 2005 (UTC)

Ein Vorwort sollte den Leser zum Stoff motivieren

Ein Vorwort ist für den, der sich jetzt endlich aufgerafft hat, sich mal HTML anzugucken, weil die anderen die ganze Zeit davon erzählen, sicher nochmal ein Motivationsschub. Ich denke, dass sowas ganz effektiv sein kann. Normalerweise überspringt man ja häufig das Vorwort, das wäre hiermit aber in selterner der Fall, IHMO.

Das Vorwort fehlt noch. Sollte aber natürlich noch kommen. -- Daniel B 19:58, 3. Apr 2005 (UTC)

Die Betonung sollte besonders auf motivierend liegen. Es gibt genug langweilige Vorwörter, die überspringt man dann schnell. Kommt natürlich erst ganz am Ende. --aleχ 20:24, 3. Apr 2005 (UTC)

Texte sollen leicht verständlich für alle sein

Da ich selber am Haus der Jugend einen HTML-Kurs mit Zwölfjährigen leite, und ich auch ältere Leute kenne, die sich der Materie erst langsam nähern, würde ich weiterhin besonderen Wert auf allgemeine Verständlichkeit -- auch für 12-Jährige und Themenfremde -- legen. Ich denke es gibt hier zu viele schlechte Beispiele, das würde so ein Buch besonders hervorheben. Mir hat damals irgendwie ein verständliches Buch gefehlt. (Sonst kann man sich auch gleich die Specs lesen, da steht ja alles genau und per Definition korrekt drin... ;-)

Da sprichst du mir aus dem Herzen. Ich bin auch der Meinung, dass die Didaktik bei den Wikibooks eine sehr wichtige Rolle spielt. Insbesondre hat man hier die einmalige Möglichkeit auf der Diskussionsseite zwischen Autor und Leserschaft zu kommunizieren - eine Möglichkeit von der leider bisher zu wenig gebrauch gemacht wurde. -- Daniel B 18:18, 29. Mär 2005 (UTC)

Ergänzung: Ausserdem gibt es ja noch Guideline 14 der WCAG: Ensure that documents are clear and simple so the may be more easily understood. 14.1: Use the clearest and simplest language appropriate for a site's content [Priority 1] (Vergewissere dich, dass die Dokumente klar und einfach sind, sodass diese einfacher zu verstehen sind. 14.1: Verwende die klarste und einfachste Sprache, die angemessen für den Inhalt der Website ist [Priorität 1]) --aleχ 13:20, 3. Apr 2005 (UTC)

Ergänzung für die Kommunikation zwischen Autoren und Leser: Wenn am Ende jedes Buches eine Extra-Seite eingerichtet wird, die allein dem Zweck des Feedbacks dient. Könnte auch als Rezension im Sinne eines Klappentextes sein. Die Seite sollte aber so gestaltet sein, dass es einzelne direkt anspricht, d.h. in verschiedene Kategorien/Überschriften, je nach Leser: "Feedback von Themenfremden", "Feedback von Jüngeren", "Feedback von Programmierern", etc. Derjenige, der zu einer Kategorie gehört, fühlt sich direkt angesprochen und ist deswegen auch motivierter, seinen Kommentar unter der jeweiligen Überschrift zu setzen.

Eine Einleitung sollte den praktischen Sinn erläutern

Grundsätzlich sollte jeder Abschnitt damit begonnen werden, dem Leser zu erklären, was der behandelte Gegenstand jetzt konkret für ihn bringt, bzw. wozu er gut ist/wieso er wichtig ist. A la "Damit Sie mit Betonungen wichtige Begriffe aus einem Text hervorheben können und somit dem Nutzer erleichtern, den Text zu überfliegen, beschäftigt sich der nächste Abschnitt hiermit." Das ganze sollte jetzt aber nicht darin ausarten, alle 20 Vorteile von CSS aufzuzählen, etc. Das ganze arbeitet den Text auch ein bisschen auf, man hat nicht die ganze Zeit nur Fakten, Fakten, ...

Didaktik ist eigentlich ein komischer Begriff, man kann nämlich nicht gelernt werden, sondern nur den Lernenden den Stoff nahebringen und diesen überzeugen, dass es gut ist ihn zu lernen.

Ein Kapitelfahrplan zeigt dem Leser wo es lang geht

Am Anfang jedes Kapitels finde ich einen gut gegliederten, aus vier als Aufzählung bestehenden Sätzen ganz angenehm. Dann hat man gleich die Übersicht, was einem im folgenden erwartet. Dann dazu bei jedem Kaptiel einen einleitenden Text, der das ganze auch in den groben Großzusammenhang stellt.

Eine Einleitung sollte natürlich jedes Kapitel haben. Aber man sollte es nicht zu sehr formalisieren. -- Daniel B 19:58, 3. Apr 2005 (UTC)

Eine Abbildung mit Bildunterschrift hilft der Orientierung

Abbildungen sind sehr wichtig für das Verständnis und sollten nicht zu sparsam eingesetzt werden. Besonders gut finde ich hier, wenn man darauf achtet, das eine Bildunterschrift vorhanden ist, die den Sachverhalt nochmal kurz erläutert. Im Alberts ist auf jeder Seite eine bis zwei Abbildungen, ich habe dazu auch schon Bildunterschriften gesehen, die über eine Viertel Seite gingen. Man blickt nämlich vom Text auf und schaut dann die Grafik, kann aber nicht gleichzeitig in den Text gucken. Wenn man dann nochmal eine direkte Erklärung dazu hat, dann kann man das Bild viel besser mit dem Text verbinden. In der Bildunterschrift können auch ruhig bestimmte Sachverhalte nochmal erklärt werden, die im Text schon behandelt werden.

ACK. Eine Bildunterschrift, die eine viertel Seite lange ist, halte ich aber doch für übertrieben. -- Daniel B 19:58, 3. Apr 2005 (UTC)

Eine Betonung von Begriffen hebt Wichtiges hervor

Wenn ein neuer Begriff eingeführt wird, sollte dieser stark hervorgehoben (d.h. dickgedruckt) sein. Einen Satz mit einem wichtigen Sachverhalt, sollte als ganzes hervorgehoben (d.h. kursiv) dargestellt sein. Damit lässt sich auch mal gut über den Text drübergucken und es hilft beim Herausziehen wichtiger Information aus einem Text.

Beispiele: Formatierungen und Objekte, die man in ein HTML-Dokument einfügt, werden mit Elementen beschrieben. Links sind interaktive Verknüpfungen in einem Dokument.

Ich bin dafür neue Worte, die eingeführt werden, schräg zu schreiben. Fettschrift sollte wichtigen Bemerkungen vorbehalten bleiben. -- Daniel B 19:15, 3. Apr 2005 (UTC)

Info-Boxen machen Zusatzinformationen leicht erkennbar

Das finde ich bei Büchern immer ganz angenehm. Man hat quasi eine Box mit Zusatzinformationen oder eine Warnung, etc. Am Rand daneben befindet sich ein Symbol, dass darauf aufmerksam macht, ausserdem ist die Box vom normalen Text abgehoben. Man sollte es aber damit auch nicht übertreiben. Hier könnten Boxen mit (a) Quervernetzungen zu anderen Bänden, (b) Tipps, (c) Hintergrundinformationen, (d) Warnungen, usw. eingeführt werden, man bräuchte jedoch jemanden, der die Symbolgrafiken hierfür erstellt. Wie sieht es da mit der technischen Umsetzung im MediaWiki aus? Ist das Einfügen von Boxen mit einem Symbol am Rand direkt mit Bordmitteln möglich?

Möglich sind solche Boxen mit der MediWiki Software, wenn auch manchmal mit etwas Aufwand verbunden (bin darin aber selbst kein Spezialist). Für Quervernetzung zu anderen Bänden reicht IHMO die Verlinkung der Begriffe. Infoboxen sollten für Tipps, Hintergrundinformationen oder Warnungen vorbehalten bleiben. -- Daniel B 19:23, 3. Apr 2005 (UTC)

Hab ich dazu genommen, weil Quervernetzungen ja eigentlich eh meistens als Hintergrundinformationen verstanden werden können. Das man eben etwas in XHTML einführt und dann vielleicht in so einer Box auf eine bestimmte Information zu CSS vorgreift. --aleχ 20:29, 3. Apr 2005 (UTC)

Definierende Überschriften geben die Hauptaussage vor

Das finde ich persöhnlich ein Special in allen drei modernen Lehrbüchern: Campbell, Stryer und Alberts. Und zwar sind die Überschriften immer ganze Sätze, außer direkt in den Kapiteln. Aber alle Sektionen haben ganze Sätze als Überschriften, die dann in Definitionsform sind. Das ist extrem praktisch, wenn so eine Überschrift schon die Hauptaussage eines Abschnitts enthält. Hier mal ein Beispiel zur Verdeutlichung, was ich meine:

XHTML-Grundlagen:

XHTML ist eine Auszeichnungssprache für Webseiten
Elemente werden zum Strukturieren von Information verwendet
XHTML-Seiten sind in zwei Bereiche unterteilt
Die Elemente <h1> bis <h6> werden für Überschriften verwendet
Mit dem <p>-Element lassen sich Absätze auszeichnen
Mit Betonungen lässt sich Leben in den Text bringen
Elemente können nähere Beschreibungen enthalten
Kommentieren Sie Ihren Quelltext mit
Eine !DOCTYPE-Anweisung gibt dem XHTML-Dokument den letzen Schliff

Dadurch kann man schon durch das Lesen des Inhaltsverzeichnis viele Informationen rausziehen und hat vor dem Lesen des jeweiligen Abschnitts schon eine Fragestellung worum es geht. Das hilft auch, und suggestiert automatisch ein bisschen die PQ3R-Methode beim Lernen. Zwar eine Umgewöhnung, aber Lehrbuchdidaktisch sicherlich sinnvoll.

Der Seitentitel selbst sollte nicht zu lang sein. Die Schriftgröße lässt sich nur bei den Zwischenüberschriften ändern. Ein Seitentitel, der über mehrere Seiten geht, sieht IHO nicht so doll aus. -- Daniel B 19:28, 3. Apr 2005 (UTC)

Eine Liste von Schlüsselbegriffen hilft der Rekapitualtion

Am Ende jedes Kapitels findet man im Stryer eine Liste mit bis zu 30 Schlüsselbegriffen (in drei Spalten nebeneinander angeordnet), die in dem Kapitel aufgetaucht sind, jeweils mit Seitenzahl (bei uns Links). Damit man daran selbst nochmal den kompletten Stoff sich ins Gedächtnis rufen kann. Wenn die Begriffe so isoliert stehen, geht das wirklich ganz gut, hat man den Sinn eines Begriffs vergessen, kann man ja nachschlagen. Hier ein Beispiel für Schlüsselbegriffe aus dem Kapitel XHTML-Grundlagen:

HTML-Tag, Element, <html>, <head>, <body>, Auszeichnungssprache,

<h1> - <h6>, <em>, <strong>, Attribute, Schachtelung, <p>, Kommentare

Nein, das finde ich keine gute Idee. Das sieht unschön aus und bringt gar nichts, weil sich die Begriffe eh kein Mensch durchliest. Da lieber Wiederholungsfragen, das bringt mehr. Und zum Nachschlagen kann man einen Index am Ende des Buches erstellen. -- Daniel B 19:58, 3. Apr 2005 (UTC)

Literaturhinweise geben Lesern eine weitere Perspektive

Nach den Schlüsselwortern findet sich im Stryer immer eine Liste "ausgewählter Literatur", die für eine weitere spezialisierte Erarbeitung empfohlen wird. Ich denke schon, dass sowas für ein Werk zur Website-Entwicklung sinnvoll wäre, meine jedoch, dass sich diese Liste relativ kurz halten lässt. Hier könnte man zum Beispiel eine genaue Erklärung zur Entstehung von XHTML oder eine Erklärung der XHTML-Modularisierung verlinken. Nach Möglichkeit in einem deutschen Buch auch deutschsprachige Quellen, denn es gibt genug Leute, deren Englisch nicht gut genug für die Spezifikationen des W3C sind. Das verärgert diese Leute dann eher

Gibt’s in vielen Büchern zum Thema EDV schon am Ende des Buches. Sollte natürlich auch hier eingerichtet werden. -- Daniel B 19:58, 3. Apr 2005 (UTC)

Zusammenfassungen geben dem Leser eine Übersicht

Ganz wichtig sind außerdem die Zusammenfassungen am Ende jedes Kapitels. Hier wird jedes der vier Hauptsektionen aus dem Kapitelfahrplan nachmal in einem zehnzeiligem Absatz kurz erläutert.

Aufgaben sind für das Vertiefen von Wissen geeignet

Im Stryer sind nach jedem Kapitel einige (bis zu 25) Aufgaben, jeweils mit Lösungen im Anhang. Diese finde ich sehr wichtig um den Stoff zu vertiefen. Ich würde aber nicht vorschlagen, dass wir 20 Aufgaben, a la "Schreiben sie eine HTML-Seite, die ..." machen, sondern die ersten 10 Aufgaben Fragen für vernetztes Wissen sind, und dann später drei oder vier solche "Schreiben sie..." Aufgaben sind. Die Wissensfragen jetzt nicht a la "Welches Element wird für eine starke Betonung verwendet?", da fühlt sich der Leser dann eher unterfordert, sondern wo direkt Wissen angewendet wird. Mir fällt jetzt gerade kein Beispiel ein, liefere ich oder jemand anderes dann nach.

ACK. -- Daniel B 19:58, 3. Apr 2005 (UTC)

Ich würde gerne einfach mal das XHTML-Grundlagen-Kapitel dazu umgestalten. Hierzu will ich auch meinen Ansatz aus den Unterlagen meines HTML-Kurses am Haus der Jugend verwenden. --aleχ 13:20, 3. Apr 2005 (UTC)

Das kannst du tun. Nur mut. Ich bin gespannt aufs Ergebnis. Ach ja, was ich noch unbedingt loswerden will: Die Formalien sind natürlich wichtig, aber ich der Meinung, dass inhaltliche Aspekte dabei nicht zu kurz kommen sollten. Ein Beispiel: Du kannst OOP in PHP noch so doll mit Boxen, hervorheben von Worten und was weiß ich noch erklären. Wenn der Leser aber deinen Erklärungen nicht folgen kann bringt der ganze Schnickschnack nichts. Aber du hast ja oben bereits gesagt, dass die Erklärungen auch für einen 12jahrigen verständlich sein sollten. Wollt's ich nur noch mal erwähnen. -- Daniel B 19:58, 3. Apr 2005 (UTC)-- Daniel B 19:58, 3. Apr 2005 (UTC)

Ja, klar. Das sieht alles so ein bisschen viel auf einmal aus, ich hab einfach mal zusammengefasst, was mir so eingefallen ist. Das sollte natürlich alles nur Anregung sein und keine Regel. Hab mal gesammelt, weil du meintest, du würdest da gerne ein bisschen mehr drüber hören. Ich werd jetzt sicher nicht auf Anhieb das alles einbringen können, hab nur mal lose Gedanken aufs Wiki gebracht. Was hälts du davon, wenn man nach Ende der Dikussion einige der Ideen auf einer Seite "Lehrbuchdidaktik" in das WikiBooks Handbuch integriert? --aleχ 20:40, 3. Apr 2005 (UTC)

Im Handbuch hab mal schon vor langer Zeit mit Hilfes:So schreibe ich gute Bücher angefangen. Da kannst du ja deine Ideen zusätzlich noch erläutern. Die Seite war von mir auch ursprünglich so gedacht, dass noch weiter Punkte ergänzt werden können. -- Daniel B 05:32, 4. Apr 2005 (UTC)

Ich bin gespannt auf euer Feedback.

Viele Grüße, aleχ

zweites PHP-Buch für Personen ohne Programmiererfahrung

Letzter Kommentar: vor 10 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Hallo, Wie wäre es, ein Buch zu machen für Personen ohne Programmiererfahrung? Ich habe soetwas schon bei http://wiki.selfhtml.org/wiki/Benutzer:Thomas131/phptut versucht. Ev. will das jemand verschieben und weiterarbeiten. Mir fehlt dazu momentan die Zeit.

-- Thomas1311 11:40, 10. Mai 2014 (CEST)Beantworten

Abschnitt hinzufügen

Diskussion:Websiteentwicklung

Frage zum Titel

Aufbau

HTML

CSS

PHP

Artikelnamen

Navigationsvorlagen

Titelbild

Änderungsvorschlag

Gliederung Band 1:

Gliederung Band 2:

Lehrbuchdidaktik

Ein Vorwort sollte den Leser zum Stoff motivieren

Texte sollen leicht verständlich für alle sein

Eine Einleitung sollte den praktischen Sinn erläutern

Ein Kapitelfahrplan zeigt dem Leser wo es lang geht

Eine Abbildung mit Bildunterschrift hilft der Orientierung

Eine Betonung von Begriffen hebt Wichtiges hervor

Info-Boxen machen Zusatzinformationen leicht erkennbar

Definierende Überschriften geben die Hauptaussage vor

Eine Liste von Schlüsselbegriffen hilft der Rekapitualtion

Literaturhinweise geben Lesern eine weitere Perspektive

Zusammenfassungen geben dem Leser eine Übersicht

Aufgaben sind für das Vertiefen von Wissen geeignet

zweites PHP-Buch für Personen ohne Programmiererfahrung