Diskussion:Websiteentwicklung: Inhaltsübersicht

• Todo-Liste des Buchprojekts Webentwicklung

Solange Todo-Einträge hier noch nicht ausgiebig genutzt werden, ist eine Unterteilung in verschiedene Buchprojekte nicht unbedingt notwendig. Hier sind derzeit benutzereigene Todo-Listen effektiver. (siehe Hilfe:Todo-Listen)

Zusammenfassung des Projekts

• Zielgruppe: Personen mit PC-Grundkenntnissen und Interesse am Erstellen von Websites.

• Lernziele: Erstellen einer Website

• Buchpatenschaft / Ansprechperson:

• Co-Autoren sind erwünscht!

• Richtlinien für Co-Autoren:
  • Anrede:
  • Rechtschreibung: neue deutsche Rechtschreibung

• Projektumfang und Abgrenzung zu anderen Wikibooks:

• Aufbau des Buches:

Diskussion

Beschreibung der Bücher

Gleichberechtigung und Feminismus in allen Ehren. Aber das hier ist lächerlich:

Handbuch Webdesign eher für DesignerInnen als für ProgrammiererInnen

Gibt es einen objektiv sinnvollen Grund beim Nutzer einen Knoten im Hirn zu erzeugen?

93.193.75.182 01:55, 5. Jun. 2013 (CEST)

Der Knoten im Hirn wird ja schon durch den denglischen Begriff 'Websiteentwicklung' bei dieser Buchsammlung erzeugt, da stellt diese Stilblüte dann auch keinen nennenswert bemerkenswerteren Beitrag dar. Und vielleicht ist die Zielgruppe des anderen Buches ja mit der Formulierung ganz gut getroffen ;o) Wäre 'Handbuch Webdesign eher für Designende als für Programmierende' eine schönere Formulierung? Oder vielleicht eher: 'Handbuch Webdesign - eher für all jene, die lieber designen als zu programmieren' - wobei man eigentlich auch noch anmerken könnte, daß einige Bücher dieser Buchreihe gar nichts über das Programmieren enthalten, etwa XHTML, CSS, Barrierefreiheit, XML, von daher ist bei diesen Büchern der Gegensatz gar nicht gegeben - oder auf einer anderen Ebene, etwa Zugänglichkeit gegenüber Design. Und was man etwa mit PHP erreichen kann, dafür stellt Design keine Alternative dar. Wenn man seine Inhalte nicht zugunsten des Designs einschränken will, wird man also gar nicht um etwas Programmieren herumkommen. Man könnte also auch formulieren: 'Handbuch Webdesign eher für all jene, die es so genau gar nicht wissen wollen' ;o) Doktorchen 10:33, 5. Jun. 2013 (CEST)

Reihenfolge der Bücher

Sollten PHP und Java Script nicht besser ihre Plätze tauschen? IMHO währe es besser erst die ganze Clientseite anzugehen und anschließend mit der serverseitige Programmierung zu beginnen. --

Daniel B 15:17, 6. Mär 2005 (UTC)

Dem stimme ich voll und ganz zu und möchte außerdem ergänzen, dass das erste Buch XML sein sollte, da es sich bei XHTML um eine XML-basierte Sprache handelt. Eine XHTML-Seite ist zwangsläufig XML.--ChristianHujer 21:37, 7. Apr 2005 (UTC)

Na ja, XML am Anfang ist logisch richtig, auf der anderen Seite bekommt der Leser dann einen recht großen Abschnitt nur Theorie gleich zu Beginn zu lesen. Das dürft das XML Buch unter Umständen schwer verdaulich machen. -- Daniel B 04:42, 8. Apr 2005 (UTC)

Daniel B, ich teile Deine Bedenken, trotz dessen, dass ich die Umstellung vorgenommen habe. Ich habe das entsprechend auf Diskussion:Websiteentwicklung:_XML vermerkt. --ChristianHujer 07:51, 8. Apr 2005 (UTC)

Ich finde, dass XML nicht vor XHTML stehen sollte, weil die natürliche Lernreihenfolge einfach anders ist. Wenn jemand Themenfremdes an das Buch rantritt, wird er vor XML ersteinmal zurücktreten, weil das nicht so einfach anwendungs- und beispielorientiert nahegebracht werden kann wie beispielsweise XHTML. Leute, die sich in XHTML schon auskennen, oder generell Ahnung von der Materie haben, können sich die Bände ja in beliebiger Reihenfolge angucken.

Ich habe auch mal die Ideen aus der Haupt-Diskussionsseite eingebracht und die Vorschläge für drei weitere Bände hinzugefüg. --aleχ 18:07, 11. Apr 2005 (UTC)

Dem möchte ich widersprechen. Ohne XML kein XHTML. XML kann man auch sehr einfach erklären, und während der Grundlagen eignet sich XHTML sowieso als gutes Beispiel.

Und dann: der ganze technische Schrott im Netz kam doch von der Ignoranz, nicht SGML lernen zu wollen. Wollen wir hier das zehntausendste Web-Kompendium, das dieselben Fehler von 99% der Web-Literatur wiederholt?

