Jeffrey Veen: Zwei Bücher und ein Interview
Index
1/ Buch: "Hotwired Style - Principles For Building Smart Web Site"
2/ Buch: "The Art & Science of Web Design"
3/ Interview
Rohfassung des mit der SCREEN geführten Originalinterviews
"Hotwired Style - Principles For Building Smart Web Site"
Jeffrey Veen war bis 1998 oder 1999 "Interface Director" für die Websites von WIRED Digital: HotWired, HotBot, Webmonkey. Inzwischen tourt er als Kolumnist, Redner und Berater in der Webwelt herum.
Das Buch "Hotwired Style" ist 1997 erschienen und daher eine Zeitreise zurück in die Anfänge des Webdesigns, zu einem Zeitpunkt als WIRED in voller Blüte war und AOL seine ersten Schritte in Europa machte. 1997 fingen Flash und Shockwave gerade erst an einen akzeptablen Marktanteil zu erringen, Netscape veröffentlichte Navigator 3, Microsoft zog mit dem Explorer 3 nach. Die Helden des Webdesigns hießen noch David Siegel und Lynda Wein man. FOCUS (ja, der Markwort-FOCUS!) veröffentlichte Webdesign-Bücher und Deutschland war noch Fußball-Europameister.
Dieses Buch ist mit seinen 161 Seiten schnell durchgelesen, in meinen Fall an einem Nachmittag. Das geht ein bißchen schnell für ein 60 DM teures Buch (Jeffrey Veen, "Hotwired style: principles for building smart Web sites", Wired Books, Inc., 1997, 32$95).
Der eigentliche Wert des Buches liegt nicht in einigen eingestreuten Tips die heutzutage ziemlich banal sind (Hört, hört: Tabellen als Layouthilfe!). Das Buch führt "unbeleckte" Screen-Designer die z.B. aus dem CD-ROM-Bereich kommen, in die "Denke" des Web eines, und fällt dabei immer wieder Aussagen die immer noch, oder schon wieder von verblüffender Aktualität sind: Trennung von Style und Content, die mangelnde Kontrolle über das "Aussehen" nicht als Machtverlust des Designers auffassen, sondern die sich bietende Chance zur Interaktivität und Flexibilität wahrnehmen. So bietet sich das Buch als Fundgrube an, um Screendesigner zu "bekehren" und den richtigen Pfad gen Web-Publishing zu weisen.
Das Buch ist dort sehr interessant wo Veen Einblicke in den Wandlungsprozeß von HotWired gibt. HotWired war zu Beginn, 1994, eines der ersten Projekte die versuchten nicht nur Content in Form von Textwüsten abzuliefern, sondern auch eine "WIRED-gemäße" Verpackung zu liefern. Man hatte diesbezüglich keinerlei Vorkenntnisse, und man machte das, was inzwischen auch mein bevorzugter Weg des Webdesigns ist: anstatt monatelang über ein Design zu grübeln, zu verwerfen, neu zu entwickeln und anschließend es von den Bedenkenträgern in der Agentur oder beim Kunden totquatschen zu lassen: Einfach machen. Learning-by-doing. Einfach den Stein ins Wasser werfen und gucken was passiert. Und auf die Wellen reagieren und die Site korrigieren, verfeinern.
Die allererste Version von HotWired war streng hierachisch gegliedert, und hatte als Homepage eine Grafik mit fünf Icons. Diese "Grafiklastigkeit", die auch eine Konsequenz aus den unzureichenden Gestaltungsmitteln von HTML2.0 war,sorgte für Aufsehen. Allerdings besaß diese erste Version das Problem daß der User nicht wußte was für ein Content sich hinter den Sektionen verbarg.
Also entwickelte man die zweite Generation von HotWired im Hinblick auf mehr Funktionalität. Man baute Teaser ein und fügte eine Art Inhaltsverzeichnis ein.
In der dritten Version von HotWired kamen zwei wichtige Punkte hinzu. Die Text-Teaser wurden durch interessante Grafik-Teaser ersetzt. Weitaus wichtiger: Um den Werbekunden genauere Daten über das Zielpublikum zu geben, wurde der volle Inhalt nur "Mitgliedern" zur Verfügung gestellt. Man mußte sich, kostenlos, anmelden um in HotWired einzutreten. Beim Anmeldungsprozeß mußte man die üblichen Daten eingeben: Wohnort, Gehalt, Beruf, Alter usw., usf...
Der fünfphasige "Verfeinerungsprozeß" ist der rote Faden der das Buch zusammenhält. Es sehr interessant zu sehen wie Ideen anderer Websites in die Gestaltung von HotWired eingeflossen sind. Diese Ideen sind noch heute aktuell und lassen mich z.B. meine Website bezüglich einige Dinge hinterfragen. Und damit erfüllt das Buch das Kriterium "Nützlichkeit" und braucht sich nicht mehr an der kurzen Lesezeit messen zu lassen.
Darüber hinaus bescherte das Buch mir permanente Flashbacks an die "gute alte Zeit". Ich habe mich richtig alt gefühlt. Beim Anblick der Screenshots wurde mir bewußt das ich vom ersten Augenblick von HotWired dabei war. Und leider wurde mir auch bewußt wie verkommen inzwischen eine ganze Reihe von ehemals guten Sites ist, weil sie aus Kostengründen nicht mehr mit neuen Inhalten "gefüttert" werden: WebMonkey, Adobe.com, Builder.com
Jeffrey Veen: "The Art & Science of Web Design"
Über die Person von Jeffrey Veen habe ich ja bereits weiter oben, anläßlich des alten "HotWired Style"-Buches geschrieben. Im Jahr 2001 ist mit "The Art & Science of Web Design" sozusagen die Erweiterung des "HotWired"-Buches geschrieben worden.
Sehr vieles was in dem Buch vorkam, wird von Veen wieder aufgegriffen. Genauso wie Veen im Laufe der Zeit "gereift" ist, bekommen auch die einzelnen Themen eine tiefere Abhandlung.
Das große Thema des Buches ist "Interdisziplinäres Denken" oder auch "Ganzheitlichkeit". Veen hat im Laufe der drei Jahre die zwischen den Büchern liegen, deutlich mehr theoretisches Fachwissen im Bereich der Usability oder auch des Projekthandlings bekommen. Die letzten Einzelteile die im HotWired-Buch noch lose nebeneinanderliegen, werden durch sein neues Wissen nun auch noch zusammengeklebt.
Veens Philosophie die bereits in Grundzügen in den HotWired-Zeiten zu erkennen gewesen ist, hat er in dem vorliegenden Buch zuende formuliert und rund gemacht.
Eine optimal Site entsteht wenn das Projektteam Hand-in-Hand miteinander arbeitet, und nicht der Screendesigner neben dem Coder aneinander vorbeiarbeitet. Dabei geht es um mehr als nur das Abstimmen von Terminen. Wenn ein Designer ohne ein Grundwissen an HTML und Grundverständnis an Web eine Navigation bastelt, wird es nicht lange dauern bis der Coder ankommt und das Screendesign dem Designer vor die Füße wirft, weil eine Umsetzung jeden Kosten- und Zeitrahmen sprengen würde. Der Kunde wiederum würde sich an eine schlechte Navigation und schlechte Besucherzahlen stoßen.
Veen teilt eine Website in drei Komponenten auf: Code und die Interaktivität ("Behaviors") - Wörter und die Strukturen - Bilder und die Repräsentation.
Intimate collaboration between developers, designers, editors, architects, production gurus, marketing managers, the sales team and everyone else who touches the Web site.
Right, I know, not likely. But if you use this model of structure, presentation and behavior as a foundation for how we build our teams and manage the development process, then at least you have a head start.
Web teams are inherently interdisciplanary. Web designers may be domain experts on theri corner of our triangle, but the more they can branch out -- the more they cann approach the behaviors and structural needs of a design -- the easier success will be. This communication, and ultimately translation between disciplines, is critical.
Wir sind im ungefähr 5-6ten Jahr nach der Explosion des Webs und entsprechender Explosion von Internet-Agenturen. Es ist erstaunlich wiewenig sich dieser Ansatz bislang durchgesetzt hat.
Veen nimmt sein Dreieck-Modell (Code - Wörter - Bilder) als roten Faden für sein Buch auf, ohne allerdings das es die Struktur des Buches bestimmt. Das Buch scheint zwar streng gegliedert zu sein, aber immer wieder greift er das Interdisziplinäre auf. Und so sind selbst die Kapitel in denen er über die Object-orientiertes Publishing spricht, derart abstrakt und praxisnah zugleich, daß selbst ein Screendesigner der sich bislang nicht über Photoshop hinaus traute, versteht was dahinter steckt.
Das Buch kann daher getrost den Anfängern empfohlen werden. Hier werden sie über nichts stolpern was zu schwierig ist. Aber das Buch sei auch aufs allerwärmste den Profis ans Herz gelegt. Denn Veen bringt viele neue Perspektiven ins Spiel die "mind-opening" sind.
Das Ganze geschieht in einer typischen US-Schreibe, sehr angenehm, nicht zu ernst, aber auch nicht bemüht witzig.
Als ich dieses Buch in der Badewanne angefangen habe zu lesen, hat es gerademal 2 Minuten gedauert, bis ich aufrecht in der Badewanne saß und im Vorwort immer zustimmend "Yeah" geschrieben habe. Das ist die Sorte Buch die einem bis in die äußerste Haarspitze motiviert. Deshalb meine ausdrückliche Empfehlung.
The Art & Science of Web Design von Jeffrey Veen, erschienen 2001 bei New Riders, ISBN 0-7897-2370-0. Preis: 45US$, in Deutschland mir schon für fast 90 DM übern Weg gelaufen.
Interview mit Jeffrey Veen
Abschließend, sozusagen als Goodie, in voller Länge die Originalversion eines E-Mail-Interviews welches Jeffrey Veen im April der SCREEN gegeben hat. Fragesteller für die SCREEN war Stefan Kowalczyk. Wer die Frage Nr. 2 vermißt: Veen hat sie wohl ausgelassen, weil er sie mit den anderen Fragen schon beantwortet hat.
1. One main statement of our book "The Art and Science of Web Design" is that collaboration in teams is the key to a successful web site. Do you think the collaboration in web-production could be improved in most of the web-companies today?
I firmly believe team collaboration is one of the driving factors of a successful Web site. And from what I've seen, most companies, web-based or not, struggle with this. Project management is hard work. You need to get a group of people to agree to a common vision as well as a shared methodology for reaching it. And by definition, these team members have radically different skills, with unique jargon and work styles. But without the delicate balance of design, technology, editorial, marketing, and business goals, you can't hope to create a product that will satisfy your audience. Of course, there is a lot more to a successful product than just a well-balanced team. But it's certainly the right place to start.
3. Could you give us examples, where collaboration in a project often fails?
I've worked with a lot of Web designers that feel the technology of the Web is too limiting. The constraint of today's browsers -- and HTML in particular -- is often something that will frustrate a talented visual designer. Many of them will simply avoid it. Instead, they'll build Web interfaces using a tool like Photoshop, which allows quick visualization of a page. That's fine, of course. But many stop there. They then send that picture of a Web page off to a more technical team member to "translate" it into HTML. Suddenly, we've lost collaboration and iteration, and are using a linear process. I prefer all team members work on all aspects of the product at all times. It takes a lot more management and communication, but makes for products that are based in the true reality of the technical limitations Web.
4. Are there any common strategies for building successful production teams?
I look for team members that understand the multidisciplinary nature of the Web. For example, a good designer will be a master of her craft: color theory, visual hierarchy, typography, and all the other aspects of graphic design. But a really good Web designer will go beyond that. They'll understand the capabilities and limitations of all the pieces of the Web. They'll learn how client-side scripting works, or they'll experiment with database-driven template systems. I don't expect them to be writing production-quality code, but I do hope they at least know how these systems work and what they're able to do with them. Same goes for the other team members. Some of the best engineers I've worked with understood why design was important, and why we needed to spend the extra time getting an interface perfect before we could consider it finished.
5. What would you recommend to enable good communication in a production team?
I like physical proximity in my teams. As much as the Internet allows geographic diversity, I still find it more efficient to have the whole team in one room, working together, able to make eye contact. I don't even like offices or cubicles. I prefer the open studio office -- no walls, shared space, lots of communication.
I'm also a fan of what I call progressive documentation. There has been an explosion of something called Web logs -- Web sites that track a specific topic in a daily, chronological fashion. Look at www.peterme.com or stating.theobvious.com for good examples. I ask my team members to keep similar sites. Each team member has a page with a Web log where they keep track of what they're working on, as well as other relevant resources. We use the tool "Blogger" (www.blogger.com) to do this almost effortlessly. It gives the team a sense of accomplishment and connection to everyone else.
6. Do you think the modern production tools -- for example editors for web graphics, HTML or backend programming -- offer good features for collaboration in teams?
Some do. Macromedia's Dreamweaver, for example, has good site tools for checking files in and out. But many non-technical people are still uncomfortable with them. Engineers have been working with version control systems for decades, but most designers and editors aren't used to that level of complexity. I think we've got a long way to go before technology can replace the kind of face to face collaboration I was just talking about.
7. Today most websites are database-driven applications. Has team collaboration become easier with this or is it even more complex today?
It really is more complex today. With template systems, a designer can never see exactly what their interface will look like in all instances. Everything is so intangible now. Pages are made up of dozens of distributed pieces of code, all abstracted from the final product. And the tools really haven't kept up. A few years ago, if you saw a page with an error on it, you could open that page up in a text editor, fix the error, and save it back to the server. Now, we've got million dollar content management systems that are so complex you need to hire professional services consultants just to change your interface. I think tools have a long way to go before collaboration gets any easier, unfortunately.
Weitere Buchrezensionen zum Thema:
Steve Krug "Don't make me think"
Steve Krug "Don't make me think"
