Also hallo, hallo, hallo. Äh, herzlich willkommen zu unserem Gespräch. Wie gesagt, ich heiße Alena, ich bin Partner Success Managerin bei Storyblock. Heute spreche ich mit Dominik, Gründer und CEO von Storyblock, über die neuen und interessanten Trends, ähm, die für meine Partner wichtig sind. Und meine Partner sind hauptsächlich digitale Agenturen. Ja. So, hallo Dominik, wie geht's dir? Hi, mir geht's fantastisch. Also gestern schon das, ähm, kurze Intro mit Mario gehabt und jetzt hier mit dir ist natürlich ganz toll. Toll. Ähm, ja, mir auch gut. Ähm, und ich finde die Konferenz, also gestern und heute sehr spannend. Ähm, Thomas, Maria und Sebastian haben gestern schon viel über die Headless-Architektur gesprochen und gezeigt, aber für mich, ähm, selbst ist das nicht nur die Augen von Marketingleuten oder Kunden interessant, sondern mehr durch die Augen von Entwickler oder Agenturen. Und, ja, apropos Trends, hier bei Storyblock arbeiten wir alle einhundert Prozent von zu Hause. Und obwohl wir beide in Österreich wohnen, etwa aus drei Stunden entfernt oder so, haben wir uns noch nie offline gesehen. Ja, aber das, das funktioniert. Also wir haben diese Kultur von Online-Coffee-Chats, nicht genau, ähm, Fireplace-Chats, sondern Coffee-Chats, die von einem Slackbot-Donut zufällig ausgewählt werden und so haben wir diese Water-cooler-Gespräche miteinander. So etwas machen wir jetzt zum Beispiel. Genau. Dominik, du hast seit Jahren bei einer Agentur als Entwickler gearbeitet, Projekte für Kunden gemacht. Wie bist du auf diese Idee gekommen, ein eigenes Tool zu bauen? Gab es (lacht leise) nicht, ähm, nicht schon genug Content-Management-Systeme in der Welt? Und Vorsicht, es geht nicht wirklich über Storyblock oder ............................ Ich versuche nur zu verstehen, also warum ein Mann von einer Agentur, der schon die, die alle Hände voll zu tun hat, ja, einen solchen Schritt machen sollte. Ja. Ähm, da, das ist tatsächlich eine gute Frage. Also, es gibt natürlich schon sehr, sehr, sehr, sehr viele Content-Management-Systeme da draußen. Also definitiv. Ähm, das Thema für uns war damals, 2015, einfach, dass, auch wenn's ganz, ganz viele Content-Management-Systeme gibt, ähm, dass es, ähm, einfach keins gab, das unsere Kunden irgendwie zufriedengestellt hat. Ähm, muss man wissen, ich habe jetzt nicht nur in einer Agentur gearbeitet, sondern seit ich, ähm, fünfzehn bin, also in den letzten, ähm, ja, doch schon zwölf Jahren. Das ist eigentlich ziemlich lange Zeit, wenn ich so drüber nachdenke. Zwölf Jahre habe ich für verschiedene Companies als Consultant, als Webentwickler und Ähnliches gearbeitet und das jetzt nicht nur in Österreich, sondern auch in Niederlande, Deutschland, Schweiz. Und es war immer wieder dasselbe Problem. Entweder sie kaufen, also die Firmen kaufen große Suits ein, also wirklich große Adobe, ähm, Libraries oder große Sitecore, ähm, Live, ähm, Array-Installationen und sind dann mega unhappy, weil sie ganz vieles verbiegen und, und brechen müssen, damit er irgendwie ein System dabei rauskommt, mit denen die Marketer arbeiten konnten. Mhm. Und so ging's uns eigentlich auch in der Agentur, in der Alexander und ich dann, ähm, eben 2000-- -15 war das -- -15 gestartet hatten. 2015 haben wir eben das Thema gehabt, dass unser damaliges Enterprise-Kontom-Managementsystem gesagt hat, „Hey, nur noch Bugfixing und keine neuen Features mehr. In sechs Monaten schalten wir das ganze Ding quasi ab." Und, ähm, das war für uns der, der Punkt, wo wir gesagt haben, gut, wir schauen mal, was ist da draußen? Was, was können wir verwenden? Und, ähm, das war dann auch für uns Startschuss, was zu finden, was für uns als Agentur passt. Und, ähm, spannenderweise haben wir dann tatsächlich nichts gefunden. Ähm, wir haben lang geschaut, wir haben uns eben noch mal doofe SiteCore Live ray anguckt. Wir haben, ähm, WordPress, Drupal, Typo3 noch mal genauer irgendwie versucht zu betrachten, ähm, aber da gab's einfach irgendwie nichts. Ähm, und, ähm, wir sind dann so weit gegangen, dass wir gesagt haben, wir haben tatsächlich das Ziel, kein CMS zu bauen. Also das war 2016 und, ähm, in dem Jahr hat dann Alex irgendwie einen Prototypen gestartet, der irgendwie versucht, so ein Gefühl von, ähm, PageBuilder, aber auch nicht wirklich, ähm, mit, ähm, dem Headless-Gedanken, mit dem komplett einen API-Base, also rein Daten getrieben, ein CMS irgendwie zu vereinen und hat dann einen coolen Ansatz gehabt mit diesen Komponenten. Man kann sich's vorstellen wie so Legoblocks. Ich sehe Lego im Hintergrund, aber ungefähr so kann man sich's quasi vorstellen. Ähm, und aus diesen einzelnen Bausteinen, aus diesen Blöcken, die sich dann quasi ein Entwickler einmal, ähm, aufbaut, kann dann Marketer wählen und sich selbstständig, ähm, eben dann eigene Blöcke und Pages zusammenbauen. Und das hat eigentlich ganz gut geklappt, ähm, und uns in der Agentur tatsächlich sechzig Prozent, ähm, Revenue gespart, also in Umsetzungszeit angesperrt. Ja, ich fand's gut. (lacht) Okay. (lacht) Ja, das ist viel. Ähm, also, zum Beispiel, wie lange dauerte es von Anfang an bis zum ersten Prototyp, der benutzt wurde? Ähm, also, Ende 2015 hat Alex irgendwie gemeint, er hatte so 'ne Idee, ähm, hat dann irgendwie im Jänner, Februar 2016 mit dem Prototypen gestartet, äh, damals noch mit 'nem ganz, ganz lustigen Würfel als Logo. Äh, und eineinhalb Monate später haben wir Silhouette und Adidas gefragt, ob die das mal probieren wollen. Beide meinten: "Hey, das ist ziemlich cool." Ähm, und dementsprechend haben sie's dann beide verwendet und ein halbes Jahr später haben wir dann eben einiges an Features dazu gebaut. Das heißt, ein Image-Service zum. Ah Bilder optimieren automatisiert, Facial Detection, damit die Gesichter nicht abgeschnitten werden. Also man kann sich vorstellen, wenn man jetzt irgendwie so wie sie jetzt Brillen verkauft, dann möchte man ungern, dass die Gesichter der Models mit den Brillen auf dem Produkt, den sie haben, irgendwie abgeschnitten wird. Und dementsprechend haben wir da ein Service gebaut, das quasi direkt mit Storyblock jetzt integriert. Haben dann auch einen Namen gefunden, Storyblock, Storytelling mit Blöcken. Deswegen, deswegen. Wir haben kein c im Namen, richtig. Also das Storyblock ohne c. Und der Grund dafür ist, die Domain war schon vergeben. Wir waren da relativ einfältig und dachten uns ja, so schlimm wird schon nicht werden. Und dann irgendwie versucht, ein Jahr lang Google beizubringen, dass wir kein Rechtschreibfehler sind. Haben es dann geschafft, aber genau, so hat das Ganze gestartet. Ich glaub, eineinhalb Monate waren es circa, zwei Monate vielleicht nach dem ersten. Ich glaube, das ist ziemlich schnell. Also wenn nur zwei Leute das so bauen, das ist ja-- Aber also zurück zu Trends. Also das war dieser You know headless Trend, ja? Ahhhm Vielleicht neu gestartet zweitausend und sechzehn oder so. Und wie genau kann die Headless Architektur die Effizienz bei einer Agentur verbessern? Ja, gibt einen bestimmten Projekttyp, zum Beispiel E-Commerce, bei dem das sinnvoll ist, oder? Also bei uns war es so, ich schildere vielleicht mal ein bisschen, wie unser Projektaufbau mehr oder weniger jedes Mal war. Am Anfang war immer die Konzeption, wo man quasi überlegt hat, was ist eigentlich das Ziel davon, wenn jetzt der Kunde mit einer Idee kommt, mit "Ich will eine App bauen" und eigentlich braucht er eine Webapp oder eine Webseite an sich oder ein E-Commerce Store, dann muss das zuerst herausgefunden werden. Danach wurde ein Design gemacht, von was auch immer da gebaut worden ist. Lass sagen, in dem Beispiel, wenn ihm jetzt eine Corporate Website, dann wurde dafür ein Design gemacht. Dieses Design wurde dann unserer Frontends Team gegeben und das Frontends Team hat damals dann Templates gebaut mit der Template Engine, also relativ rudimentär mit HTML, JavaScript, CSS und das Ganze eventuell noch mit irgendeiner Template Engine, die ähnlich ist zu dem jetzigen verwendeten in View, Next und ähnlichem. Und dann war so der Punkt, okay, jetzt haben wir diese Implementierung abgeschlossen, das Templates passen, wurden abgenommen, die einzelnen Komponenten passen und jetzt muss das ins CMS pflegbar gemacht werden. Also das war damals immer so der Begriff, wir müssen das Ganze jetzt pflegbar machen, dass ein Marketer aus einer Kundensicht quasi dann selbstständig neue Seiten erstellen kann von einem gewissen Typ und, ahhh, das selbständig quasi bearbeiten kann. Und dann kam eben die CMS Entwicklung. Dafür haben wir dann eben Backend Entwickler gehabt oder CMS Entwickler tatsächlich, also gesondert geschulte CMS Leute, die genau dieses CMS konnten und haben angefangen, dieses eigentliche, schon fertige Templates dann zu zerschneiden, mehr oder weniger, also wirklich auseinander zu nehmen und ins CMS zu überführen. Und irgendwann war so der Punkt, dass es eigentlich voll traurig war, dass der Frontend Code an sich zwar weiterhin existiert hat, aber eben in diesen einzelnen Stücken irgendwie zerteilt wurde und eigentlich nichts mehr mit dem ursprünglichen HTML zu tun hatte, weil eben, ja für Wordpress muss man das einfügen, bei Typo3 wäre die Änderung besser und dann wurde es mit irgendeiner Programmiersprache gemischt, das heißt PHP, Perl oder ähnliches. Und das fanden wir halt nicht, nicht so praktisch. Dementsprechend ein Headless CMS System gibt dir die Möglichkeit, diese bereits existierenden Templates, die meistens in dem Frontend entwickelt werden, einfach relativ schnell mit Daten anzureichern. Also anstelle von dem, das jetzt ein Frontend Team die Templates fertig baut mit einer Template Engine und dann wird es übergeben und zerteilt, ist ein Frontend Entwickler bereits so weit, dass er sagt, er baut die einzelnen Komponenten mit den einzelnen Content Typen, sage ich mal. Und anstelle das dann zu zerlegen und irgendwo reinzuwerfen und wirklich dort zu warten, lädt man einfach von einem anderen System, von einem datenbasierten System, die Struktur, seien es der Aufbau der Seite und die Inhalte. Was soll in der Headline drinstehen? Was ist das für ein Bild, das sich anzeigen soll und lad es direkt in das Frontend rein. Also in diese, in HTML, CSS, JavaScript plus der Template Engine und dann war's das. Und bei uns war es immer so, zehn, fünfzehn Prozent Projektleitung plus, ich sag mal, irgendwie Konzeption. Dann haben wir zwanzig Prozent Design und der Rest war eigentlich Entwicklung vom Aufwand her. Und die Entwicklung und hat sich auch unterteilt zwischen fünfundzwanzig, dreißig Prozent Frontend Entwicklung plus Business Logic und der Rest war rein nur CMS Entwicklung und das ist schon traurig. Und wenn man sagt, man spart sich auf einmal die komplett CMS Entwicklung, weil es nur Daten laden ist, dann ist natürlich ein enormer Mehrwert für die Agentur selbst da. Also ja, Agenturen würden davon, haben davon einen Benefit. Es ist halt die Frage, haben sie es beim ersten Mal? Vielleicht nicht, weil sie erstmal den ganzen Prozess abändern müssen. Beim ersten Mal müssen sie sich daran gewöhnen, aber spätestens nach dem zweiten, dritten, vierten Projekt ist es so, dass sie definitiv eine Umsatzsteigerung haben, alleine dadurch, dass die Profitmargen einfach nach oben gehen im einzelnen Projekt. Verstehe. So, die Agentur kann also sicher Zeit sparen, auch Ressourcen sparen. Aber vielleicht für das erste Projekt braucht man ein bisschen Onboarding oder so, ja. Genau. Du musst dir vorstellen, die müssen quasi am Anfang mal ein bisschen Boilerplate, so haben wir das genannt, aufbauen. Wie strukturieren sie jetzt die Daten, die einzelnen Komponenten. Aber sobald sie ein zweites, drittes, viertes Projekt umsetzen, können sie einfach genau diese Komponenten an sich jetzt nicht designmäßig, sondern rein von der Datenstruktur nehmen, duplizieren und auch in dem System, im Storyblock geht es zumindest. Man kann einfach ein komplettes Projekt duplizieren und das als Starting Point nehmen und dann eben customizen zu den Punkten, wo man es braucht. Und das ist eigentlich das Schöne dabei. Man baut sich selbst so ein Stack auf, so ein eigenes Projekt Setup, damit man nicht jedes Mal von null starten muss. Das ist eigentlich ganz nett. Ja, ja, das ist wirklich, äh, glaube sehr toll. Und dann, ah, auch meine nächste Frage. Als als Storyblock bekannt gab, dass wir jetzt Mitglied der Mach Alliance sind, haben wir interessante neue Partner gewonnen und ich hab das schon selbst gesehen. So nach etwa einer Woche oder so kam eine Agentur mit einem Projekt auf Enterprise Ebene zu uns und sagte, dass sie selbst auf die Machstrategie umsteigen will und deshalb für das Projekt ausgewählt haben. Und für mich, das war okay, wow, das ging ja schnell. Ähm, und aber ich verstehe nicht genau, warum. Also was ist mit machlos? Mhm. Also das Spannende früher war halt, man hat sich ein System gekauft, eine große Suite und hat dann gehofft, das passt. Also da ist 'n E-Commerce drin, da waren CMS, da war eine Suche drin, ein Digital Asset Management System, also 'n komplettes DXP System. Also Digital Experience Platform heißt das quasi auf auf Englisch mehr oder weniger. Und die Überlegung dahinter war, man kauft sich eine Suit und das löst alle meine Probleme. Und dann wurd halt 'n Rechtteam mit aufgesetzt, das hat meinstens relativ lange gedauert. Und dann wurden davon vielleicht noch 'n paar Sachen jetzt nicht verwendet und 'n paar Sachen wurden angepasst und dann ist man halt mal mit der Lösung reingegangen. Das klappt ganz gut, wenn man jetzt irgendwie keine wirklich besonderen Unterscheidungsmerkmale haben möchte. Es gibt natürlich dann Themes und ähnliche Erweiterungen, die man dazu hängen kann. Aber irgendwann hat das dann Limitierungen, wo man anfängt, selbstständig Lösungen dazu zu bauen und zu verstricken mit dem Altsystem. Und wenn auch immer diese Suite oder diese Monolithen, also alte Systeme quasi 'n Update haben, muss ich auch meine eigenen Integrationen updaten, was natürlich zu mehr Aufwand in in der Wartung führt. Und dieser komplette Machansatz bedeutet nichts anderes als ey, wir unterteilen die Responsibilities, also die wirklichen Punkte oder Bereiche, wo jemand zuständig dafür ist, in einzelnen Produkte und einzelnen, ich sag mal, ja, Produkte, ja, Services, die man dazu kauft, Microservices, APIs, wie auch immer man das dann nennen möchte. Und Storypock kann eines davon sein, deswegen sind wir jetzt auch eben Macheline als Partner. Man kann sich zum Beispiel sagen, hey, Shopify, Algolia und Storypock nehme ich jetzt her, um einen Store zu bauen. Shopify für den Checkout und die Produktdaten und den Produktcheckoutpreise und Ähnliches. Storytelling übernimmt dann Storyblock quasi mit den Komponenten, die gebaut werden können. Und wenn ich dann noch eine ordentliche Produktsuche da haben möchte, kann ich Algoide dazu hängen. Da möchte ich vielleicht noch Personalisation, nämlich optimise LEZU und so weiter und so fort. Und man kann sich quasi dieses Best of Breed Gedanken quasi zusammenfügen. Man sucht sich aus, was man braucht und das Schöne ist, wenn man dann irgendwann mal merkt, hey, ich sag mal, Shopify passt jetzt nicht für meine Vorhaben im im E-Commerce Bereich, dann brauch ich jetzt nicht alles austauschen, sondern kann tatsächlich einfach sagen, ich tausch jetzt nur Shopify aus mit Commercetools, mit Big Commerce. Dasselbe ist auch mit Storyblock. Wenn man jetzt sagt, hey, diese CMS von uns ist jetzt nicht ideal, ich möcht lieber zurück auf WordPress, warum auch immer, dann kann ich das machen, weil ich einfach genau diese Struktur einfach sag, ich cut das jetzt einfach auseinander und nehm was anderes rein. Und einfach diese Wartbarkeit und Flexibilität über Zeit ist eigentlich das Spannende an der Mach Alliance. Okay, das ist wirklich genau, auch Zeit geht, auch vielleicht Investitionssicherheit. Das ist genau unsere Frage im Chat. Mhm. Also ich ich lese das vor. Was könnt ihr zum Thema Investitionssicherheit sagen, könnten aufgrund der Unternehmensgröße die Frage stellen, ob der Softwareeinsatz langfristig sein ist, also ob es auch sicher ist, ja. Ja klar, also ich glaub, das das ist immer eine sehr große Frage auch bei uns in Pitches, weil wir sind mittlerweile hundertvier Leute, haben den Plan, dass wir dreihundertdreißig Leute wachsen in diesem Jahr. Dementsprechend, für uns jetzt das Unternehmensgröße ist das, denke ich, ganz okay für das, dass wir 'n Softwareprodukt wie 'n CMS bauen. Und das Spannende ist tatsächlich gar nicht so sehr die Unternehmensgröße, sondern wie stark automatisierbar ist das Problem, das die Firma löst. Wenn ich jetzt sage, ich hab 'n Livechat, wie zum Beispiel wir selbst nutzen Chrismal, Chris wird von 'nem Team gebaut, das, ich glaub, unter fünfzehn Leuten sind. Die betreuen aber knapp hunderttausend, hundertfünfzigtausend Kunden. Na, wie machen die das? Na ja, die haben halt ganz wenig Supportaufwand, weil das 'n Livechat Widget ist. 'N CMS braucht natürlich jetzt wesentlich mehr Leute im Produkt, deswegen haben wir auch vierzig Leute im Produktteam. Das rein und sich darum kümmern, dass eben alles glatt läuft, dass wir die Prozesse, die wir haben, automatisiert bekommen und neue Features bauen. Deswegen können wir auch eine V zwei liefern. Und ich glaub, das muss man sich schon anschauen. Wenn man jetzt irgendwie CMS vergleicht oder generell Software vergleicht, die 'n Core Bereich abdeckt, sei es jetzt 'n Content Bereich oder 'n E-Commerce Bereich oder auch in der Suche selbst, also wenn man jetzt wirklich Produktsuche ähnliches bauen möchte im E-Commerce Bereich. Für kleinere zusätzliche Tools, die Sachen erleichtern, Automatisierungstools, Live Chats und ähnliches, da kann man auch mal gern auf, ich sag mal, kleinere Player gehen, weil man's eben relativ schnell austauschen kann. Und das ist auch der Vorteil der Macherlines. Wenn man sagt, hey, man hat jetzt hier irgendwie daneben gegriffen mit einem Tool, erlaubt es diese Headless Architektur oder diese Servicearchitektur, einfach Taten auszutauschen und das System auszutauschen. Ich mein, klar, es ist 'n Aufwand verbunden damit, aber es heißt jetzt nicht, ich fang wieder von null an, sondern ich fang vielleicht damit an, dass ich das TMS noch integriere, das E-Commerce-System umstelle und so weiter und so fort. Aber da hat man auf jeden Fall 'n Riesenvorteil. Danke für die Frage. Ja, eine sehr tolle Frage und ja, falls es gibt mehr Fragen, dass wir wir freuen uns, so mehr darüber zu sprechen, so einfach im Chat fragen. Ich habe auch nächste Frage über einen anderen Trend. Also seit, ich glaube, schon ein paar Monaten höre ich viel über das Mataverse. Ist das nur ein Marketing Trick, wie ich glaube, aber nicht wie, was glaubst Du? Ähm, das ist eine sehr gute Frage. Also tatsächlich glaube ich, dass eher VR, was quasi die Bausteine für dieses Metaverse sein werden, immer stärker werden. Ähm, man merkt am, am Smartphone, an den Devices, jetzt mittlerweile nicht mehr wegzudenken. Vor fünfzehn Jahren, vor zwanzig Jahren, wenn da irgendwer gesagt hätte, ich laufe immer mit meinem PC rum, was ja eigentlich mehr oder weniger ein ziemlich leistungsstarker Rechner ist, äh, hätte dich jeder angeguckt und gesagt: Warum willst du fünfzehn, zwanzig Kilo mit dir rumschleppen? Das macht doch keinen Sinn. Äh, und ich glaube, ungefähr so wird es auch werden, sobald die Geräte, äh, sich in den Alltag integrieren lassen, äh, und das Ganze, ähm, tatsächlich einfach nicht mehr spürbar ist, dass es da ist, äh, dann wird es richtig spannend. Und, äh, da können Unternehmen jetzt schon einiges machen. Sie können versuchen, eben die Daten, die sie haben, die Inhalte, die sie haben, so aufzubereiten, dass sie auch von anderen Systemen abgreifbar sind. Ähm, ich spreche natürlich jetzt auch ein bisschen aus der eigenen Tasche, weil Storyblock ist ein Headless System. Man kann die Daten überall verwenden, aber wenn man auch jetzt auf andere Systeme achtet, zum Beispiel das E-Commerce System soll API basiert sein, die Suche soll API basiert sein. Wenn ich jetzt ein Digital Asset Management System hernehme, Binder und ähnliches, die bieten auch APIs an, äh, und das alles erlaubt einem auf langer Sicht, äh, dann genau diese Plattformen, eher wie auch und wie auch immer, die sich dann in den Alltag integrieren, ähm, auch wirklich anzusteuern. Und da kann man jetzt schon die ersten Schritte in die Richtung machen. Ich glaub, dass das noch ein bisschen dauern wird. Also wir reden da von, von Metaverse, weil natürlich jetzt Facebook jetzt zu Meta geht, jetzt vom Naming her und jetzt Avatare rumfliegen lässt und ähnliches. Das dauert noch, bis das da irgendwie eine Realität daraus wird. Aber, ähm, man sieht es am Smartphone, das geht viel, viel schneller als man denkt und dann übernimmt das einen richtig, richtig großen Part. Ähm, dementsprechend, ähm, würde ich jetzt schon mal drauf setzen. Wir selbst machen es. Unsere Inhalte sind jetzt so getrennt, dass wir es jederzeit auf jeder Plattform rausspielen können. Also für unsere eigenen Marketingkampagnen. Äh, das heißt, wenn wir da irgendwie, ähm, ein gutes Beispiel, glaube ich, ist, ist tatsächlich Gaming. Ähm, wer hätte gedacht, dass es in zwanzig einundzwanzig virtuelle Konzerte in einem Online Game geben soll? Richtig, genau. Also in, in Fortnite, das ist ein ziemlich bekanntes Spiel unter, äh, den, den Jungs und Mädels heutzutage. Die, die haben einfach ein Konzert, äh, dort gehabt. Das muss man sich mal vorstellen. Das hätte es vor zwanzig Jahren einfach nicht gegeben. Und genauso wird es auch sein, dass man sagt: „Hey, vielleicht gibt es da irgendwann mal, ähm, Werbeflächen, die man bespielen kann." Ähm, ich meine, das kann jetzt ganz, ganz schlimm abdriften, dass man mit einer Brille durch die Stadt läuft und man hat überall Werbung, die reinfliegt. Aber es kann natürlich auch positiv sein, wenn man jetzt durch einen Laden durchgeht und man schaut sich ein Produkt genauer an und möchte wissen, wie viel kostet das? Wurde das nachhaltig produziert? Dann kann ich einfach draufsehen und ich bekomme vielleicht über einen QR-Code oder über einen Barcode, der sowieso drauf ist auf dem Produkt, mehr Zusatzinformationen, die im Headless CMS gespeichert sind. Und ich glaube, das ist eben das Spannende. Man weiß noch nicht hundertprozentig, wo die Ansatzpunkte sind oder wo die Punkte sind, wo es dann zur Anwendung kommt, aber es wird genau in die Richtung gehen. Das ist nicht jetzt etwas, ähm, darüber wir können nur reden und etwas also vielleicht, also, denken, aber vielleicht in, äh, nächstes Jahr oder in ein paar Jahren, es, es wird, es werden also Kunden sein, Budgets, ja, für das, etwas auch für digitale Agenturen, das alles zusammenzubauen, so etwas mehr praktisch, ja. Ja, definitiv. Also, ähm, ich bin ja mal gespannt, wann es so weit ist, wenn die ersten Modelabels hergehen und, äh, vielleicht sich mit der Brille integrieren lassen, dass du durch eine Stadt durchgehst und du siehst, hey, das T-Shirt, das die Person anhat oder die Jacke, die die Person anhat, sieht richtig gut aus und, äh, man geht vorbei, sieht sich das an, macht kurz ein Foto oder ähnliches, ähm, und braucht dann nicht selber irgendwie suchen, sondern während man das Foto macht, weiß man schon, okay, das könnte ich jetzt bei Marco Polo kaufen. Das ist jetzt, ähm, ein T-Shirt oder eine Socke von Happy Socks oder ähnliches, was natürlich recht spannend wäre. Okay, ja, spannend. Ähm, ich sehe, dass wir keine mehr Fragen im Chat haben, aber, also herzlich willkommen, bitte stellen Sie die. Und ich habe ein zusätzliche, eine zusätzliche Frage. Und so, ähm, okay, du hast also jahrelang in einer Agentur gearbeitet und du bist jetzt auch jahrelang der Gründer und CEO eines Softwareanbieters, ja? Siehst du Kundenprojekte jetzt anders? Wie hat sich dein, ähm, Blickwinkel geändert? Oder vielleicht gar nicht, oder? Ja, also, äh, der hat sich definitiv ein bisschen geändert. Ähm, früher, ähm, also, ich hatte jetzt mehrere Positionen. Also ich Consultant war und Webentwickler für, für andere Companies, war es auch so, dass ich mal in der Kundensituation war, wo ich von der Agentur quasi was angeliefert bekommen habe, das überprüfen musste und ähnliches. Äh, dann zurück in, in, in die Agentur an sich, quasi zu sagen: „Hey, wir setzen das Ganze um." Dort natürlich von Projekt zu Projekt an die Arbeit aufgebaut, was natürlich wieder anders ist. Und jetzt als Produkthersteller und, und, und auch, ähm, ich sag mal, Software as a Service im ganzen Detail, ähm, Anbieter, haben wir den Vorteil, dass wir auf Subscriptions gehen. Das heißt, wir haben an sich jetzt keine Professional Services, die wir selbst anbieten. Das heißt, wir bauen keine Webseiten, wir bauen keine, ähm, ja, Shops oder ähnliches, sondern wir bieten Storyblog als System an, damit darauf gebaut werden kann. Und, äh, das Spannende ist, wir haben jetzt Agenturpartner, die uns natürlich immer wieder mit Projektfragen fragen. Das ist auch kein Problem. Dafür sind wir da. Dafür haben wir ein Partnerteam, wo jetzt, Elena, du natürlich auch dazu gehörst. Du bist ja eh täglich, jeden Tag dabei. Ähm, und dahingehend hat sich relativ wenig geändert. Ähm, meine Sicht auf Projekte ist halt so oder auf, auf-- Projekte, die wir machen sollen oder wo jemand zu uns kommt, hey, macht ihr bitte mal die Umsetzung davon, ähm, dann würde ich halt immer sagen: „Nein, aber wir haben einen Partner für dich. Ja. Das liegt einfach daran, dass wir das gar nicht machen könnten. Unser Fokus ist darauf, dass Produkt passt. Produkt muss online sein, muss verfügbar sein, muss stabil sein. Ähm, wir müssen neue Features bauen, müssen Security-Tests im Hintergrund machen, Zertifizierungen wie ISO 27001 und Ähnliches. Und das ist das, was wir jeden Tag machen. Wir schauen, dass das Produkt, das wir haben, besser wird, äh, neue Challenges, ähm, ähm, von unseren Kunden getackelt werden durch unser System, äh, und wir da bereit sind. Aber wir sind jetzt nicht diejenigen, die die Umsetzungen machen. Bekommen aber zum Glück jetzt eben genau dieses Feedback, das wir selbst früher hatten, warum wir das Projekt gestartet hatten, äh, von den Partnern, die wir haben. Und mittlerweile sind wir bei, äh, über achthundert registrierte Partner von Storyblock weltweit und davon sind jetzt, ich glaub, achtundvierzig, neunundvierzig zertifiziert von uns sogar irgendso in der Richtung und das ist eigentlich schon ganz spannend. Definitiv. Wir haben eine, ähm, neue Frage. Ich lese es vor. Kann Storyblock mit Thema-CMS verglichen werden? Äh, was sind die Vorteile von Storyblock? Kann Storyblock in einer punkt net, ähm, Umgebung benutzt werden? Bietet es ein Live Editor? Ja. Ähm, wie customizable ist das? Ja, klar. Danke für die Frage, Maja. Also, äh, ja, kann verglichen werden. Ähm, richtig großer Unterschied, äh, der Thema CMS ist vom, ähm, Forestry, äh, abgegangen quasi. Das ist so ein neuer Ansatz von denen, der auf React basiert. Ah, das heißt, da bist du technologiegebunden und du musst React-Komponenten bauen. Ähm, jetzt ist es natürlich so, React läuft ganz gut als Open-Source-Projekt. Wir verwenden es tatsächlich auch für manche Sachen, die wir selbst bauen, äh, aber, ähm, du bist halt trotzdem auch eine Technologie gebunden. Und es gab ja auch schon Themen in die Richtung von Licensing Topics mit Facebook und React und Ähnliches. Das ist für mich persönlich immer ein Risiko, wenn wir etwas bauen. Äh, dementsprechend haben wir mit StoryBlock, ähm, bevor Themas CMS auch irgendwie unterwegs war, geschaut, dass wir das nicht machen. Wir haben jetzt nicht gesagt, du kannst StoryBlock nur mit, äh, Few Chairs verwenden, du kannst es nur mit PHP verwenden. StoryBlock ist komplett technologieabhängig und mit dot net kannst du es genauso verwenden. Es gibt sogar Open Source SDKs von jemandem in der Community, der das für dot net gebaut hat, ah, die dafür verwendbar sind. Das heißt, unsere APIs stellen dann quasi Datenstrukturen für dich zur Verfügung, wo, ähm, zum Beispiel eine Seite dargestellt wird mit einzelnen JSON-Objekten für jeden Block und dann kann der dort verwendet werden. Und, ähm, zum Thema Customizability und Live Editor. Ja, wir haben 'nen Live Editor. Das ist tatsächlich einer unserer größten Unterschiede zu den anderen Headless CMS-Anbietern. Wir bieten die Möglichkeit, dass du deine eigene Umsetzung bei uns integrierst und, ähm, wir machen's dann mit 'ner kleinen Javascript Bridge, die nur in dieser Live Preview quasi aktiv ist, ähm, möglich, dass Marketer draufklicken können, also Content Creator können dann auf einzelne Blöcke klicken. Wir öffnen dann den richtigen Inhalt dafür, damit der gleich bearbeitbar ist. Äh, und all diese Blöcke kannst du komplett customizen, wirklich so, wie du es möchtest. Ähm, es gibt verschiedenste Field Types und, äh, selbst die Field Types kannst du customizen mit JavaScript. Das heißt, auch die Darstellung innerhalb vom Storyblock selbst, also vom CMS selbst, obwohl wir im Software-as-a-service-Business sind, hast du selbst in deiner Kontrolle. Und das Spannende daran ist, ähm, grad dot net ist oft im Enterprise-Umfeld unterwegs und, ähm, wird oft verwendet, ähm, im Zusammenhang mit irgendwelchen Oracle-Systemen beziehungsweise Systemen, die gerade mit internen, ähm, Daten zu tun hat. Äh, wenn da zum Beispiel eine Integration mit einem Custom Field Type stattfindet, um interne Daten abzuholen, ähm, kann das auch in Storybook gebaut werden, ähm, weil genau diese Darstellungsart im Custom Field Type, also dort, wo Content erarbeitet wird, frei zugänglich ist und dort Customizations betrieben werden können. Danke, danke, Dominik. Ähm, zusätzliche Frage: Gibt es konkrete Systemarchitektur-Anforderungen für die Nutzung von Storyblock? Mhm. Also, das Wichtigste ist, dass die Plattform oder die Architektur, die ihr verwendet, die Möglichkeit habt, Daten aus dem Internet zu laden in Form von JSON, äh, und diese zu verarbeiten. Ähm, ich würde empfehlen, dass dort 'ne Template Engine auch im Frontend im Einsatz ist. Ansonsten habt ihr da tatsächlich gar keine Limitierungen. Ähm, warum jetzt irgendeine Template Engine? Das macht's einfach leichter. Äh, warum JSON? Das ist die Datenstruktur, die wir rausspielen. Warum Internet? Wir sind eine Software-as-a-service. Ah, das heißt, wir haben eine zugängliche API, die read-only ist, äh, und eine Management-API, falls ihr noch Daten reinschreiben möchtet. Aber diese Read-only-API ist dann quasi direkt von uns gehostet und für euch zur Verfügung gestellt. Äh, und grundsätzlich wird's tatsächlich verschieden verwendet. Sei es jetzt, ähm, in 'ner kompletten Umsetzung von einer normalen Webseite als Hauptplattform. Äh, aber natürlich geht's genauso, dass es quasi zu 'nem bestehenden System für einzelne Bereiche hinzugefügt wird. Äh, das ist hier komplett offen. Also gibt's keine, ähm, ja Default-Architektur, weil Storyblock meistens n Teil, ähm, von 'nem Lösungsansatz ist, weil es gerade in der Architektur, die aktuell herrscht, ein Problem gibt. Es gibt 'n paar, ähm, Partner von uns, die extrem gut darin sind, 'ne Architektur für 'n komplettes System aufzubauen. Ähm, storyblock.com slash partners, da kann man sich dann auch relativ schnell 'n paar Partner suchen, die, die einem da helfen können. Und wenn's dazu einfach noch detailliertere Fragen gibt, vielleicht zu 'nem spezifischen Projekt, äh, gerne auch einfach bei uns kurz eine Mail an sales at storyblock dot com schreiben. Da sind ganz viele Jungs und Mädels, die richtig begeistert davon sind, wenn sich jemand meldet und Fragen zu uns hat. Ja, danke Dominik und danke mal viel für die Fragen. Ähm, ich glaube, das war für alle interessant. Und ja, ich glaube, das war's. Äh, wir sind am Ende und, ja, liebe Zuschauer, liebe Zuschauerinnen, ich bin hier auf die Konferenz bis quasi drei Uhr. Wenn Sie, ähm, reden wollen über Partnerprogramm oder so, chatten Sie mich einfach an. Super. Danke, Elena, für, für die Fragen. Danke an den Chat für die Fragen auch dort. Ah, und, ja, wenn's irgendwas gibt, gerne auf Twitter, LinkedIn und Ähnliches connecten. Äh, jederzeit für Fragen offen. Danke. Tschüss. Tschüss.
Automatisch erstellt & redaktionell aufbereitet — kann vereinzelt Fehler enthalten.
