Begonnen habe ich als Designer. Irgendwann musste ich gezwungenermaßen auch entwickeln. Jetzt ist es Zeit für einen Reset.
Wir hatten ja nix
Es waren die Neunziger. Netobjects Fusion war das Designtool mit der weitesten Verbreitung, dich gefolgt von Microsofts Frontpage. Fusion war für Designer gemacht. Kontakt mit dem Quelltext der Website gab es nie, war auch gar nicht möglich. Ebenso verhielt es sich mit Frontpage. Das Ergebnis waren zwar ansehnliche Seiten, aber grauenhafter Source Code.
Später kamen Dreamweaver von Macromedia und GoLive von Adobe dazu, liefen Fusion und Frontpage sogar den Rang ab. In Sachen WYSIWYG waren die Newcomer besser, in Sachen Code-Qualität ebenso. Da war es nur logisch, dass Designer den Pionieren der Designtools keine Tränen nachweinten. Der Schaden war zu diesem Zeitpunkt allerdings bereits angerichtet.
Was hätte sein können, wenn es anders gelaufen wäre
Schreibst du Postscript mit der Hand? Nein? Warum nicht? Genau, es ist nicht erforderlich. Und das Schreiben von HTML mit der Hand wäre auch nicht erforderlich geworden, wenn die frühen Tools direkt eine ordentliche Umsetzung der Standards geliefert oder wenigstens geschafft hätten, glaubhaft zu etablieren, dass es darauf nun wirklich gar nicht ankäme. Schau dir Word und seinen Kraut-und-Rüben-Code an; funktioniert aber.
Hat uns also die mediokre Qualität früher HTML-Designtools kollektiv auf die Entwicklerschiene gezwungen? Das mag am Ende etwas übertrieben wirken. Zumindest wird die Alleinschuld nicht bei den Jungs von Netobjects oder Microsoft zu suchen sein. Tatsache ist allerdings, dass wir von Beginn an zum händischen Schreiben von Code gezwungen waren, etwas, dass Print-Design-Tools nie von uns verlangt hatten und – ich würde sogar sagen – hätten. Es waren halt Wild-West-Zeiten.
So schlugen wir uns recht früh mit unattraktiven Codeblöcken rum, statt visuell an attraktiven Designs zu werkeln. Irgendwann wurde es uns zur Normalität. Und seither beschleunigt sich das code-basierte Arbeiten geradezu dramatisch. Kein Tag vergeht ohne drei Dutzend brandneue, natürlich ganz tolle Frameworks, Boilerplates, Libraries und sonstige Tools.
Design ist nur noch ein Teilaspekt der Arbeit
Das Design ist in den Hintergrund getreten. Die Entwicklertätigkeit dominiert. Das kann man mögen, muss es aber nicht. Schaue ich mir meinen Arbeitsbereich an, dann haben sich die Anforderungen meines typischen Kunden in den letzten zwei Jahrzehnten kaum verändert. Dramatisch verändert haben sich indes die Möglichkeiten dessen, was wir alles technisch umsetzen können. Das allerdings spielt für den Durchschnittskunden kaum eine Rolle, denn dessen unternehmerische Ziele sind die exakt gleichen wie vor zwanzig/dreißig Jahren. Da kannst du ein BWL-Lehrbuch der Achtziger aufschlagen und an beliebiger Stelle lesen.
Die brandneuen Features, die du nur als Entwickler zum Einsatz bringen kannst, sind natürlich deshalb nicht unnütz. Sie betreffen allerdings nur einen relativ geringen Teil der potenziellen Kundschaft und sind hinsichtlich ihrer Visibilität, des Buzz, der um sie erzeugt wird, deutlich überrepräsentiert.
Back to the Roots
Mir reicht es jetzt. Anstatt immer wieder neue Tools zu evaluieren, um festzustellen, dass ich damit nach unnützer Einarbeitungszeit wieder das erreichen kann, was ich zuvor auch schon erreichte, werde ich jetzt gezielt aus diesem Hamsterrad aussteigen. Ich will keinen Facebook-Klon entwickeln und es wird auch kein Kunde jemals verlangen.
Mich erfreut die Arbeit an Designs, nicht das Rumfrickeln an Code. Wie oft habe ich mich schon über ein fehlendes Semikolon oder einen überflüssigen Unterstrich geärgert, wenn ich denn endlich mal fündig geworden war. Damit muss Schluss sein.
Und wo wir schon mal dabei sind. Ich will auch kein Webmaster sein. In den Neunzigern habe ich Tage an Arbeit investiert, wenn wieder der Mailserver des Kunden XYZ nicht lief oder auf irgendwelchen Blocklisten auftauchte. Heutzutage ist die Tätigkeit zwar überschaubarer und dank vernünftiger Backends auch einfacher zu erledigen. Spaß macht sie deswegen noch lange nicht.
Wenn ich also nicht webmastern und nicht entwickeln will, was ist das richtige Tool für mich? Naheliegenderweise fallen mir da direkt als erstes die Homepage-Baukästen neuer Generation vor die Füße. Dreamweaver und Co nehmen mir schließlich nicht die Arbeit des Webmasters ab, wenn sie auch schon recht weit gehen, in der Unterstützung von Cloud-Speicherplatz und der Verwaltung von Modulen und anderen wieder verwendbaren Elementen.
Hello Wix
Für Dr. Web beschäftigte ich mich schon des öfteren mit dem Thema Homepage-Baukästen, auch für t3n schrieb ich mehrfach zum Thema, inklusive der Erstellung eines großen Marktüberblicks. Ich darf wohl für mich in Anspruch nehmen, qualifizierte Entscheidungen für oder wieder bestimmte Produkte treffen zu können.
So betrachtet, blieben letztlich zwei Website-Builder in meiner engeren Auswahl, nämlich Wix und Webydo. Zu beiden findest du hier auf Dr. Web eine ganze Reihe von Beiträgen. Auch Kollege Robert Mening baute eine vollständige Website mit Wix und berichtete ausführlich darüber.
Während Webydo auf den ersten Blick das komplettere Paket, sogar inklusive Billing und White Labelling, anbietet, ist Wix das größere Unternehmen.
Warum ist das wichtig? Ich will nicht so tun, als legte ich mit der Entscheidung für ein bestimmtes System meine komplette berufliche Zukunft in dessen Hände. Aber sicherlich wäre es durchaus ärgerlich, wenn mein Dienstleister von jetzt auf gleich die Grätsche machte. Also gilt es schon, im Vorfeld, zumindest soweit möglich, zu prognostizieren, wie wahrscheinlich der Worst Case erscheint.
Da sehe ich persönlich den Marktführer Wix als sicherste Wette an. Deutsche Wettbewerber haben teils bereits turbulente Zeiten erlebt, deshalb kommt für mich da keiner in Frage. Webydo hat zwar ein gutes Produkt, steuert aber irgendwie auf eine Art Endkampf mit Wix zu. Am Ende wird einer der beiden siegen, und ich vermute, es wird Wix sein.
Vom Featureset her sind sich die beiden großen Anbieter sehr ähnlich, von der Lernkurve und der Bedienbarkeit her auch. Im Zweifel wäre sogar ein schneller Wechsel vom einen zum anderen denkbar. Diese Vorstellung bestärkt mich weiter in meinem Entschluss.
Durch die klare Fokussierung auf Wix-basierte Websites verliere ich keinen einzigen Kunden. Soviel kann ich jetzt schon sagen. Den Kunden war es immer schon egal, auf welcher technischen Grundlage ich ihre Designs zum Laufen bekomme. Und Services habe ich schon in der Vergangenheit nur zwei, drei Mal entwickelt; zuletzt vor 15 Jahren.
Psychologisch erleichtert mich die Entscheidung ebenfalls kolossal. Wenn du erst einmal erkannt hast, dass du dein Geschäft gar nicht im Cutting Edge der neuesten Technologien betreiben musst, fällt viel Ballast ab.
Natürlich werde ich mich auch weiterhin über neue Entwicklungen auf dem Laufenden halten, aber Experimente wird es nicht mehr geben. Code wird ebenfalls nicht mehr geschrieben. Ab heute wird nur noch gestaltet. Wie früher.
8 Antworten
Ich hab Pinegrow seit geraumer Zeit im Einsatz. Das ist auch nicht der Weißheit letzter Schluss hilft aber zumindestens bei der schnellen Erstellung. Das Finetuning erfolgt dann meistens per Hand. Mich würde interessieren wie Sie Ihren Entschluss in aller Konsequenz umsetzen. Eine Workflow-Beschreibung als Artikelserie wäre nett.
Nun ich finde Pinegrow eine ziemlich optimale Mischung zwischen grafischer Benutzeroberfläche und maximalem Zugriff auf den Code. Natürlich ist es nicht der Weisheit letzter Schluss aber die Basis eines jeden meiner Webprojekte. Pinegrow mit Wix oder anderen Homepage Baukästen zu vergleichen hinkt ein wenig, dafür ist es einfach zu komplex.
Schon mal Muse von Adobe getestet?
Ich schon. Vor ca. 6 Monaten.
Ein zu umständlicher Workflow für mich.
Hat immer noch etwas von Betaphase.
Zudem stellt Adobe schnell mal Produkte ein die nicht die gesteckten Umsatzziele erreichen ?
Wenn man HTML Code schreibt ist das noch lange kein “Entwickeln”, Websites mit Print vergleichen ist auch etwas seltsam. Es hat schon seinen Grund warum man sich bei Websites etwas mehr ins Zeug legen muß.
Trotzdem war ich neugierig was die Lösung für Website mit irgendeinem Wundertool sein soll!
Wix! 😉 Ernsthaft? Gut, für 0815 Sites geht Wix, genauso wie damals Dreamweaver.
Die richtige Lösung wäre Teamarbeit wenn der Grafiker keine Themes bauen kann oder will.
Ich mache immer noch beides, ich finde es spannender den Code zu schreiben und dann im Browser das Ergebnis zu sehen, wie man aus nichts etwas wunderschönes erschaffen kann. Klar, es klappt nicht immer, aber man lernt immer wieder was neues.
Für mich ist zufriedenstellender, wenn ich dem Kunden etwas liefere und genau weiß, das ich (vieles) per Hand gemacht habe.
Jedoch wäre es heute ohne Frameworks oder Templates als Basis, unerschwinglich Webseiten aus dem nichts heraus zu entwickeln, dann wären grafische Editoren wirklich besser^^.
Hallo!
Ein interessanter und zum Nachdenken anregender Beitrag.
Richtig dargestellt, benötigt es für eine erfolgreiche Webseite den technischen und den gestalterischen Teil.
Wenn man sich aber als Designer voll und ganz auf seine Kreativität konzentrieren und sich nicht um die Technik kümmern möchte, hat man aber noch eine andere Möglichkeit. Man arbeitet mit jemandem zusammen, bei dem das genau andersherum ist!
Die hier vorgestellte Variante von Designer + Wix ist ja genau das gleiche, nur dass man den technischen Teil jemand Unbekanntem bzw. einem technischen System selbst überlässt. Man macht sich damit meines Erachtens zu sehr von einer Technik abhängig, deren Zukunft man schwer beeinflussen kann.
Viele Grüße
Heiko Mitschke
Vielen Dank für diesen tollen Artikel! Ich kann die Position des Autors gut nachvollziehen, mir geht es genau so. Gestalten macht doch am meisten Spaß. Und trotzdem scheue ich mich davor, diesen Weg zu fahren. Die junge Generation ist mit Apple groß geworden, fit im Gestalten von Powerpoints und hat keine Probleme, sich selbst eine Website in Wix zusammen zu klicken. Unsere Nische ist es doch eigentlich, all das an Websites bauen zu können, was mit Wix eben nicht geht. Und deshalb ist eigentlich eher eine noch stärkere Spezialisierung in die technische Richtung erforderlich, zum Beispiel mit ProcessWire. Klassische FrontEnd-Designer gab es auch früher schon. Diejenigen, die auch Code schreiben konnten, hatten am Ende doch immer einen Vorteil.