Einen wichtigen Fehler der Web-Literatur sehe ich darin, dass die Erklärungen zu kompliziert sind, und sie deshalb keiner versteht. Damit das Buch etwas herausragendes wird, sollte es genau diesen Fehler nicht machen, und zwar einfach zu unverständlich zu sein. --aleχ 22:44, 17. Apr 2005 (UTC)

Stellt man XHTML vor XML, und erklärt XHTML dann so, dass ein Leser fehlerfreie Webseiten schreiben kann, gibt's einen Haufen Überschneidungen mit XML. Grundsätze des Dokumentaufbaus, Wohlgeformtheit und Gültigkeit, Elemente und Attribute bei den Grundlagen, Processing Instructions bei der Einbindung von Stylesheets, xml:lang-Attribut bei der Internationalisierung, alles zu DTDs sowie Definition und Einbindung externer Entitäten bei der Entwicklung eigener XHTML-Module.

XHTML ist XML. Die Reihenfolge XHTML vor XML ist wie die praktische Führerscheinprüfung vor der Theorie-Prüfung. Das führt dazu, dass Leute glauben, (X)HTML zu können, aber bereits von den Grundlagen absolut keine Ahnung haben: angefangen mit falscher Terminologie (z.B. Tag statt Element) über Fehler bei der Internationalisierung und Barrierefreiheit führt das bis hin zu den 98% ungültigen Webseiten im Netz.

Nicht zu vergessen, dass bei XHTML keine Fehler verziehen werden, und die Leute sollten wissen, warum. XHTML wird vom Browser (sofern er es korrekt verarbeitet) nur in zumindest wohlgeformter Form akzeptiert, damit sind wir schon wieder bei XML.

--ChristianHujer 23:34, 11. Apr 2005 (UTC)

Achja, siehe Websiteentwicklung: XHTML: Kommentare. Das hatte mich damals dazu bewegt, das Kapitel XML vor das Kapitel XHTML zu stellen. Kommentare in XHTML sind XML Kommentare. Redundanz sollte vermieden werden. Welche Unterschiede gibt es zwischen Kommentaren in XHTML und Kommenaren in XML? Keine, weil XHTML XML ist. Würden sich ein Kapitel über Kommentare im XML-Buch und ein Kapitel über Kommentare im XHTML-Buch signifikant unterscheiden, gibt's etwa Dinge über Kommentare in XHTML zu sagen, die nicht bei XML genannt werden sollten oder umgekehrt? Wohl kaum. Und Kommentare werden sicher nicht das einzige Thema dieser Art bleiben. --ChristianHujer 23:46, 11. Apr 2005 (UTC)

Ich finde, dass ist für den unbedarften Anfänger viel zu viel auf einmal. Ich würde nicht sagen, dass der Leser etwas über Dokumenttypen wissen muss, bevor er die erste Überschrift mit einem dazugehörigen Absatz geschrieben hat. Ich denke auch nicht, dass sich die Grundlagen von XML anschaulich darstellen lassen, für jemanden, der noch nie mit irgendeiner Form von HTML gearbeitet hat. Deswegen würde ich zum Beispiel im Kapitel "Kommentare" die Backus-Naur-Form rausnehmen, und alle Sonderfälle, etc. Dass man Kommentare nicht schachteln kann lernt der Leser durch Erfahrung und logisches Denken, das einzige was nötig wäre, ist eine Zeile hinzuzufügen, dass ein Kommentar selber kein '--' enthalten kann. Wenn man aber, um XHTML zu lernen, sich erst durch lange Kapitel mit theoretischen Abhandlungen zu Dokumenttypendefinietionen durchhangeln muss, denke ich schreckt das in jedem Fall ab.

Um der Kompromissbildung beizutragen: Eine Möglichkeit (die mir aber nicht wirklich gefällt) wäre, dass XHTML-Buch so zu schreiben, dass man es auch ohne das XML-Buch versteht, oder das XML-Buch in zwei Bereiche aufzuspalten: Die "Basics" in denen alles erklärt wird, was man später für einen XHTML-Anfang zwingend braucht, darunter sehe ich jetzt nicht: Wie definiert man einen Documenttype, Processing-Instructions, etc. Ich würde aber lieber den XHTML-Band vorziehen, unter anderem auch mit folgendem Argument: Wenn der Leser einmal XHTML-Kommentare und Element-Schachtelungen, Attribute, usw. verstanden hat, kann das dann das Erlernen von XML extrem erleichtern.

Das ganze geht ein bisschen meinem Konzept der einfachen Verständlichkeit entgegen. Wir können das aber auch auf der Diskussionsseite über das Gesamtwerk diskutieren. Ich würde gerne demnächst am Werk einige tiefergehende Änderungen machen, die die Verständlichkeit betreffen. --aleχ 22:44, 17. Apr 2005 (UTC)

HTML 4.01

