Welche Homepagebaukästen sind wirklich gut?

Internet
#21

Tach,

DW schrott ist , kein WYSIWYG kann HTML , das sind alles
Layoutsysteme die TAGS benutzen wie es gerade optisch passt.

Schön, daß man Unwissenheit mit so wenigen Worten so bunt
darlegen kann.

Das heißt, DW ist doch nicht so schlecht?
Von meiner Seite war das eine ernstgemeinte Frage.

Ich finde den DW nicht so schlecht, wie er gerne dargestellt wird. Ich würde zwar nbicht unbedingt eine ganze Site damit bauen (die Gründe sind vielfältig) aber gerade als Entwurfstool für das Grundlayout finde ich ihn ungemein praktisch. Damit meine ich natürlich nicht, die Idee erst am Rechner zu finden, sondern ein vorhandenes Layout umzusetzen.
Vorraussetzung ist natürlich immer, daß ich mit einem geteilten Fenster für Ansicht und Codeview arbeite und - sollte einmal etwas unerwartetes passieren - so schnell eingreifen kann.

DW macht übrigens auch keinen Spaghetti-Code oder DIV-Suppe, es sein denn, Du bist hungrig und bestellst das. Ist eben kein Baukasten.

Lad Dir einfach Mal die Trial runter und teste. Möglicher Weise kannst Du den ja sinnvoll in Deinen Workflow integrieren. UNd wenn nicht, so hast Du immerhin eine Vorstellung.

Allerdings muss ich sagen, daß ich den Preis für die einzelne Lizenz (ohne irgendeine Suite) für ziemlich, ähämmm, ambitioniert halte.

Ohne Akamai Downloader gibts die Trial hier (sollte ohne Adobe ID funktionieren):
Dreamweaver CS 5 (v11)
http://prodesigntools.com/trials2/AdobeProducts/DRWV…
Dreamweaver CS 5.5 (v11.5)
http://prodesigntools.com/trials2/AdobeProducts/DRWV…

Gruß

osmodius

#22

Moin,

Lad Dir einfach Mal die Trial runter und teste. Möglicher
Weise kannst Du den ja sinnvoll in Deinen Workflow
integrieren. UNd wenn nicht, so hast Du immerhin eine
Vorstellung.

Okay, das mache ich vermutlich mal. Vielen Dank für die Links.

Schönes Wochenende,
-Efchen

#23

Moin,

Und für diesen ersten Schritt des Einrichtens
sind Kenntnisse in HTML, CSS und dem entsprechenden CMS
unabdingbar.

Und wie stehts mit der Semantik für den Redakteur? Erlauben
die gängigen CMS dem Texteschreiber denn auch das Festlegen
der Semantik? Wo das CMS dann die richtigen Tags einsetzt?
Denn das kann der Layouter ja vorher nicht festlegen, sondern
das muss der Texter machen.

Ich kann natürlich nicht für alle CMS sprechen, nichteinmal für viele, daher zuerst etwas grundsätzliches:
Viele CMS (z.B. Joomla!, Wordpress) vermengen in ihren Templates PHP mit HTML. Kann man machen, verkompliziert das Templating in meinen Augen allerdgings und führt schnell zu abenteurlichem Code. Ich schätze da eher die Trennung bei TYPO3.
Ich gehe daher von einem soliden HTML-Grundgerüst mit (exemplarisch) Header, 3 Spalten (navigation, Content, irgendwas) und Footer aus. In diese steckst Du Marker über die das CMS die Bereiche mit Inhalt füllt.

Wenn Du also eine Seite in der Hierarchieebene 1 erstellst, so wird sie automatisch in die Navigation aufgenommen und da als li-Element in einer ul eingebunden - wenn der Admin/Designer das so vorgesehen hat.

Die Seite verlangt einen Seitentitel, der für die Navigation genutzt wird. Die Seiten selber füllst Du mit Inhaltselementen, welche wiederum ihre eigenen Vorgaben haben. Für ein reines Textelement kannst Du vorgeben, daß eine Überschrift Pflicht ist und als h1 ausgezeichnet wird. Im Text (verpackt als Paragraph) sind meinetwegen nur 2 Arten Überschridt erlaubt, verpackt als h2 und h3. Bei einem Absatz im Test wird p geschlossen und ein neues geöffnet, Margin 10em.

Letztlich tippt der Redakteur seinen Text wie mit einer vernüftigen Word-Vorlage und das Ergebnis sieht nicht nur den Vorgaben entsprechend aus, auch der Code entspricht den Vorgaben.

Bei anderen Inhaltselementtypen funktioniert das analog.
Durch die Trennung von Inhalt und Gestaltung verhinderst Du effektiv, daß der Nutzer bold-Tags verwendet und bringst automatisch das entsprechende CSS. Letztlich stellst Du nur die gewünschten Funktionen bereit. Das macht zwar beim einrichten Arbeit, führt dafür allerdings zu ansehnlichen Ergebnissen.

Ist eine ernst gemeinte Frage, weil ich mich nie besonders mit
CMS befasst habe (also mit Systemen nicht, der Theorie aber
sehr wohl).

Na, immerhin gehörst Du hier nicht zu den Leuten, die denen ein CMS empfehlen, die keine Lust haben sich in die Materie einzuarbeiten. Die empfehlen vermutlich auch jemanden, der nicht Fahrrad fahren kann als Lösung ein Motorrad. :wink:
CMS-Seiten bei denen das Standard-Blau in Grün geändert wurde gibts schon zu genüge. Und in allen Templates sind die gleichen Fehler…

