nicht angemeldet
Hallo, Sven.
Sobald klar ist, welcher Content auf der Seite ungefähr angeboten werden soll, geht es an die Seitengestaltung. Die Grafikerin (das bin auch wieder nicht ich ;) ) kriegt ein Briefing, in dem deine Äußerungen, wie die Webseite denn sein soll, welche Kundengruppen du ansprechen willst, wie dein Unternehmen erscheinen soll etc., wieder auftauchen, und setzt diese Beschreibung in einen grafischen Entwurf um.
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. 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. Überhaupt liegt die Usability eigentlich im Kompetenzbereich des Hypertextautors, davon kann der Grafikmensch keine Kenntnis haben, höchstens der Kundenberater (?), indem er mit dem Kunden eine benutzbare Inhaltsstruktur entwirft, welche vor vornherein auf den Seitenbenutzer ausgerichtet ist - hier spielt der Aspekt der "Zielgruppenanalyse" eine Rolle: was sucht der Benutzer und wie wird es ihm "ergonomisch" dargeboten. Denn im Endeffekt muss der Grafikentwurf in ein Hypertextdokument umgewandelt werden, was beispielsweise bedeutet, dass das Layout, welches vorher nur als Pixelgrafik ohne Dokument- und Textstruktur existierte, *skalierbar* mit HTML/CSS gelöst werden muss. Grafikeffekte müssen mit in den Hypertext eingebundenen Objekten realisiert werden, es muss eine Übereinkunft getroffen werden, ob und in wie weit Positionierung beziehungsweise der Bezug der Layoutelemente zueinander überhaupt mit Hypertext realisierbar ist. Die Erstellung von interaktiv-visuellen Effekten ("DHTML", :hover, :focus usw.) fällt IMHO eher in den Zuständigkeitsbereich des Grafikmenschen, dieser wiederum *muss* in JavaScript- bzw. CSS-Kategorien denken, zudem müsste er sich sogar mit den Misslichkeiten der verschiedenen Browser herumquälen, denn ohne Blick auf die Implementierung beziehungsweise Realisation ist jede Vorarbeit sinnlos. Für gewöhnlich geht dieser notwendige Schritt der Übereinkunft kurz und schmerzvoll von statten, Grafiken werden einfach zerhackt und Bereiche mit Hyperlinks versehen, dazwischen gibt es noch ab und zu ein Brocken Text - Grafik-/Printdesign meets World Wide Web, das Ergebnis ist uns allzu gut bekannt.
Der Backendprogrammierer sieht wiederum den Hypertext als Interface für Benutzereingaben und Programmausgaben, er denkt - wenn überhaupt - nur an Formularen und Tabellen und den Möglichkeiten, dynamisch Inhalte zu verwalten und sie mit Hilfe von Templates in ein grafisches Frontend zu überführen - ein Frontend, von dessen innerer Architektur keine Ahnung haben muss beziehungsweise kann, da es ein Produkt von anderen Spezialisten ist.
Ich nehme genauso an, dass der Projektmanager beziehungsweise Kundenberater in ähnlichen völlig unterschiedlichen Kategorien denkt, womöglich in Kategorien der Werbetechnik, der Vermittlung eines Images, dem Ansprechen der Zielgruppe (ich kenne die tatsächlichen Aufgaben nicht, es ist eine Mutmaßung, es soll auch nur als Beispiel dienen).
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". ;)
Oder auch in zwei oder drei - je nachdem, wieviel Geld du rausrücken willst. Diese grafischen Entwürfe werden dir dann vorgelegt, damit du auswählen kannst. Eventuell komme auch ich ins Spiel, und setze den einen oder anderen Entwurf in HTML, CSS und Javascript um, um einen Klick-Dummy herzustellen.
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. Ich kann im Gegensatz dazu nicht verstehen, wieso jeder des Teams seine eigenen für wichtig empfundenen Schwerpunkte einbaut, nach dem Motto: Erst kommt der für foo zuständige Typ, dann der Experte für bar, dann der Spezialist für baz...
Wenn du dich für einen Entwurf entschieden hast (ggf. noch mit ein paar Änderungswünschen), dann komme ich vollends ins Spiel und erstelle die Site.
In Anbetracht der oben genannten Überlegungen hast du anscheinend das schwerste Los... *fg*
Dabei sind die Sonderfunktionalitäten wie Newsletter, Kontaktformular, Content Management System, Datenbankeinbindungen etc. zu berücksichtigen und zu programmieren.
Nun gut, aber das alles sind *Lösungen*, aber welche Instanz definiert die *Aufgaben* beziehungsweise *Probleme*? (Für den Kunden ist beispielsweise der Newsletter nur ein Mittel zum Zweck.) Unter anderem vielleicht eine Art "Marketingberater"?
Natürlich auch die schon aus dem Klick-Dummy bekannte Site-Navigation (der Klick-Dummy wird Grundlage der weiteren Seitenentwicklung).
"Wer bei euch hat Nielsen gelesen?" - Das soll heißen, wer ist fachkundig, über die sinnvolle Verteilung der Inhalte und darüberhinaus über die Seitennavigation zu entscheiden? Der Grafikmensch...? Ein "Klick-Dummy" sollte IMHO schon den "Geist der Benutzbarkeit atmen", weil er in seiner Nichtigkeit und Inhaltsleere bereits über die komplette Inhalts- und Navigationsstruktur verfügbar und als "Baustein" oder "Fundament" für die Seite fungiert; von dieser "Idee" hängt folglich der Erfolg des gesamten Projekts ab.
Auch der Inhalt wird auf Wunsch von uns (teilweise) erstellt, wenn du selbst nicht alle Informationen liefern kannst oder willst.
Ach, daher kommen die vielen Seiten mit viel Content, aber wenig Inhalt... ;) SCNR.
Im Prinzip erhälst du ein Rundum-Sorglos-Paket und am Ende eine schöne Site auf deinen Webspace oder Server hochgeladen. Wir kümmern uns auch hinterher gerne um die Site, um Änderungen durchzuführen (kostet natürlich dann extra).
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.
Dein Kumpel wird dieses umfangreiche Programm vermutlich nicht bieten können. Entweder ist er ein guter Berater, oder ein guter Grafiker, oder ein guter Programmierer - selten alles drei zusammen. Schon allein deshalb wird sein Arbeitsergebnis nicht so hochwertig sein, wie unseres (mal ganz davon abgesehen, dass dein Kumpel vermutlich noch nicht unbedingt viel Erfahrung mit Seitenschreiben für _alle_ Browserversionen, barrierefreier Seitengestaltung etc. hat). Und deshalb sind wir teurer. :)
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...?
Mathias