Habe das jetzt hier nur überflogen. Was spricht denn dagegen zuerst HTML 4.01 noch mit dazu zu nehmen? Schließlich ist das (vorallen STRICT) derzeit auch eine vollständig bestätigte W3C-Version und für die Menschen, die dann auf XHTML umsteigen wollen, sollten dementsprechend wirklich sich zunächst mit XML beschäftigen. Eventuell ergreife ich mit HTML4 auch einen Standpunkt, der bereits ausdiskutiert war? --KingCrunch 15:24, 2. Okt 2005 (UTC)

Umgekehrt. Wer sich für HTML4 interssiert, kann sich damit ja später beschäftigen.--Et2 20:15, 30. Aug 2006 (CEST)

Grafik und Deisgn <-> CSS

Warum "Grafik und Design" nach "CSS"? Ist das so unterschiedlich? --Et2 12:45, 1. Sep 2006 (CEST)

Kapiteldiskussion: Grafik und Design, Barrierefreiheit und Benutzbarkeit, Schritte eines Webprojekts

Ich finde, daß diese Kapitel:

1. (wenn überhaupt) in falscher Reihenfolge stehen
2. eigentlich eine generelle Einteilung in zwei Bereiche, nämlich Programmierung und Gestaltung, getroffen werden müsste
3. der Titel nicht sonderlich geschickt gewählt ist, im Bezug auf erwünschten "Leserfang" ;)

Das Kapitel HTML würde ich umbenennen in HTML/XHTML, um der chronologischen Reihenfolge der Entwicklung Rechnung zu tragen. Ausserdem finde ich, daß JavaScript gleich hinter CSS stehen sollte. Die anderen Kapitel gehen doch alle in die Richtung der serverseitigen Programmierung.

serverseitige Programmierung ist mehr als PHP

Ich wollte wissen, ob noch Sachen wie (Fast)CGI geplant sind, aufgenommen zu werden? Dann kann man nämlich auf PHP verzichten und gleich schöne Sprachen schreiben... --Keks Ger 02:56, 28. Jul. 2008 (CEST)

Diejenigen, die ihre erste Webseite bauen, werden sich vermutlich mit einem kostenfreien oder kostengünstigen Hosting-Tarif begnügen. Und in diesem Bereich ist PHP die einzige Skriptsprache, die heute nahezu überall verfügbar ist. --Feeela 16:21, 13. Okt. 2011 (CEST)

Zwei Bücher zum selben Thema

Schau mal bei Handbuch Webdesign vorbei, dass wir zwei Bücher haben, die ähnliche Themen behandeln, darauf möchte ich dich gerne hinweisen.

• Es wäre notwendig, eine Abgrenzung vorzunehmen. Das organisiert dann auch die Mitarbeit anderer, die sich zwischen den beiden Projekten entscheiden können.
• Würde es deiner Ansicht nach eine Möglichkeit geben, die beiden Projekte zusammenzufassen, hat ein Buch Vor- oder Nachteile???

Bitte als Hinweis verstehen, nicht als Kritik o. ä. Gleicher Beitrag auch beim anderen Buch... --InselFahrer 10:54, 5. Sep 2006 (CEST)

siehe Regal_Diskussion:Programmierung#Websiteentwicklung Bjelli 18:42, 11. Sep 2006 (CEST)

SMIL

Koennte was zum Thema SMIL beisteuern. Siehe http://de.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language. Ich habe inzwischen eine etwas ueberarbeitete Version des in dem Artikel verlinkten Textbuches zum Thema 2.1 verfuegbar, die ich auf SMIL 3.0 ergaenzen koennten. Waere das als Band 10 oder 11 erwuenscht? --Wvk 17:56, 4. Mär. 2009 (CET)

super Idee Wenn ich schlauer wäre, würde ich auch was beitragen =) --WissensDürster 21:25, 16. Apr. 2009 (CEST)

SVG

Ich weiß nicht ob es in euer Konzept passt, aber rein Thematisch währe SVG bei euch besser aufgehoben. --FischX 19:14, 29. Sep. 2009 (CEST)

+1, SVG gehört mittlerweile selbstverständlich zur Gestaltung von Webseiten (mittlerweile eher noch als XSLT) --Feeela 16:22, 13. Okt. 2011 (CEST)

Anrede

Wie wäre mit einer einheitlichen Anrede für alle Unterbücher? XHTML benutzt durchgängig die Sie-Form, PHP die Du-Form!? Ich bin ja für die durchgehende Benutzung des "Du". --Feeela 04:07, 14. Okt. 2011 (CEST)

Das ist eine Frage der Projektdefinition für die ganze Reihe, die es aber nicht gibt. Auf Diskussion:Websiteentwicklung werden solche allgemeine Fragen besprochen. Auf Ich brauche Hilfe gab es ein Fazit von Meinungsäußerungen: Normale Fachbücher immer "Sie"... Duzen nur dann, wenn die Zielgruppe üblicherweise geduzt wird. -- Jürgen 08:48, 14. Okt. 2011 (CEST)