Gruß

osmodius

#24

Moin,

Lad Dir einfach Mal die Trial runter und teste. Möglicher
Weise kannst Du den ja sinnvoll in Deinen Workflow
integrieren. UNd wenn nicht, so hast Du immerhin eine
Vorstellung.

Okay, das mache ich vermutlich mal. Vielen Dank für die Links.

Na, dann bist Du das WE ja runter von der Straße. :wink:

Schönes Wochenende,

Ebenso,

osmodius

#25

Hallo,

Und wie stehst mit der Semantik für den Redakteur? Erlauben
die gängigen CMS dem Texteschreiber denn auch das Festlegen
der Semantik? Wo das CMS dann die richtigen Tags einsetzt?
Denn das kann der Layouter ja vorher nicht festlegen, sondern
das muss der Texter machen.

Ja klar. Der Texteschreiber darf „Formate“ auswählen, so wie h1, h2, h3, bold etc., und das CMS legt mit dem hinterlegten CSS die Formatierung fest.

Das ist meine Erfahrung mit joomla und wordpress. Allerdings sind die Wordpress-Templates, die ich mir angesehen habe, auch das standard-Template, nicht konsequent, dehalb habe ich mir mal ein eigenes gemacht. Dann funktioniert es aber. Mein joomla-Template stammt von jemand anders, da habe ich mir die Mühe nicht gemacht.

Cheers, Felix

#26

Moin,

Ich kann natürlich nicht für alle CMS sprechen, nichteinmal
für viele

Ich fand das sehr aufschlussreich, was Du geschrieben hast, das zeigt mir, dass (gute) CMS auch wirklich das halten, was sie versprechen. Wenn man sie natürlich falsch benutzt, kommt auch der übliche, bekannte Käse dabei raus.

Na, immerhin gehörst Du hier nicht zu den Leuten, die denen
ein CMS empfehlen, die keine Lust haben sich in die Materie
einzuarbeiten.

Arbeit macht eine Website immer! Wenn jemand keine Lust hat, sich in HTML/CSS einzuarbeiten und ein Tool sucht, das ihm diese Arbeit abnimmt, dann muss er immer noch die Bedienung dieses Tools lernen, um ein anständiges Ergebnis zu erzielen. Ob das dann allerdings weniger aufwändig ist, ist halt immer die Frage. Ein CMS würde ich niemandem empfehlen, der keinen Bock hat, weil der schafft es nicht - egal wie er es angeht.

Danke und Grüße,
-Efchen

#27

Moin,

Ja klar. Der Texteschreiber darf „Formate“ auswählen, so wie
h1, h2, h3, bold etc.

Ehm, ich gehe davon aus, dass Du Dich falsch ausgedrückt hast, denn h1 bis h3 sind keine Formate und bold sollte man eigentlich auch nichts markieren können, weil es keine Semantik enthält.

Man sollte natürlich Überschriften der verschiedenen Ordnung markieren können, wobei man auch auf die Reihenfolge achten muss und man soll natürlich auch wichtige Textstellen festlegen können. Natürlich dürfen die dann auch bold sein, aber einen Inhalt nur als „bold“ markieren, macht ja eigentlich keinen Sinn. Deswegen nutzt man ja auch nicht das b-Tag.

Grüße,
-Efchen

#28

Hallo,

Ja klar. Der Texteschreiber darf „Formate“ auswählen, so wie
h1, h2, h3, bold etc.

Ehm, ich gehe davon aus, dass Du Dich falsch ausgedrückt hast,
denn h1 bis h3 sind keine Formate

Da gebe ich dir recht.

und bold sollte man
eigentlich auch nichts markieren können, weil es keine
Semantik enthält.

Da gebe ich dir nicht recht - wenn ich will, dass ein Wort fett gedruckt wird, soll mir das erlaubt sein. Dass das semantisch bedeutungslos wird, wenn alternative Browser verwendet werden, ist klar.

Deswegen nutzt man ja auch nicht das b-Tag.

Nein, das benutzt man nie :wink:

Aber nochmal - so etwas lässt sich in den mir bekannten CMS gut umsetzen. Bloß tun es die Standard-Templates eher nicht, und dann siehst du die von dir schon oft kritisierte div-Suppe.

Cheers, Felix

#29

Moin,

Da gebe ich dir nicht recht - wenn ich will, dass ein Wort
fett gedruckt wird, soll mir das erlaubt sein. Dass das
semantisch bedeutungslos wird, wenn alternative Browser
verwendet werden, ist klar.

Das Problem ist, dass Du damit zwei verschiedene Semantiken für den selben Inhalt vergibst - und das kann eigentlich gar nicht sein.

Clients, die auf die HTML-Semantik angewiesen sind, messen dem Wort dann keinerlei Bedeutung zu. Menschen aber, die visuelle Clients benutzen, sehen das Wort fett und assoziieren eine semantische Bedeutung (nämlich „wichtig“), die aber im HTML-Code nicht festgelegt ist.
Und ich denke, da musst Du mir wieder recht geben. Verschiedene semantische Bedeutungen für den selben Inhalt macht nicht wirklich Sinn, oder?

Grüße,
-Efchen