Transcript
Speaker: Herzlich willkommen zum 404 Podcast mit André Goldmann. Wir sprechen in dieser Woche zum Thema Innovationsmanagement und wie wir Innovationen in bestehende und natürlich auch in neue Websites integrieren können und was ich da für ein Framework oder auch generelles System habe, wie ich da vorgehe. Das möchte ich dir in den nächsten knapp 30, 45 Minuten erzählen und freue mich, wenn du hier einiges Neues mitnehmen kannst. Viel Spaß dabei.
Speaker: Ja, seit dieser Woche ist es ja endlich soweit. Ich bin Mitglied vom Termfrequenz Podcast -Netzwerk und habe dadurch einen riesigen Schlag vieler neuer Hörer bekommen, was mich persönlich super freut, weil ich denke, dass man so auch noch viel mehr Menschen erreichen kann, die eben
Speaker: mit ihren Websites arbeiten, die eben ihre Websites besser machen wollen. Und dafür ist ja mein Podcast gedacht, nämlich ganz konkrete Ideen zu bringen, wie man Websites besser machen kann und wo die Probleme sind. Ja, wenn du mich noch nicht kennst oder auch dem 404 Podcast noch nie gehört hast oder auch von ihm gehört hast, möchte ich dir zwei, drei Sachen erst mal dazu sagen, auch wer ich bin, weil du solltest schon wissen, wem du hier zuhörst, sofern du mir komplett zuhörst, was mich natürlich freuen würde.
Speaker: Und ja, fahren wir vielleicht mal ganz kurz bei mir an, damit du den Hintergrund verstehst. Mein Name ist André Goldmann. Ich entwickle jetzt seit 20 Jahren, genauer gesagt seit 96 Websites. Damals natürlich noch nicht auf dem Niveau, wo wir heute stehen.
Speaker: Allerdings hat sich das bei mir nie verändert. Im Gegenteil, ich habe mir 2007 noch einen zweiten Skill angeeignet, und zwar habe ich mich 2007 mit dem Thema Suchmaschinenoptimierung auseinandergesetzt und bin da kleben geblieben und habe natürlich das ganze Thema Webentwicklung nie aus den Augen gelassen, weil da komme ich einfach her. Ich bin Frontendler.
Speaker: Ich code mein Leben gern und die Kombination aus ich baue Websites, vermarkte die und kriege über organische Treffer eben meine Besucher, meine Nutzer auf meiner Website. Das hat mich schon früh begeistert und so habe ich mich einfach wie gesagt seit 2007 eben ganz stark auf diesen Bereich fokussiert.
Speaker: Und habe auch damals schon eben für Kunden Websites gebaut, mit dem Hintergrund eben diese auch im Umsatz und in deren Reichweiten eben für Wachstum zu sorgen. Ja, und in diesem Zuge habe ich einige eigene Projekte gemacht, die hier auch in diesem Podcast das eine oder andere mal vorkommen. Dann auch namentlich in diesem Podcast, in dieser Folge jedenfalls keins. Da geht es um generelle Themen, Innovationsmanagement eben von Websites. Und
Speaker: Ja, ich möchte dir einfach ein paar Dinge eben geben im Podcast, die dir nicht immer hundertprozentig konkret weiterhelfen, zumindest nicht in dem Moment, wo du es hörst, weil es ist immer schwierig, das, was man gerade hört. Viele hören beim Autofahren Podcast, da kannst du eh nichts umsetzen. Was ich eigentlich schaffen möchte, ist dir Impulse zu geben. Ich möchte dir
Speaker: Ansätze geben, die du mal durchdenkst, die du auf dein Business, auf deine Art von Websites transferieren musst und wirklich überlegen solltest, wo du ansetzen kannst, um vielleicht was mit aus dem Gehörten rausziehen zu können, mit dem du arbeiten kannst. Das ist für mich eigentlich die Kernaufgabe, die ich mir gegeben habe, weil ich habe
Speaker: einfach die Schnauze voll von diesem schlechten Internet, was ich jeden Tag nutzen muss. Ich möchte einfach, dass wir bessere Websites haben. Und wenn es der Teil ist, den ich dazu beitragen kann, eben vielen Leuten die Möglichkeit zu geben, ihr Know -how zu verbessern.
Speaker: und mehr Wissen zu bekommen, wie man eben gute Websites baut. Dass ich damit jetzt nicht sagen möchte, dass du nicht selbst dazu in der Lage bist, aber ich denke, wenn wir uns mit anderen Menschen unterhalten oder auch wenn wir anderen Menschen zuhören, deswegen höre ich auch sehr gerne Podcasts, da zieht man sich eben noch mal Dinge raus, die
Speaker: auf die man vielleicht gar nicht selber kommt. Und das ist eben auch so der Grund, warum ich eben dieses Format Podcast so spannend finde und warum ich mich jetzt vor knapp elf Wochen dazu entschieden habe, eben einen eigenen Podcast zu machen, der jede Woche rauskommt. Das unterscheidet mich vielleicht von dem einen oder anderen Podcast, den du hörst. Jede Woche gibt es bei mir eine neue Folge.
Speaker: Genauer gesagt jeden Donnerstag um circa 20 Uhr. Das liegt immer ganz danach, wie dein Podcast, die App, die du nutzt oder auch dein Feedcatcher oder eben auch iTunes, wie schnell das aktualisiert wird. Aber sofern du auf Soundcloud hörst, dort hoste ich meine Podcasts. Dort wird pünktlich um 20 Uhr jeden Donnerstag eine neue Folge veröffentlicht.
Speaker: Ja, und in dieser Folge, wie gesagt, geht es um das Thema Innovationsmanagement und wie wir es schaffen können, unsere Websites eben auch innovativ zu machen. Und ganz wichtig finde ich es auch zu halten, weil das ist das Problem, was ich meistens sehe, ist, dass Websites gebaut werden und danach
Speaker: War's das? Das klingt vielleicht ein bisschen komisch oder vielleicht nicht ganz greifbar, aber ich denke, das kennt man von vielen Websites, an denen ich schon gearbeitet habe. Kann ich mich jetzt nicht außen vornehmen. Ich hab auch schon viele Seiten gebaut, die schnell mal eben gebaut wurden. Vielleicht weil auch nicht die nötige Zeit da war oder auch nicht das nötige Budget. Um da wirklich mal im Teil drüber nachzudenken, wie es eigentlich sinnvoll wäre, eine Seite aufzubauen.
Speaker: Und sobald es dann mal daran geht, dass man gewisse Innovationen machen soll, da rede ich jetzt nicht davon, dass man einfach mal irgendwie einen Slider einbaut oder solche Geschichten. Da reden wir noch lange nicht von der Innovation. Für mich ist Innovation etwas, was eine Website richtig gut macht. Und Innovationen sind in der Regel nichts, was man irgendwie zwingend gleich fertig irgendwo von der Stange kriegt, sondern da gehört eine Menge
Speaker: Eigeninitiative, eigenes Know -how, wissen, wie die Zielgruppe funktioniert, wie sie die Website bedienen soll. Das ist für mich Innovationsmanagement und nicht irgendwelche Plugins zu aktivieren und dann zu sagen, ja, wir sind jetzt
Speaker: mobilfähig oder jetzt haben wir auch AMP. Natürlich ist auch AMP eine Innovation und auch bestimmt für die eine oder andere Zielgruppe ganz nützlich. Aber für mich ist Innovation im Kern eigentlich eine bessere oder besser gesagt eine höhere Zufriedenheit bei meiner Zielgruppe, bei der Bedienung und bei der Verwendung meiner Website. Und das ist für mich steht ganz oben einfach, wenn ich Websites baue.
Speaker: Und in der Regel ist es aber so, dass wenn wir uns nicht im Vorfeld darüber Gedanken machen, wie wir die Website auch, ja, viele sprechen von Inhaltsarchitektur. Für mich gibt es die Inhaltsarchitektur aber nicht nur nach außen für den Nutzer, sondern eben auch nach innen. Das heißt, wenn ich mein Content -Management -System so schlecht aufsetze oder mir nicht im Vorfeld wirklich Gedanken mache, wie ich gewisse Parameter ansteuern kann, wie ich an Informationen in der Datenbank komme, dann wird
Speaker: später einfach in der Weiterentwicklung teilweise wirklich enorm schwer an diese Informationen ranzukommen, weil man sie einfach nicht im Vorfeld Gedanken gemacht hat.
Speaker: welche Informationen man später mal an welcher Stelle benötigt. Stichwort strukturierte Daten als JSON -LD. Da habe ich schon Websites gehabt oder auch übernehmen müssen oder eben besser gesagt von Kunden bearbeiten müssen, wo es für mich ein Graus war. Ich habe da mehrere Stunden dran gesessen, um eben aus der Datenbank die entsprechenden Informationen rauszubekommen an der Stelle, wo ich sie benötigt habe. Einfach weil der Entwickler, der da vorher dran gesessen hat, sich überhaupt keine Platte gemacht hat, ob vielleicht mal irgendwann jemand anders diese Seite übernehmen muss.
Speaker: und dann zuseht, wie er an diese Daten rankommt. Und das ist für mich zum Beispiel auch so ein Stück weit Kodex. Wenn ich eine Seite baue, auch für Kunden, dann arbeite ich grundsätzlich immer so genau, dass ich auch sicherstellen kann, dass wenn der Kunde irgendwann mal sich von mir
Speaker: oder vielleicht auch das Budget nicht mehr reicht, um mit mir zusammen zu arbeiten. Und der braucht jemanden oder macht noch eine Inhouse -Lösung, ja, das gibt es ja auch. Und wenn dann jemand da inhouse sitzt und der kann mit meiner Website nicht umgehen, ja, dann habe ich einfach schlecht gearbeitet. Und man muss ja vielleicht auch mal daran denken,
Speaker: dass zwar ein verlorener Kunde einem nicht mehr aktiv Geld bringt, aber ein verlorener Kunde im Umkehrschluss ein Sprachrohr nach außen ist. Weil wenn der die Erfahrung gemacht hat, dass Projekte mit Pixel Dreher oder André Goldmann einfach mal mega kompliziert sind, weil man später nicht mehr die Daten richtig nutzen kann, dann wirft das einfach ein schlechtes Licht auf mich und meine Leistung als Entwickler und natürlich auch im Umkehrschluss als Dienstleister, mehr bin ich an der Stelle natürlich nicht,
Speaker: Und das muss ich natürlich verhindern. Ich möchte, dass auch nach einem Projekt immer das Gefühl da ist, der hat sauber entwickelt. Und ich kann auch mit jedem anderen Entwickler damit umgehen oder eben das Projekt weitergeben, wenn das eben so gewünscht ist oder eben wegen In -House -Lösungen einfach auch der logische Schritt ist. Und ich möchte jetzt einfach mal ein bisschen darüber sprechen, wie ich vorgehe, wie auch du vielleicht vorgehen solltest in Zukunft und was ich für Probleme sehe.
Speaker: wenn man eben nicht daran denkt und wohin man eventuell steuert mit seinem Websiteschiff, wenn man eben gewisse Insellösungen einfach nur produziert oder eben nach außen weitergibt. Ich versuche jetzt erstmal so einen Klassiker von Websites darzustellen, der zu einer ziemlich hohen Anzahl im Internet da draußen irgendwo hingerotzt wird.
Speaker: Wenn du mich noch nicht kennst, ich benutze in der Regel keine Schimpfwörter, aber es gibt manchmal auch Dinge, da kann man es einfach nicht anders ausdrücken. Das ist dann einfach so, deswegen nutze ich auch mal so ein Wort wie hingerotzt. Ich nehme kein Blatt vorm Mund. Aber keine Angst, Hasthüraden werde ich nicht in irgendeiner Art und Weise verbreiten. Wie bauen jetzt viele Websites? Wie gesagt, sprich dich jetzt, wenn du jetzt so warst, dann kannst du dich vielleicht angesprochen fühlen.
Speaker: Aber nicht verletzlich, sondern mach dir vielleicht mal Gedanken, dass du's vielleicht anders machen solltest. Wenn du das eh nicht machst und du nur, in Anführungsstrichen, nur, also wenn du einfach Kunde bist von jemandem, dann solltest du vielleicht mal überprüfen, ob das, was du bekommen hast, nicht eventuell auf dem gleichen Niveau gemacht wurde. Ich hab vor kurzem eine Website übernommen, die hat eine Agentur gebaut für, ja, es waren so an die 20 .000 Euro.
Speaker: Ich nenne jetzt auch keine Kunden und auch keine Namen. Deswegen darf ich auch so eine Sache jetzt sagen. Diese Seite war gebaut. Es war natürlich eine WordPress -Site. Sonst hätte ich das auch nicht übernommen, weil ich einfach ausschließlich seit vielen, vielen Jahren mit WordPress arbeite. Und ich habe dafür im ersten Moment keine Worte gefunden, weil diese Seite so was von schlampig entwickelt wurde. Es wurde einfach mal überhaupt in keiner Art und Weise mal irgendwann an später gedacht.
Speaker: Wir sprechen jetzt nicht davon, dass es keine Versionierung bei GitHub oder im SVN gab. Für die, die das nicht wissen, darin kann man seine Websites versionieren und kann zu jedem Zeitpunkt an einen Entwicklungsschritt davor gehen. Also wenn man irgendwann sich mal verrannt hat in einer Entwicklung, dann hat man einfach die Möglichkeit, wieder an den Ursprung zurückzukehren.
Speaker: und dann eben einen anderen Weg einzuschlagen. Das ist eigentlich eine gängige Methode, wie man professionelle Websites baut und ist für den Entwickler am Ende natürlich auch ein Fallback, wenn man tatsächlich mal ein Problem hat.
Speaker: wird eine Website gehackt oder, oder, oder, ja, dann hat man einfach immer ein Backup und zwar für jede einzelne Versionierung einer einzelnen Datei, sei es CSS, sei es SAS, sei es PAP, egal was für eine Datei, man kann alles versionieren, größtenteils.
Speaker: Also davon sprechen wir noch nicht. Wir sprechen jetzt einfach nur davon, dass da eine WordPress -Site aufgebaut wurde, in die ein Forum, das zehn Jahre alt war, einfach mal dreckig in die SQL -Datenbank reingehackt wurde. Das heißt, da liegt jetzt ein riesiger Wust an vielen, vielen tausend URLs, die auch nicht über ein Management -System irgendwie bedienbar sind. Sie sind einfach da, stellt euch das vor wie statische Inhalte und
Speaker: Mit dem muss man jetzt umgehen. Das heißt, ich habe jetzt eine WordPress Installation, wo viele, viele schlechte Eigenentwicklungen drauf sind, wo auch der Code von der Sicherheit wirklich sehr, sehr fragwürdig ist.
Speaker: Und ich habe eben viele Inhalte in einer Datenbank, die weder performant ist, noch wirklich zu pflegen ist. Also man steht jetzt einfach vor einem riesigen Trümmerhaufen, wo viel, viel Zeugs drin rumliegt, was da eigentlich nicht hingehört. Wir haben gefühlte 20 Custom Post Types für jeden Müll da irgendwie drin liegen. Das heißt, auch da mal später zu sagen, wir fassen das Ganze mal zusammen, wir sortieren mal die Custom Post Types, ist
Speaker: wenn man es automatisiert macht, nur sehr, sehr schwer möglich. Das heißt, man muss sich erstmal etwas bauen, was eben aus den unterschiedlichen Custom -Post -Types vielleicht einbaut, etc. Das Problem an der Stelle ist aber, dem Kunden muss man jetzt erstmal klar machen, dass man jetzt viele, viele Stunden investieren muss in ein Produkt, was er schon für viel Geld bezahlt hat, um es überhaupt erstmal nutzen zu können als Entwickler. Also ich habe knapp
Speaker: sechs Stunden gebraucht, um diese Installation überhaupt für mich greifbar zu machen, dass ich in Zukunft damit arbeiten konnte, um dann erst mal aufzuräumen. Also wir reden jetzt nur davon, eine Entwicklungsumgebung aufzubauen. Wir haben jetzt auch, das muss man dazu wissen,
Speaker: Wir reden über eine Installation von knapp anderthalb Gigabyte. Für eine WordPress -Installation reden wir davon echt einer Menge. Natürlich mit den ganzen Bildern und PDFs und Filmen, die da hochgeladen worden sind, warum auch immer Filme, keine Ahnung. Jedenfalls, die werden noch nicht genutzt, das ist ganz davon ab.
Speaker: Wir reden auch über viele Dateien, die da hochgeladen worden sind, die Ewigkeiten nicht mehr genutzt werden, die auch nicht verknüpft sind mit irgendwelchen Artikeln. Wie gesagt, das muss man alles händisch raussuchen, weil wir haben ja eben ein riesiges Forum damit drin, wo man eben nicht mal eben überprüfen kann, ob da irgendwie einen Zusammenhang mit einem Threat besteht.
Speaker: Ihr könnt euch sicher vorstellen, ich kürze das Ganze jetzt mal ab, dass diese Installation für beide Seiten wirklich eigentlich ein Totalschaden ist. Für den Kunden, der einmal dafür bezahlt hat, jetzt zu einem neuen Dienstleister geht, der neue Dienstleister sagt zu ihm, ich kann mich jetzt hier mehrere Stunden oder manchmal sogar gar Tage dransetzen, um überhaupt erst mal damit arbeiten zu können. Und dann gucken wir mal, was am Ende das Ergebnis ist, was durchaus eben auch so sein kann, dass wir alles wegschmeißen und neu machen.
Speaker: Aber ich habe erst mal ein paar Tage quasi verarbeiten müssen. Wir reden jetzt auch gar nicht davon, dass das jetzt übertrieben viel ist. Natürlich große Websites, da muss man sich eben auch auseinandersetzen. Es geht mir aber um diese Tatsache, dass man quasi als Dienstleister dem Kunden etwas verkauft hat. Der Kunde geht mit keinem schlechten Gewissen an einen neuen Dienstleister ran und der muss im Grunde erstmal ihm klar machen, du pass mal auf, du hast jetzt zwar schon viel, viel Geld bezahlt, aber damit ich überhaupt damit arbeiten kann,
Speaker: musst du jetzt einfach noch mal zusätzlich zu dem Budget, was wir dann einfach vereinbaren, noch mal etwas oben drauf legen, damit ich überhaupt in der Lage dazu bin, mit diesem Dilemma umgehen zu können. Und deswegen ist es mir einfach so wichtig, dass wenn ihr mit Dienstleistern arbeitet oder auch wenn ihr Dienstleister seid, denkt bitte immer daran, was mal passiert, wenn ihr irgendwann nicht mehr da seid. Und wenn es auch
Speaker: vielleicht ärgerlich ist, wenn ihr einen Kunden verliert. Aber den Ruf muss man deswegen nicht gleich auch noch verlieren. Und das kann schnell passieren, je nachdem, wie viele Projekte ihr einfach stemmt. Ich habe viele Kollegen, gerade in der Entwicklung, die wirklich saubere Arbeit abliefern, wo ich mich wirklich darüber freue, wenn ich sowas mal sehe und entsprechend damit arbeiten kann, weil ich einfach weiß, da hat man sich auch über die Inhaltsarchitektur Gedanken gemacht, auf Datenbank -Ebene und eben generell das WordPress
Speaker: Wie gesagt, ich arbeite größtenteils eigentlich fast nur mit WordPress. Wirklich sauber aufgestellt. Es wurde alles geupdatet. Ich habe nicht irgendwie 10 .000 alte Codes. Das ist ja auch noch so ein Beispiel. Ich übernehme diese Website. 20 Updates sind fällig.
Speaker: Ich weiß weder, ob irgendwie in diesen Plugins mal irgendwann Code verändert wurde, weil wenn ich mir ansehe, wie dreckig der Rest gemacht ist, kann ich mir sehr gut vorstellen, dass auch in diesen Codes einfach mal was verändert wurde. Das heißt, mache ich jetzt ein Update, fliegt mir die Seite auseinander. Natürlich kann ich das Ganze debuggen und erstmal überprüfen, aber das ist einfach ein Aufwand, den ich machen muss.
Speaker: der irgendwo auch abgerechnet werden muss. Mir geht es eigentlich im Grunde darum, dass ich nicht möchte, dass ich mit einem Kunden ja gleich so einen negativen Start habe, weil ich ihm jedes Mal sagen muss, du pass mal auf, ich habe jetzt wieder anderthalb Tage verbaselt, weil ich erstmal gewisse Codes mir anschauen musste. Es geht jetzt auch, wie gesagt, nicht um diese eine Position auf der Rechnung. Es geht mir mehr um diese Tatsache, dass ich mit einem, auch als Dienstleister danach, einfach schon mit einem negativen
Speaker: Punkt in meiner Abrechnung beginnen muss, bevor ich überhaupt was Gutes produziere, eben eine Innovation. Und kürzen wir das Ganze jetzt mal ab. Ihr wisst jetzt, was ich meine. Wenn ihr Dienstleister seid, kümmert euch bitte darum, dass ihr wirklich eine saubere Code -Basis abliefert, egal, ob ihr das Projekt nur einmal erledigt und danach seid ihr raus oder auch, wenn ihr das Projekt weiterhin übernehmen möchtet.
Speaker: Das Problem bei solchen Insellösungen ist nämlich am Ende, dass man einfach 10 .000 Baustellen hat und keiner weiß so richtig, was hat jetzt hier eigentlich mal an welcher Stelle funktioniert, welches. Entschuldigt, wenn ich jetzt von WordPress immer spreche, also auch wenn ihr Drupal nutzt oder auch Typo 3, bei dem einen heißt das jetzt Add -on, da ist es eine Extension. Bei uns sind es eben Plugins, von daher transferiert das bitte auf eure eigenen Countermanagement -Systeme.
Speaker: Wenn ich jetzt eine Website habe und ich habe eben für einen Slider, für Taps, einen Akkordeon und was haben wir noch für schicke Döens, eine Navigation, Suckerfisch oder auch ein Off -Canvas, die ganzen JavaScript -Geschichten, die man eben so hat, um eine Website bedienbar zu machen. Und ich habe für alles irgendwie einzelne Plugins. Ich habe neulich einen Slider gefunden, ungelogen von 35 MB.
Speaker: Da dachte ich, ich guck nicht richtig. Also ein Slider. Ich meine, selbst ein aufgeblähtes Java -Script hat vielleicht 150, 200 Kilobyte. Da muss ich nicht 35 MB, wozu? Das muss man sich halt auch mal, wenn ich ein Studio machen muss, um so einen Slider zu verstehen, dann läuft doch irgendwas verkehrt. So, und was ich halt da empfehle, wenn ihr euch für etwas entscheidet, wenn ihr Seiten bauen möchtet, dann überlegt euch wirklich,
Speaker: ob es nicht vielleicht Lösungen gibt von professionellen Anbietern, die den ganzen Tag nichts anderes machen, als sich um dieses eine Kernprodukt zu kümmern, indem ihr, ich gebe jetzt mal ein Beispiel, wenn ich jetzt Seiten baue und ich habe zum Beispiel so eine Geschichten wie irgendwelche Lightboxen, Accordions, Taps etc., Slideshows, sofern ich sie einbaue. Manchmal muss es einfach sein, weil man gewisse Sachen einfach mit Bildern transportieren möchte.
Speaker: wenn ich so dynamische Dinge habe, die von Nutzern irgendwie...
Speaker: genutzt werden sollen. Dann nutze ich zum Beispiel grundsätzlich WidgetKit, das ist von U -Theme, die haben eigentlich mal vor langer Zeit begonnen Joomla Templates zu bauen, haben dann irgendwann angefangen das Ganze, also schon vor ein paar Jahren, eben diese Templates eben auch als WordPress -Theme zu entwickeln und haben eben mittlerweile auch ganz gute Add -ons, beziehungsweise eben auch WordPress -Plugins und unter anderem eben dieses WidgetKit, das gibt es jetzt auch schon in der zweiten Version.
Speaker: schon seit, ach gut, zwei, drei Jahren, wenn nicht sogar länger, kenne ich das Plugin und nutze das auch schon noch deutlich länger noch. Und da weiß ich einfach, dass da Profis am Werk sind, die auch eine saubere Code -Basis aufstellen, die ich für viele Sachen nutzen kann. Also gerade dieses Widget -Kit,
Speaker: ist auch vom Code, der dann tatsächlich im Frontend geladen wird, sehr, sehr sauber. Es wird dann nur der Code geladen, den ich tatsächlich benötige und nicht eben diese ganzen Accordions, Tabs und so weiter, wenn ich sie gar nicht brauche. Und was ich so schön finde an der Sache ist, ich bin total flexibel und bleibe innovativ. Wenn ich heute keinen Slider brauche, dann ist das in Ordnung.
Speaker: Wenn ich ihn aber irgendwann benötige, dann muss ich nicht erst wieder gucken, welche gibt's da jetzt eigentlich, dann muss ich schauen, dass ich nicht irgendeinen JavaScript miteinander verhakt, weil am Ende alles in diesem Budget -Kit drin ist.
Speaker: Da habe ich einfach mir im Laufe der Jahre gewisse Extensions, Plugins, Addons, wie auch immer, ich spreche jetzt immer noch von Plugins, das ist jetzt einfach einfacher. Ich habe mir ein gewisses Set am Plugins gebaut oder eben herausgesucht, wo ich mittlerweile den Code sehr, sehr genau kenne, weil ich genau weiß, wer schreibt den, was steckt da eigentlich drin, wie viel Know -how steckt da in einem Entwickler eigentlich, ist der Code sicher, das ist für mich einfach
Speaker: ganz, ganz wichtig, weil ich keine Seiten habe, in der Regel, die irgendwie, wo es unwichtig wäre, wenn die mal irgendwie 200 Tage down sind, sondern ich habe in der Regel eben Seiten oder eben auch Kunden, die wirklich viel Traffic haben und wo jeder Tag richtig Geld kostet, wenn die Seite nicht online ist. Und ich muss mich darauf verlassen können, dass der Code, der heute funktioniert, auch noch noch drei, vier Updates funktioniert. Deswegen habe ich zum Beispiel noch niemals ein Problem mit irgendwelchen Updates gehabt, weil ich nicht 20, 30 Plugins nutze.
Speaker: die ich weder kenne, noch wo ich weiß, wie der Code gebaut ist, noch ob ich weiß, dass da irgendwann mal vielleicht die Datenbankstruktur umgestellt wird innerhalb des Plugins oder auch kompletter Code sich verschiebt und dann fliegt es mir irgendwo um die Ohren. Nein, ich kann mich einfach darauf verlassen, dass das, was ich da benutze, wirklich funktioniert und ich könnte theoretisch, obwohl ich es nicht tue und auch niemals tun würde, blind auf Update drücken und ich wüsste, dass nichts passiert.
Speaker: Wie ich das mache, erzähle ich gleich noch, damit auch du weißt, wie ich Websites entwickle. Deswegen da mein Tipp, wenn du einfach etwas brauchst, dann schau mal bitte etwas über den Tellerrand hinüber. Nicht immer nur für jeden Teil, den du jetzt gerade irgendwie benötigst, ein Produkt raussuchen oder ein Plugin, sondern schau dir einfach mal an, okay, es gibt so gewisse Dinge, die braucht man vielleicht jetzt nicht heute, aber vielleicht morgen oder übermorgen. Und wenn man dann mal eben schnell
Speaker: Ich hatte das schon ziemlich häufig, dass dann der Kunde anruft, du, pass mal auf, wir möchten ganz gern mal so einen Tab drin haben oder so ein Akkordeon für FAQ. Dann kann man natürlich sagen, ja, das kann ich machen. Ich muss dann erst mal was bauen und dann muss ich erst mal das entsprechend miteinander testen, dass das alles funktioniert. Und am Ende rechne ich den Tag ab. Natürlich ist das irgendwie ganz lukrativ für den Anbieter. Ich finde allerdings
Speaker: Es ist irgendwie verkehrt, weil es gibt diese Lösung bereits und wenn man sich wirklich mal intensiv, und das ist in meinen Augen die Aufgabe, die ich als Dienstleister habe, auch im Sinne des Kunden, wenn ich mir wirklich Gedanken darüber mache, was sind so Dinge, die meinen Kunden irgendwann mal in irgendeiner Art und Weise berühren,
Speaker: dann habe ich da bereits darauf geachtet bei der Auswahl eines Plugins, sondern ich baue nicht einfach stumpf, heute ist die Anforderung so, das baue ich, sondern ich gehe einfach den Schritt weiter und überlege schon mal im Voraus, okay, wenn ich mir so die Website von dem ansehe und weiß, was so der Wettbewerb hat und ich weiß, dass viele Kunden immer beim Wettbewerb gucken und sich danach orientieren, ich rede jetzt nicht davon, dass es meine Empfehlung ist,
Speaker: Aber es ist eben so. Und ich sehe, dass eben drei Viertel irgendwelche Taps drin haben. Dann könnte das drei zählen, dass die irgendwann mal bei euch anrufen und sagen, Herr Goldmann, ich hätte ganz gerne mal solche Taps. Ich habe hier beim Wettbewerber das gesehen. Das sieht ja ganz schick aus und das scheint ja ganz gut zu funktionieren.
Speaker: Natürlich, ich hinterfrage solche Dinge auch immer, warum und wieso und was soll da eigentlich stehen und ich messe solche Sachen auch, also ich schüttel das nicht sofort ab, aber am Ende sind solche Sachen relativ klar und ich kann es mir viel einfacher machen, indem ich eben etwas raussuche, von dem ich sicher bin, dass ich auch in Zukunft dem Kunden schnell eine Innovation anbieten kann, die
Speaker: er haben möchte. Und zum anderen kann ich aber auch so vorgehen, dass ich gewisse Dinge ganz proaktiv vorschlage und einfach, nicht einfach integriere, aber einfach mal eine Testseite aufbaue und dann einen entsprechenden Vorschlag mache. Weil am Ende ist das alles Kundenbindung, die ich damit schaffe. Wenn ich weiß, als Kunde, mein Dienstleister das bemüht, der macht auch mal von sich aus was, dann bringt mir das einfach eine gute Bindung auf beiden Ebenen.
Speaker: Ja, sollte ich jetzt alles selbst entwickeln? Das ist halt auch so eine typische Frage. Sprechen wir mal wieder von Innovation. Ich habe einen guten Kollegen, mit dem eine Unterhaltung neulich gehabt, der vieles selber entwickelt, was auch gut ist. Also die Basis und was er da entwickelt, ist wirklich astrein. Da ziehe ich meinen Hut vor. Der Unterschied ist nur, wenn ich jemanden habe, der braucht einen Tag, um das zu entwickeln.
Speaker: Und ich brauche da eine halbe Stunde für. Und das Ergebnis ist am Ende das gleiche, nur ich habe den Code nicht selbst geschrieben, der andere hat es doch gemacht.
Speaker: Es ist ein bisschen schwierig, jetzt sage ich mal, das weg zu argumentieren. Natürlich, eigener Code ist immer gut. Ich glaube aber, wenn man Code benutzt, den man sehr genau kennt und weiß, wie er funktioniert und weiß, wo gewisse Dinge in die Datenmärkte geschrieben werden, um auch später an anderen Stellen heranzukommen, dann kann man sich auch Dinge nehmen, die es bereits gibt und die bereits getestet wurden und vor allem, wo ein Entwickler hintersteckt, der das Ganze
Speaker: nicht kostenfrei macht. Auch das fehlt mal so ein kleiner Hinweis. Ich benutze ausschließlich kostenpflichtige Plugins oder Lösungen. Einfach aus dem Hintergrund, ich brauche jemanden, der mir im Fall der Fälle hilft. Bei allen Dingen, die kostenfrei sind, ziemlich sicher könnt ihr davon ausgehen, ihr kriegt nur Hilfe.
Speaker: wenn er Sergei Müller heißt, aber der entwickelt leider nicht mehr, für WordPress zumindest. Da konnte man einfach sicher sein, früher, der Sergei hat einem geholfen. Und natürlich gibt es auch viele andere WordPress -Entwickler, die wirklich bemüht sind, einem zu helfen, aber glaubt mir, das ist eher eine Rarität im Schrank der WordPress -Entwickler.
Speaker: Deswegen versuche ich immer, wenn es geht, auf kostenpflichtige Plugins zu setzen, weil ich einfach weiß, dass da zum einen eben auch einen Support hinterhängt und zum anderen aber auch eine hohe Kundenbasis, mit der man sich einfach nicht verscherzen möchte, wo man auch von sich aus auch gewillt ist, Probleme, Sicherheitslücken oder auch Fehler schnell zu fixen, damit eben es da auch keine schlechten Stimmungen irgendwie produziert oder ein Shitstorm, im schlimmsten Fall sogar. Deswegen sitze ich immer auf kostenpflichtige Geschichten.
Speaker: Ich entwickle natürlich auch selbst, also ich wäre ein schlechter Entwickler, wenn ich immer nur alles Kosten mir irgendwie einkaufen würde. Aber auf der anderen Seite, wie gesagt, schaue ich auch immer, dass das Ganze irgendwie in einem wirtschaftlichen Rahmen bleibt, der vertretbar ist für beide Seiten.
Speaker: Und dann leg ich los, weil am Ende Innovation auch natürlich ein Stück weit was von Geschwindigkeit hat. Ich kann nicht innovativ sein, wenn ich ein halbes Jahr brauche, um eine neue Funktion zu bauen, wenn es die vielleicht schon gibt und ich sie lediglich für mich adaptieren muss oder eben leicht anpassen kann.
Speaker: um genau das zu erreichen, was ich haben möchte. Man sieht ja auch, wie viele Start -ups gebaut sind. Dort kann man auch gar nicht so viel auf Zeit setzen. Man hat einfach die Zeit nicht, weil das Geld nicht da ist. Und die meisten Innovationen sind eben eher von Unternehmen, die aus Geschwindigkeitsgründen Dinge machen müssen,
Speaker: weil sie jetzt einfach Geld verdienen müssen mit dem, was sie da produziert haben. Und viele sind dann einfach so, dass sie einfach auf bestehende Sachen aufsetzen. Ich verteufel auch keine fertigen Seams. Also wer gerade startet und jetzt auch noch nicht das Budget hat, jetzt einen Entwickler zu bezahlen, der eben wirklich was Unikes baut, keine Frage, dann fang mit was Fertigem an. Also ich nutze auch sehr, sehr gerne für Seiten, die ich mal testweise aufbaue, um ein Produkt zu testen, ob das Sinn macht, das weiter zu
Speaker: zu beackern und erst mal es zu entwickeln, mache ich sehr gerne Websites, um erst mal Adressen zu sammeln mit dem db -theme. Das ist von Elegant -Themes ein super mächtiges Framework, mit dem man eigentlich jede Form von Website sehr sehr unik zusammenbauen kann.
Speaker: Man benötigt, um zumindest mal den größten Teil aller normalen Websites abzubilden, keinerlei Entwicklungsknow -how. Was einem am Ende leider immer fehlt, ist ein gewisser Blick für Ästhetik und für Nutzerführung, wie man gewisse Sachen baut.
Speaker: Das kann man sich halt auch einkaufen. Und wenn ihr da Hilfe braucht, ich biete so was an. Na, aber es ist einfach so, schaut euch Divi einfach mal an, wer jetzt mal schnell so eine Website bauen muss, um Produkte zu testen oder eben erst mal, um so eine Presale -Page zu bauen oder eben generell erst mal so ein Dummy. Dafür nutze ich es auch sehr gerne, um zum Beispiel mal erst mal so einen gewissen Website
Speaker: Aufbau zu zu kreieren. Mit Mockups hat man das früher gemacht, so mit der klassischen Software, dass man so eine Dummy -Grafik irgendwo hinzieht. Das mache ich mittlerweile mit Divi, weil da habe ich eben den riesigen Vorteil, dass ich eben auch Seiten bedienbar bauen kann. Und das ist halt schon eine schöne Lösung.
Speaker: Der Nachteil bei Divi ist natürlich, wenn ihr dann irgendwann mal sagt, jetzt möchte ich gerne eine richtige Website haben, dann empfehle ich euch nicht einfach zu sagen, ihr aktiviert ein neues Theme und lasst Divi da so liegen. Divi arbeitet mit massiv viel Shortcode -Zeugs, was am Ende, sobald ihr Divi deaktiviert, nicht mehr funktioniert. Das heißt, ihr solltet dann wirklich sagen, die Divi -Website bleibt so lange bestehen, bis die neue Website wirklich fertig ist und das macht ihr dann nach Möglichkeit mit der neuen Installation.
Speaker: um hier einfach keine Probleme zu kriegen. Aber Divi hilft euch auf jeden Fall, um schnell Seiten aufzubauen, die ihr einfach mal braucht, um Dinge zu testen oder auch eben, um erst mal Adressen zu sammeln. Also dafür super geeignet. Das wäre auch tatsächlich so die einzige Insel, die ich so nutzen würde, um ein Produkt innovativ erst mal zu testen. Also ob es überhaupt innovativ ist und ob es angenommen wird von meiner Zielgruppe, da eignet sich Divi auf jeden Fall.
Speaker: Ja, wie mach ich das jetzt? Also ich hab jetzt eben eher so diese Probleme skizziert und auch so schon mal die eine oder andere Lösung, wie ich eben vorgehe, Beispiel Widget Kit. Aber was ich euch empfehlen kann, um innovativ zu bleiben, um überhaupt erst mal Dinge aufzubauen, ist ein kontinuierlicher Relaunch. Ihr tut euch keinen Gefallen damit.
Speaker: ständig die Notbremse zu ziehen, aus dem Fenster zu hüpfen und sagen, hey, hier ist unser neues Layout, das ist unsere neue Website, schaut doch mal vorbei. Ihr helft weder euren Nutzern damit, noch euch, noch Google oder sonst wem, dem ihr irgendwie gefallen müsst. Der Nachteil ist relativ klar bei so einem kompletten neuen Relaunch, ihr habt einfach
Speaker: Ein komplett neues Layout. Ihr habt eine neue Code -Struktur. Beim Layout muss sich der Nutzer damit auseinandersetzen, was problematisch ist, wenn ihr eben auch viel Traffic habt. Oder zum Beispiel auch eine Community, einen Online -Shop, der zum Beispiel häufig genutzt wird. Und ihr habt ein neues Layout, da muss sich der Kunde erstmal damit auseinandersetzen. Er muss erstmal verstehen, wo waren jetzt eigentlich die Dinge, oder wo sind jetzt eigentlich die Dinge, die ich aus der Vergangenheit schon gut kannte.
Speaker: Und die meisten Relaunches sind oft eben auch gekoppelt an einen Agenturwechsel. Also oft, nicht immer, aber oft. Und meistens lebt man sich dann mal so richtig aus und dann machen wir alles neu, weil das, was die vorherige Agentur gemacht hat, ist natürlich alles für die Cats und taugt ja alles nicht, deswegen machen wir jetzt mal alles neu. Das Problem ist einfach mal, ihr schmeißt alles hin.
Speaker: eure ganzen Analysen, die ihr gemacht habt. Schön, dass ihr das habt, aber ihr könnt's wegschmeißen, weil es ist nicht mehr vergleichbar. Ihr könnt natürlich sehen, oh, es ist besser geworden, oh, es ist schlechter geworden, aber ihr könnt keine einzelnen Fragmente eurer Seite mehr in irgendeiner Art und Weise miteinander vergleichen, weil halt alles anders ist.
Speaker: Im Idealfall habt ihr ja noch einen URL -Wechsel gemacht, das war jetzt Ironie. Dann könnt ihr sowieso gar nichts mehr miteinander vergleichen, weil ihr das nicht mal miteinander mappen könnt. Und deswegen kann ich wirklich nur empfehlen, also vom URL -Wechsel sowieso würde ich weitaus Abstand nehmen, weil so wichtig ist das Ganze auch nicht.
Speaker: Sofern ihr nicht wirklich Mist gebaut habt in der Vergangenheit. Aber wenn ihr eine Website habt, dann tut euch wirklich den Gefallen und verändert eure Seite auf Modul -Ebene. Modulare Aufbau oder eben generell Modulare Relaunch ist einfach das, was am besten für euch funktioniert und für eure Nutzer.
Speaker: Ich würde das eigentlich umdrehen für eure Nutzer und natürlich auch für euch. Bei Modulare Aufbau gibt euch die Möglichkeit, Innovation zu integrieren in bestehende Website -Typen oder eben auch bestehende Systeme, weil ihr eben nicht mehr alles wegschmeißen müsst und neu, sondern ihr könnt einen Teil neu machen, an den kann sich ein Nutzer gewöhnen, währenddessen noch ein Großteil der Seite so ist, wie er das gewohnt ist. Das heißt, er hat nur einen kleinen Teil, an den er sich neu gewöhnen muss und nicht mehr alles neu.
Speaker: Und auf der anderen Seite natürlich auch Google, weil Google eben nicht einen kompletten neuen Code vorgeworfen kriegt, sondern eben nur einen Teil davon, der jetzt anders ist. Und kleine Happen sind meistens etwas leichter zu verdauen als große Happen. Das ist wie mit dem Essen und so geht das Google genauso. Und deswegen kann ich euch das wirklich nur empfehlen, wenn ihr eure Website
Speaker: verändert, dann macht das bitte immer nur in einzelnen Etappen und für einzelne Bereiche. Wenn natürlich alles so wie in dem ganz zu Beginn genannten Beispiel auf gut Deutsch für ein Arsch ist, dann hilft euch auch kein modularer Relaunch mehr. Da muss man dann einfach mal die Brechstange rausholen und muss einfach mal wirklich alles offen Müll werfen. Das ist auch tatsächlich eine Geschichte, die ich sehr sehr ungerne oder selten mache, aber in dem Fall muss ich es tatsächlich so machen.
Speaker: Wie gehe ich jetzt vor und was gibt es eigentlich für Voraussetzungen? Als Voraussetzung natürlich ist erst mal, dass das, was ihr habt, wirklich gut ist. Eine bestehende Seite, von dem ihr im Idealfall mit dem Code auch wirklich zufrieden seid, die ist natürlich, um Längen leichter modular zu verändern, als eine Seite, die ihr übernommen habt. Das sind so Klassiker, wie jetzt zum Beispiel, wenn ihr jetzt mit SAS arbeitet, die Leute, die mit CSS in der Vergangenheit gearbeitet haben und sich vielleicht da auch in Richtung SAS orientiert haben.
Speaker: Die werden wissen, dass es problematisch ist, wenn die Seite, die ihr jetzt übernehmt oder an der ihr jetzt arbeitet, es gibt dort keine SAS -Files. Dann müsst ihr jetzt erst mal zusehen, dass ihr das bestehende Layout bzw. die Layout -Datei des CSS in eine SAS umbaut.
Speaker: Wer das mal gemacht hat, der weiß, was das für ein Aufwand ist. Das ist nicht lustig, aber am Ende ist das auch eine modulare Innovation, weil nämlich alle weiteren Schritte, die ihr machen müsst, um eurer Website besser zu sein oder eben mit eurer Website, davon profitiert das ungemein, weil ihr viel schneller seid eben in Anpassungen, in Veränderungen, wenn ihr mit SAS arbeitet. Das mache ich ausschließlich bei allen Dingen, die ich mittlerweile mache.
Speaker: Auch wenn es Plugins sind. Nicht nur Steam, sondern auch Plugins. Alles mit SAS ist wirklich super. Wer das mal gemacht hat, der wird sehen, das ist ein Problem. Deswegen ist eine Voraussetzung schon mal im Idealfall habt ihr SAS zur Verfügung. Wenn nicht, dann fangt damit bitte gleich zu Beginn an. Wer aufschiebt, verschiebt nur das, was definitiv
Speaker: zu tun ist. Es ist wirklich so, die Innovation gerade bei der Website Layouts ist einfach mal an der Stelle schon mal SAS statt CSS und das ist eine Voraussetzung, die ich habe. Ich muss SAS nutzen können. Ein weiterer Punkt ist der, dass ich mich mittlerweile davon verabschiedet habe, dass ich alles selbst baue.
Speaker: Das heißt nicht, dass ich den Code nicht selbst schreibe, sondern ich benutze seit mittlerweile gut anderthalb Jahren das Genesis -Theme. Das ist ja im Grunde ein Framework, was mir gewisse Dinge vorgibt, über die ich lediglich
Speaker: über einen Childseam Veränderungen oder Ergänzungen hinzufüge. Ihr müsst euch das wirklich so vorstellen, dass die grundsätzliche Code -Basis vorgegeben ist, ich aber über WordPress -Filter und Hooks mir gewisse Dinge modifizieren kann oder eben dazu packen kann. Es gibt in diesem Seam eine
Speaker: schier unbegrenzte Anzahl an an Plätzen, wo ich bestimmte Sachen integrieren kann. Ist jetzt schwierig, ich wäre damit noch nicht gearbeitet, dass das jetzt irgendwie zu zu visualisieren in einem Podcast, aber es ist wirklich enorm und der Vorteil ist einfach, dass das Genesis im Grunde das HTML5 -Gerüst ist, was ich eigentlich habe und ich ergänze dieses Gerüst um Informationen, die ich für das jeweilige Projekt benötige und muss mich lediglich um das Layout kümmern, weil ja die Code -Struktur
Speaker: Die macht Genesis und diese Code Struktur ist bei Genesis in meinen Augen wirklich sagenhaft gut. Ich habe lange nicht so ein wirklich gutes Framework gesehen, was für so viele unterschiedliche Ansätze wirklich zu gebrauchen ist. Das kann ich wirklich nur empfehlen. Dieses Genesis Framework, wer von euch WordPress Seiten entwickelt und auch für Kunden entwickelt, schaut euch das an, weil ihr einfach nur noch modulare Dinge bauen müsst und nicht mehr das große Ganze.
Speaker: beschleunigt eure Prozesse ungemein. Und das ist halt, um Innovationen zu bringen, eben enorm wichtig, weil ihr müsst schnell sein. Es kann nicht sein, dass ihr euch immer noch um klassische HTML -Konstrukte kümmert, weil im Grunde könnt ihr alles zumindest im Workplace über PHP steuern und ihr seid so viel, viel schneller. Also Frameworks wirklich anschauen.
Speaker: Ein weiterer Punkt, mit dem ich jetzt angefangen habe, muss ich dazusagen, das heißt mir fehlt hier noch die endgültige Beurteilungsfähigkeit, ist der Beaver -Bilder. Viele kennen oder zumindest einige kennen, die mit WordPress arbeiten, bereits diese ganzen Drag -and -Drop -Geschichten.
Speaker: die eine Menge Schrott produzieren. Das lässt sich nicht anders sagen. Am Ende bleibt auch nur noch ein Haufen Shortcodes über, wenn ihr dann euch mal dafür entscheidet, das zu deaktivieren. Beim Beaver Builder ist das ganz anders. Der Beaver Builder ist am Ende zwar schon vorkonfiguriert mit bestimmten Website -Fragmenten, die ihr nutzen könnt, wie jetzt zum Beispiel E -Mail -Sign, Newsletter -Anmeldung halt oder
Speaker: Slider, Taps und diesen ganzen Kram, den man ebenso braucht, um eine Website zu bauen. Aber, und das finde ich eigentlich viel, viel intelligenter an der Stelle, ihr müsst die nicht nutzen, sondern ihr könnt euch eigene Module bauen, die für den jeweiligen Anwendungsfall wirklich, also für die Website wirklich gedacht sind. Und das Schöne ist, diese Module sind auf zwei
Speaker: Ebenen konfigurierbar auf der einen Seite, wie man im WordPress -Backend diese nutzt oder an welcher Stelle, also das ist auch dann per drag -and -drop, das heißt auch ganz normaler Content -Manager, muss kein Code verstehen können, um wirklich sehr, sehr unike Content -Erlebnisse quasi zu kreieren, ohne mit Shortcodes oder so ein Kram zu arbeiten.
Speaker: Und auf der anderen Seite könnt ihr aber als Entwickler auch bestimmen, wie die Code -Struktur aussieht, die da am Ende rauskommt. Das heißt, ihr seid auch da nicht irgendwie abhängig von irgendwelchen Entwicklern, die dann vielleicht gut oder schlecht entwickeln, sondern ihr könnt wirklich Einfluss haben darauf, was man im Backend nutzen kann und auf der anderen Seite, was dann aber auch vorne rauskommt. Und das finde ich schon ziemlich innovativ, wenn man sich eben bedenkt, dass eben diese Zeiten vorbei sind, eben die 0815,
Speaker: Content -Layouts, wo man einfach flexibel sein muss, wo es eben unterschiedliche Content -Formate gibt, die man mittlerweile integriert. Da empfehle ich wirklich den Beaver -Bilder. Das, was ich bis jetzt gesehen habe, ich bin jetzt seit ein paar Monaten da sehr aktiv mit, begeistert mich und es macht Spaß damit zu arbeiten. Auch die Lernkurve ist, sage ich mal, in Ordnung.
Speaker: Man muss sich ein bisschen damit auseinandersetzen, aber nach einem halben Tag hat man begriffen, wie man dafür Module entwickelt und dann kann man da richtig Gas geben. Und das Schöne ist, man kann diese Module auch für zig andere Installationen nutzen, einmal gebaut, könnt ihr das für weitere Projekte anwenden. Das ist wirklich eine Sache, die finde ich wirklich gut. Ich habe jetzt gerade mal kurz den Faden verloren, weil zu diesen BIVA -Bilder wollte ich noch eine Kleinigkeit ergänzen. Vielleicht fällte ich mir später nochmal ein.
Speaker: Ja, das ist jetzt gerade mal blöd. Das hat mir eigentlich gerade gepasst. Ich arbeite im Übrigen ohne Schnitt. Also das ist hier ein One Take Podcast. Deswegen, ich mache jetzt einfach mal weiter. Vielleicht fällt es mir noch wieder ein oder ich ergänze das in der kommenden Woche. Als letzten Punkt, wie man Innovationen einfach auch aufbauen kann. Und das ist, glaube ich, ein Punkt, der nicht zu unterschätzen ist. Jedenfalls einer, den ich sehr, sehr gerne eben auch benutze für meine eigenen Projekte oder eben auch für Websites, an denen ich arbeite.
Speaker: und zwar die Meinung von externen. Damit meine ich jetzt nicht zwingend die externen Klassiker, Eltern, Geschwister und Verwandte und Bekannte, sondern damit meine ich tatsächlich auch externe Menschen, deren Kompetenz ihr als wertvoll erachtet, die auch ein Stück weit losgelöst von
Speaker: dieser Privatästhetik sind. Es geht mir bei Websites in der Regel nicht darum, ob sie jemandem gefallen, der natürlich am Ende derjenige, der sie bezahlt, dem muss es auch gefallen. Also man sollte sich schon mit der Website identifizieren können, die man da selber hat. Aber am Ende zählt für mich das, was die Zielgruppe empfindet und ob die Zielgruppe sich gerne mit meiner Website auseinandersetzt und ob sie diese gerne bedient.
Speaker: Und da arbeite ich sehr gerne datenunterstützt. Ich mag den Ausdruck datenunterstützt lieber als datengetrieben, weil datengetriebene in der Regel eben auch nicht weiter können oft. Also nimm es mir nicht übel, aber ich finde dieses Thema datengetrieben etwas schwierig, weil ohne Emotionen und ohne eigenen Grips
Speaker: könnt ihr einfach keine sauberen Websites bauen. Natürlich können die konvertieren, wenn ihr rein datengetrieben seid, aber ihr müsst schon ein Stück weit verstehen, für wen ihr da was macht und was ihr da eigentlich macht. Und da hilft euch auch nicht irgendwie in Analytics -Konto irgendwie perfekt bedienen zu können, sondern man muss einfach auch von selbst aus ein bisschen empathisch sein für die Zielgruppe und verstehen, wie die funktioniert und was die eigentlich braucht.
Speaker: Die Meinung von extern finde ich an der Stelle wirklich wichtig, weil diese nämlich auch emotionslos daran gehen kann. Auf der einen Seite brauchen wir Emotionen auf der Seite, damit sich die Zielgruppe gerne auch wiederkehrend bei uns aufhält. Aber auf der anderen Seite bin ich eben eine Innovation machen muss und ich muss als Mensch eine Website produzieren, die wirklich innovativ ist oder die innovative Bestandteile hat.
Speaker: dann brauche ich auch mal jemand von extern, der nicht irgendwelche Befindlichkeiten hat. Das Problem hat man nämlich mittlerweile in vielen größeren Teams, wo Entwickler etwas bauen. Ganz schlimm sind da Designer. Ich spreche da aus eigener Erfahrung, weil ich nämlich selber mega empfindlich darauf bin. Mittlerweile aber ganz gut weiß, wie ich damit umgehen kann, wenn ich weiß, dass der mir gegenüber auch die nötige Kompetenz besitzt.
Speaker: Möchte damit jetzt nicht irgendwie arrogant wirken, aber ich finde es einfach wichtig, dass man das einfach trennt, ob jemand professionell etwas beurteilen kann aus Usability -Gesichtspunkten und auch aus Zielgruppenaspekten.
Speaker: Oder ob es darum jetzt geht, finde ich hübsch oder finde ich nicht hübsch, weil es interessiert mich nicht, ob jemand das hübsch findet, den ich im Grunde gar nicht gefragt habe oder der die Seite nicht bedienen muss. Ich freue mich, wenn es jedem gefällt, aber am Ende muss es dem gefallen, der den Köder auch schlucken muss. Das kennen wir schon, Anglerfisch, diese Geschichte.
Speaker: Deswegen versuche ich immer mal jemand externes zu holen, dessen Kompetenz ich wirklich als sehr hoch empfinde und der eben ohne Emotionen mir auch sagen kann, ob er das gut oder auf gut oder scheiße findet. Ob das, was ich da gemacht habe, in seinen Augen wirklich funktionieren kann und was er vielleicht noch verbessern würde.
Speaker: Weil, sobald ihr Emotionen im Spiel habt, überlegt ihr euch, wenn ihr jetzt zum Beispiel, ihr habt in -house einen Grafiker, ganz klassisches Beispiel, und ihr gibt ihm die Aufgabe, macht mal unser Menü, macht mal bitte für die mobile Ansicht, macht das mal bitte hübscher. Klassiker. Nicht sagen, was man eigentlich haben möchte, einfach nur, dass einem das Bestehende irgendwie nicht mehr gefällt.
Speaker: Dann setzt er sich ran und denkt sich so, okay, jetzt will er das hübscher haben. Ich find's ja eigentlich schon hübsch und das funktioniert ja auch, aber ich weiß ja, man sieht sich an seiner eigenen Seite meistens selber satt. Das ist immer so ein Grund, wenn's keinen Grund für einen Relaunch gibt, dann sucht man sich dieses, ich find das nicht mehr schön, und dann macht man's einfach. Nehmen wir das mal als klassischen Ansatz. Dann setzt er sich hin und macht zwei, drei Entwürfe, wie es denn in Zukunft aussehen könnte.
Speaker: Ungetestet natürlich, er macht einfach Entwürfe, weil es ihm so gefällt. Dann gibt er das weiter und wenn er glückert, dann gefällt dem Entscheider ein Entwurf. Wenn er Pech hat, sagt der Entscheider aber, wenn er sich ungünstig ausdrückt, das sieht scheiße aus, gefällt mir nicht. Was haben wir da im Spiel? Wir haben Emotionen im Spiel. Der Entscheider sagt in dem Fall zu dem Designer, gefällt mir nicht, was du da gemacht hast.
Speaker: Und damit haben wir diese Emotionen im Spiel, dieser Angriff gegen meine Leistung. Jemand findet das, obwohl er nicht in der Lage eigentlich dazu ist, das zu beurteilen, ob das funktioniert. Das geht hier rein nach ästhetischen Gesichtspunkten, sagt er zu mir, das sieht nicht gut aus.
Speaker: Drücken wir es mal so aus, wie es ist, sieht scheiße aus. Dann fühle ich mich als Designer in der Regel meistens angegriffen, weil ich weiß, ich habe da eine Ausbildung genossen oder ich habe, wie in meinem Fall, jetzt wirklich viele Jahre Erfahrung. Ich habe da keine Ausbildung genossen, aber ich habe einfach die Erfahrung gemacht. Und dann kommt da jemand, der einfach nur aus seinen ganz persönlichen Ansichten mir sagt, wie er das optisch findet. Weder ob er das bedienen möchte oder whatever.
Speaker: sofort haben wir eine Stimmung, die schon aufgeladen und jeder Entwurf, den ich dann noch liefern würde als Designer, der dann noch mal abgelehnt wird im schlimmsten Fall, weil ich vielleicht auch kein wirklich
Speaker: nützliches Feedback bekomme, was jetzt genau nicht gefällt und vor allem das Warum. Für mich ist bei jedem, bei jeder Kritik immer eigentlich das Warum entscheidend, weil ich diese Gründe erstmal verstehen muss, um zu wissen, was ich jetzt anpassen muss oder was ich ändern sollte. Um etwas zu erreichen, muss ich halt immer wissen, warum ich das mache und was die genauen Gründe sind. Und bei externen
Speaker: um das jetzt mal abzukürzen, weil ich denke ihr habt jetzt langsam begriffen, was ich damit meine, dieses Emotionsgeladene hin und her und dann hat man einfach irgendwann Beef und dann mag man den anderen nicht mehr sehen und im schlimmsten Fall kündigt der Designer. Das wollen wir natürlich alle nicht, deswegen versucht auch
Speaker: Vielleicht, wenn ihr auf C -Ebene arbeitet oder ihr habt eine leitende Position und ihr habt Designer, holt euch auch mal jemanden von außen, der solche Sachen mit euch gemeinsam moderierend gestaltet, um einfach auch ein gemeinsames Ziel zu erreichen, ohne dass Beef herrscht. Weil ich habe das schon ein paar Mal gemacht, dass ich von einem Kunden gebucht wurde, der mich eigentlich nur als Art Moderator mit fachlichem Hintergrund eingesetzt hat.
Speaker: um eine professionelle Stimme von außen zu bekommen, die dann aber auch geht. Wenn ich dem Designer sage, pass mal auf, das hast du nicht gut gemacht, probier's doch mal mit der und der Methode oder versuch's doch mal so und so, dann fühlt er sich vielleicht ein bisschen weniger angegriffen, weil er ja erstmal weiß, dass wir uns einfach auf Augenhöhe begegnet sind.
Speaker: weil ich eben auch weiß, wovon ich spreche. Und auf der anderen Seite, wenn es auf warum auch immer bei dem Designer dann irgendwann mal zu Beef kommt, oder es kann ja eine andere Geschichte sein, ich hab auch schon, das mache ich relativ häufig, SEO Audits gemacht, wenn ich sage, das und das stimmt nicht,
Speaker: Dann kriegt ihr einen Audit von mir, da steht das drin und danach, wenn man das möchte, ist Ruhe. Dann bin ich raus aus der Geschichte und dann kann man das abarbeiten. Es gibt aber keinen Beef zwischen Kollegen und das finde ich ist immer wichtig an der Stelle. Deswegen ist diese Meinung von außen eben ohne Emotionen und irgendwelche vorbestimmten Workflows und Tools enorm wichtig, um einfach auch mal ein anderes Bild zu kriegen von dem, was man da macht.
Speaker: und um einfach auch mal ja gewisse dinge zu überdenken weil man ist irgendwann in so einem gewissen trott drin wo man schon lange lange zeit an der website gebaut hat und dann einfach auch nicht mehr
Speaker: viele Dinge sieht und auch gewisse Dinge ja auch nicht mehr an sich ran lässt, wenn das immer nur auf Kollegenebene kommt. Deswegen finde ich das immer eigentlich ziemlich wertvoll, wenn man auch mal so einen Blick von außen bekommt, wie gesagt immer mit dem fachlichen Hintergrund, weil dann kann man damit auch arbeiten und kann einfach seine Website kontinuierlich besser machen. Als aller allerletzten Tipp habe ich jetzt noch ein Buch, was ich dir empfehlen möchte.
Speaker: Das war jetzt ein ziemlich abruptes Ende, das ist mir auch gerade aufgefallen, aber ich glaube, du hast jetzt wirklich in den letzten, ich hab jetzt keine Ahnung wie lange, aber es muss bestimmt über eine halbe Stunde sein, viele Dinge gehört, die vielleicht manchmal etwas komisch klangen und ich hoffe du nimmst mir den einen oder anderen Ansatz auch nicht übel, aber manche Sachen müssen einfach so ausgesprochen werden. Ich denke du hast einige Dinge jetzt gehört, die du vielleicht auch mit Sicherheit auch schon kanntest, aber vielleicht auch das eine oder andere hast du mitgenommen, wo du
Speaker: Ja, dir einfach mal Gedanken zu machst jetzt in den nächsten Minuten und vielleicht sogar auch in den nächsten Tagen und wo du einfach dir überlegst, wie du da rangehen solltest und was du vielleicht besser machen kannst, wie du vielleicht deine Workflows veränderst oder auch, gerade wenn du jetzt eben auch eigene Websites baust, dass du vielleicht auch mal gewisse Dinge eher versuchst zu standardisieren, um einfach dann, wenn es sein muss, schneller sein zu können.
Speaker: indem du eben eigene Sachen machst oder eben auch auf bestehende Technologien aufsetzt und diese eben verwendest. Ich glaube, da konnte jeder einiges mitnehmen jetzt gerade.
Speaker: Und wenn ich dir dabei behilflich sein kann, dann kannst du dich gerne bei mir melden. Dann können wir darüber reden und ich kann schauen, wie ich dir helfen kann. Wie gesagt, mein Buchtipp an der Stelle noch ist das Innovators Dilemma von Clayton Christensen. Ein wirklich grandioses Buch um mal so, ja, also ich habe das Buch gelesen und dachte mir so,
Speaker: Verdammt, ich stehe mir bei vielen Sachen selbst im Weg. Es gibt so viele Dinge, die man einfach sehr kompliziert löst. Und vor allem, das fand ich in dem Buch wirklich sehr, sehr klasse, hatte ich das Gefühl, dass das ...
Speaker: dass wir viele Dinge einfach zu kompliziert sehen oder dass uns bestimmte Sachen, die wir uns irgendwann mal gebaut haben in unseren Websites, ja einfach massiv an unsere eigenen Innovationen behindern, weil wir einfach keine Möglichkeit haben, an Dinge ranzukommen oder wir irgendwann nur noch eben Lösungen bauen, um gewisse Dinge zu umgehen oder irgendwie zu
Speaker: zu verschlimmbessern. Deswegen finde ich es einfach wichtig, dass man sich da Gedanken zu macht, wie man so eine Website technisch aufbaut, wie man da eben rankommt und wie man die eben auch so aufbaut, um nicht irgendwann der eigenen Arbeiten noch hinterher zu laufen und niemals mehr in den Genuss von Innovationen kommen kann, weil man eigentlich so viel mit seiner eigenen Website zu tun hat.
Speaker: dass man gar nicht mehr Zeit investieren kann, die eigenen Dinge besser zu machen und mehr an den Nutzer auch zu koppeln, um wirklich zu überlegen, was hilft hier eigentlich mehr? Oder was macht die Bedienung meiner Website besser? Ich glaube, die Zeiten waren nie besser als heute, wo man die Möglichkeiten hat, wo auch soziale Netzwerke, ich sag jetzt nicht immer mehr, erabflachen. Aber ich glaube, im Moment ist so eine Zeit, wo ich das Gefühl habe, dass da draußen so ein gewisser Umbruch stattfindet.
Speaker: Ich will nicht sagen, die Foren haben irgendwann wieder eine Chance, aber ein Stück weit glaube ich das. Nicht heute und nicht morgen, aber warten wir mal ein, zwei Jahre ab. Deswegen haltet die Augen offen, macht eure Seiten besser und wir hören uns nächste Woche Donnerstag wieder um 20 Uhr zum 404 Podcast mit André Goldmann. Ich wünsche Ihnen eine schöne Zeit und wenn dir der Podcast gefallen hat,
Speaker: dann abonnier ihn doch, wenn du es noch nicht getan hast, gib mir dann Feedback, gerne auch auf Facebook singen, können uns auch gerne da vernetzen miteinander und wenn ich dir irgendwie helfen kann, melde dich einfach bei mir. Bis nächsten Donnerstag, 20 Uhr, mach's gut, ciao!
