nicht angemeldet
Moin, Mathias!
Uff, eine lange Antwort. Ich will mich mal kurzfassen und deine Fragen herausfiltern...
Dieses Zusammenspiel zwischen Grafikdesign und Hypertextgestaltung interessiert mich sehr, vor allem auch weil ich eine gewisse Unvereinbarkeit zu sehen glaube (AFAIR hattest du schon früher einmal davon erzählt, als du eure Seite vorgestellt hast) - ich denke nicht, dass sich beide Arbeitsbereiche beziehungsweise -phasen trennen lassen, sodass eine Person - ein spezialisierter Experte, oder schlichtweg "Fachidiot" ;) - ohne Verständnis von Hypertext und den Möglichkeiten der tatsächlichen Realisation für den grafischen Teil zuständig ist und eine andere, welche ihrerseits die Überlegungen des für die Grafik zuständigen Menschens nicht nachvollziehen kann, für die Hypertextumsetzung verantwortlich ist.
Du triffst den entscheidenden Punkt: Eine designte Grafik der Webseite entsteht meist so, dass ein Screenshot eines Browserfensters der bekannten Seite "about:blank", wahlweise auf 800x600 oder 1024*768 gemacht, ausgemalt wird. Das ganz große Problem dabei ist natürlich, dass diese Grafik a) nicht scrollt, b) sich nicht dynamisch an die Fenstergröße anpaßt, c) Blindtext enthält, dessen Aussehen dem realen Content meist nicht ähnelt, d) Menüpunkte mit fabelhaft kurzen Stichwörtern enthält, die in der Realität viel länger werden, e) keine Mouseover-Effekte und kein DHTML besitzt - kurzum: Der grafische Entwurf ist so ziemlich die ungeeigneste Art, eine Webseite zu erstellen. Dennoch funktioniert dieser Arbeitsstil eigentlich ganz gut, denn als Vorlage für die HTML-Umsetzung kann ich diesen Entwurf meinerseits in Photoshop öffnen und nach meinen Bedürfnissen in Einzelteile zerschneiden, wobei ich das wenigste wirklich benötige - 90% der Umsetzung erledige ich mit CSS, nur dort, wo Logos, Icons oder andere Schriften zwingend auftauchen müssen, muss ich Grafiken verwenden.
Und schon beim Entstehen des grafischen Entwurfs kann ich eigentlich ganz gut abschätzen, ob sich die Vorlage gut oder weniger gut in CSS realisieren läßt. Bislang hat es jedenfalls immer geklappt. Zugegeben sitzt man da einige Tage dran, bis nicht nur die einfachen, pflegeleichten Browser wie Opera kapiert haben, was man will, sondern auch Mozilla (eine Stufe schwerer), IE (eine (6.0) bis drei (5.0) Stufen schwerer) und Netscape 4 (vier Stufen schwerer).
Während der Grafikmensch möglicherweise auf die Beachtung eines Corporate Designs aus ist und in Kategorien von Farben und Formen und deren Zusammenspiel denkt und typische Werkzeuge für die Gestaltung von Pixelgrafiken benutzt, ist es die Aufgabe des Hypertextautors, mit Markupelementen zu jonglieren, die Texte/Inhalte zu "abstrahieren" und zu strukturieren (*Hyper*text), er denkt vermutlich in Kategorien von Seitenelementen ("Kopf mit Titel/Überschrift/Logo", "Primär-/Sekundärnavigation", "Fuß mit Hyperlinks zu Metainformationen" usw.), die ihre Entsprechnung im Markup und später im CSS-Boxmodell finden.
Genau. Aber das würde ich als Vorteil für die Seitengestaltung nehmen. Ich denke viel zu sehr in CSS-Boxen. Die Grafikerin nicht, die sieht das Gesamtbild und sorgt hoffentlich dafür, dass das Erscheinungsbild der Seite "aus einem Guß" ist. Seit der Entdeckung von CSS gibt es ziemlich viele Seiten von HTML+CSS-Gurus, die zwar ganz nett aussehen, aber doch eine gewisse CSS-Sterilität ausstrahlen, weil es ihnen zugunsten der totalen CSSilität an jeglicher Grafik mangelt - womöglich werden etliche CSS-Effekte nur vom Mozilla 1.3alpha realisiert ;). Der Grund liegt schlicht darin, dass die Ersteller zwar ganz prima mit HTML und CSS umgehen können und diese Techniken auch auszureizen verstehen, aber nicht unbedingt gestalterische Fähigkeiten haben. Deshalb bin ich eigentlich ganz froh, dass die Grafikerin nur eingeschränkte Kenntnisse von CSS hat und sich lediglich bei mir rückversichert, dass ich ihre Ideen auch hinkriege.
Kurz gesagt: wie geht die teaminterne Kommunikation von statten und wie lassen sich diese grundverschiedenen Arbeitsbereiche vereinbaren, dass am Ende ein Produkt entsteht, welchen allen Belangen gerecht wird - denn zuoft ist der lineare Arbeitsverlauf (Kunde spricht mit A, A gibt weiter an B, B gibt weiter an C, C schließt das Projekt ab) nicht möglich, alleine schon weil der Kunde oft keine Ahnung davon hat, wie und ob eine Idee realisierbar ist, dieses Phänomen lässt sich an jedem Glied der Kette feststellen... "ein Teufelskreis". ;)
Kommunikation ist das Zauberwort. :) Wenn Kunde mit A gesprochen hat, spricht A regelmäßig mit B und C über den Stand der Dinge - wobei B und C ja nur für einen kleinen Teilbereich des Projektes zuständig sind: Die optische Erscheinung der Site. Daneben gibts natürlich noch den Inhalt zu regeln, mit dem die beiden nicht so viel zu tun haben - das wäre dann eher Sache für D (den Backend-Programmierer, sofern er nicht mit C eine Personalunion eingeht).
Ich denke immer in Kategorien der Benutzerführung beziehungsweise -interaktion, der Strukturierung von Inhalten, der Hierarchisierung von Dokumenten, kurz gesagt - ich schreibe Hypertext und mein gedanklicher Horizont umfasst alle davon ausgehenden Bereiche. Erst daraus entsteht die Notwendigkeit (!) der visuellen Gestaltung, dies bedingt ein konsistentes, authentisches Grafikdesign.
Man kann eben von zwei verschiedenen Seiten am Tunnel bohren - gerne auch von beiden gleichzeitig. Ich gebe gern zu, dass wir mehr auf der Seite der "grafische Seite ohne Inhalt"-Strecke fahren (jedenfalls besteht die Gefahr dazu) - deshalb ist es die nicht leichte Aufgabe des Kundenberaters, zusammen mit dem Kunden auszuloten, was denn an inhaltlichen Sachen auf die Site soll. Und ich darf dir versichern: Es ist bei Firmenhomepages verdammt schwer, aus dem üblichen "Wir über uns - Produkte - Kontakt"-Einheitsbrei auszubrechen. Vor allem, wenn der Kunde selbst so recht nichts bieten kann, was ihm im Netz eine gewisse Einmaligkeit für die Site oder einen Nutzen für seine Besucher beschert. Been there, done that, have the t-shirt.
Ich nehme an, bei euch gibt es eine Art "Projektabschluss"? Aus diesem Grund werden große Firmen beziehungsweise Institutionen eher keine freien Agenturen konsultieren, sondern fest angestellte Mitarbeiter beschäftigen, welche unaufhörlich an der Seite weiterarbeiten und in direktem Kontakt mit der Redaktion stehen.
Teils, teils. Wenn ein CMS zur Verfügung steht und der Kunde es will, werden seine Mitarbeiter dafür geschult und erledigen Arbeiten an der Site selbst. Macht ja auch durchaus Sinn, dafür kurze Wege innerhalb des Unternehmens zu haben, ohne ständig die Agentur anrufen zu müssen. Allerdings gibt es natürlich auch Bereiche, die ein auf ein CMS geschulter Mitarbeiter nicht erledigen kann. Wenn zu erwarten ist, dass komplexere Wartungsarbeiten anfallen, oder auch einfach nur Admin-Tätigkeiten zu erledigen sind, dann wird in der Regel ein Rahmenvertrag abgeschlossen und die Tätigkeiten werden nach Aufwand abgerechnet.
Ehrlich gesagt: Würde ich den Kunden die Herrschaft über den HTML-Code überlassen, wäre die Site nach kurzer Zeit kaputtgespielt. Natürlich hat der Kunde defacto die Herrschaft darüber - er hat die Zugänge zum Server ja ebenfalls bzw. könnte sie sich beim Provider besorgen.
Ich hab's nur bei einem Projekt erlebt, was wir abgeschlossen hatten und der Kunde dann (ohne unser Wissen) offenbar jemand anderes mit der Pflege und Änderung der Site beauftragt hatte.
Erste Aktion dieses jemandes: Er tauschte auf der Startseite eine Kollage, für deren Bildrechte der Kunde einen vierstelligen Eurobetrag bezahlt hatte, gegen eine Eigenkreation aus, die auf eine Gewinnspielseite linkte. Die zuständige Person des Kunden wußte davon nichts und war etwas ungehalten, als wir darauf hinwiesen...
Dieser jemand steigt leider auch durch mein HTML und CSS nicht ganz durchgestiegen. Zwar sieht die Seite jetzt auf dem Bildschirm noch immer ganz gut aus, aber die Druckansicht ist jetzt total daneben, weil für neu hinzugefügte Elemente auf einzelnen Seiten keine Definition für den Ausdruck angegeben ist - die Elemente (meist Bilder) stehen mitten über dem Text. Auch das Seitenblättern (hatte ich recht elegant gelöst, indem auf einer Seite einfach zwei Layer definiert sind - einer versteckt, einer sichtbar: Geblättert wird entweder mit Javascript oder mit PHP, indem ein Seitenparameter ein dynamisches CSS einbindet, was den anderen Layer zeigt) wurde nicht verstanden - jetzt gibts zwei getrennte Seiten. Hätte ja nur Vorteile beim Ausdrucken gebracht...
Habt ihr Kunden, die explizit Barrierefreiheit wünschen oder bietet ihr es als spezielles, aber selbstverständliches, standardmäßig inbegriffenes Feature an und die Kunden nehmen es zwar hin, aber verstehen nicht wirklich die Notwendigkeit...?
_Ich_ wünsche Barrierefreiheit - sie entsteht bei meiner Seitenerstellung automatisch mit (jedenfalls weitgehend) und kostet nichts extra, deshalb wird sie eingebaut. Und da wir uns gerade an der Ausschreibung einer öffentlichen Institution beteiligen, würde es dort ganz sicher auch zwingend erforderlich sein, barrierefrei zu arbeiten. Und diese Barrierefreiheit werde ich ganz sicherlich nicht durch eine "Nur-Text"-Version realisieren, sondern durch heftigsten Einsatz von CSS und nur mit ganz wenigen <img>-Bildern (der Rest wird, wenn es denn wirklich notwendig ist, per background-image eingebunden).
- Sven Rautenberg