So, Sebastian, wollen wir mal loslegen? Ja, eine Sekunde noch. Das ist immer super bei einem Live Demo, wenn man dann drauf kommt, dass man jetzt plötzlich auf das Projekt keinen Zugriff mehr hat, das man eigentlich zeigen wollte. Ui, (Lachen) also ihr seht schon, es ist live live. Es ist echt live live. (Lachen) Aber ihr lasst mich mal beginnen und ich werde in der Zwischenzeit schauen, wie ich wieder zurück zu, ähm, meinem Projekt komme. (Lachen) Also wenn du noch eine Minute brauchst, kann ich gerne noch warten, Sebastian. Ähm, ich habe wirklich gerade keinen Zugriff mehr auf den Space, den wir hier zeigen wollten. Ähm, soll ich mal kurz nachschauen? Schau du einmal kurz da, ob es noch, ob du den Space noch hast. Ruckack zwanzig zwanzig. Jo. Ja, ich bin drin. Okay. Lass mich kurz die... Sebastian, ich seh dich wirklich nicht mehr. Mhhhm Kleinen Moment. Das ist ja lustig. Also, wir erleben hier wirklich, ähm, it's a Live Demo. (Lachen) Danke für das Verständnis, Sebastian. Du solltest jetzt Zugriff haben. So, jetzt wieder zurück. Dankeschön. With that said. Ähm, (Lachen) wir haben, also die Energie beim, beim Sebastian ist da. Ich hoffe, bei euch allen da draußen ebenso. Ich lege einfach mal direkt los. Ähm, vielen Dank fürs Zuhören, fürs Reinschalten. Der eine oder andere hat vielleicht unsere erste Session, ähm, von Storyblock am Vormittag miterlebt. Auch an dieser Stelle noch mal herzliches Dank fürs Zuhören. Liebe Grüße, Maria. Ähm, das ist im Grunde, ähm, einerseits eine Fortsetzung, aber im Grunde auch, wenn ihr die erste Session nicht gesehen habt, ähm, ist das auch überhaupt kein Problem. Ähm, wir möchten euch heute kurz das Thema Headless CMS, Headless Content Management Systeme vorstellen und eben euch ein paar Einblicke geben, wie man wirklich für das eigene Business sehr, sehr spezifische, sehr customizable, ähm, sogenannte User Experiences am Ende des Tages schaffen kann, erstellen kann und wie eben ein Headless Content Management System wie eben Storyblock, ähm, da eingesetzt werden kann. Das heißt, das ist wirklich heute eine kleine Live Demo, ähm, wo wir euch, ähm, das CMS zeigen werden und ein paar Einstellungen. Und ja, wenn es da Fragen gibt, bitte einfach direkt in den Chat rein. Ähm, wir sind, wir werden am Ende auch eine kleine QA einplanen, ähm, aber gerne auch jederzeit zwischendurch. Wir verfolgen den Chat. Mein Name ist Thomas Piram und ich bin heute hier gemeinsam mit meinem Kollegen, den Sebastian Girlinger. Hallo. Wie ihr es am Dialekt bereits erkennen könnt, kommen wir beide aus Österreich. Storyblock an sich ist aber quasi eine hundert Prozent Remote Company. Wir sind mittlerweile über hundert Mitarbeitern in über dreißig Ländern und als Produkt, ähm, in hundertdrei, also in hundertdreißig Ländern plus aktiv. Ähm, vielleicht kurz als Einstieg, kurz das Thema CMS, Headless CMS, was ist das überhaupt? Was sind die Vorteile? Und dann springen wir gleich direkt in die Live Demo rein. Ähm, ja, und somit starten wir einfach mal los. Ich glaube, jeder von euch, der jetzt hier einschaltet, kennt vermutlich ein Content Management System und weiß so mehr oder weniger, was ein CMS am Ende des Tages so macht, aber dennoch vielleicht einfach ganz kurz erklärt. Ähm, ein Content Management System dient im Grunde zur Erstellung, Verwaltung und Veröffentlichung von digitalen Inhalten. Egal ob das Texte, Grafiken, Videos für die eigene Website sind. Ähm, mittlerweile haben wir nicht nur Websites im Einsatz, sondern viele andere Experiences vom Online Shop über Mobile Apps und so weiter im Einsatz. Also im Grunde ist ein CMS ein Content Management System. Das es ihm ermöglicht, den Inhalt zentral zu verwalten. Ähm, ein CMS bietet in der Regel eine einfach zu bedienende Benutzeroberfläche ohne, ähm, Programmierkenntnisse. Das heißt, auch Redakteure, Marketingpersonen können Inhalte verwalten, ändern, publizieren. Ähm, genau, und das ist quasi in der Regel an einem All-in-one, ähm, -Platz zusammengefasst. Das heißt, in der Regel kommt mit einem sogenannten traditionellen monolithischen System eben auch das Frontend mit. Das heißt, man kann darüber die Design Templates und ähnliches verwalten. Genau. Warum sprechen wir jetzt heute über, ähm, das Thema Headless Content Management System? Wenn man sich so den CMS-Markt ganz generell mal kurz ansieht, dann gibt es da unterschiedlichste Statistiken, Studien. Das ändert sich auch laufend. Viele CMS-Systeme, die man heute so kennt, wurden in den neunziger Jahren entwickelt. Ähm, damals gab es so den großen ersten Aufschwung. Man kennt sicher WordPress, Drupal und Co, so im Open-Source-Bereich und auch in vielen Branchen und Industries ist das dann sehr, sehr, ähm, spezifisch dann auch, was so genutzt wird. G2 zum Beispiel listet hier über dreihundert CMS-Anbieter im Web CMS-Markt und statista.de rechnet 2021 mit einer CMS-Marktgröße von über dreiundvierzig Milliarden US-Dollar. In Summe kann man sagen, der CMS-Markt ist riesig, sehr divers und eben sehr regional und branchenspezifisch. Ähm, unter einem Headless CMS, und das haben wir auch in der, in der vorhergehenden Session kurz erklärt. Das heißt, für alle Zuhörer, die dort bereits dabei waren, kurz als Wiederholung. Unter einem Headless CMS versteht man im Grunde, ähm, die Abkoppelung des Frontends, nämlich dem Kopf, vom Rest des Körpers, dem sogenannten Backend. Das klingt im ersten Moment etwas schräg. Also warum trennt man das Frontend vom Backend ab? Warum macht man diese Auftrennung? Ähm-Der Hintergrund ist der, dass ein Headless-CMS sich im ersten Schritt gar nicht mal darum kümmert, wo ihr gerne den Content publizieren möchtet. Also das heißt, ein Headless-CMS kümmert sich im ersten Schritt gar nicht, ob das jetzt ein Inhalt für die Website ist, für die Mobile App oder andere Ausgabe-Medien. Ähm, denn über sogenannte APIs, Schnittstellen, ist es eben möglich, diesen Inhalt auf diese diversen Kanäle zu pushen, unabhängig davon, wie eben ich als Redakteur, als Marketer, diesen Content im Backend verwalte. Das heißt, der große Vorteil eines Headless CMS, so als großen ersten Punkt, ist sicherlich die Fähigkeit, den Inhalt einmal verwalt-- oder nur einmal verwalten zu müssen, unabhängig davon, ob der jetzt mehrfach im diversen Frontends ausgespielt wird. Das ist mal so grundsätzlich das Konzept eines Headless CMS. Wenn wir jetzt quasi, ähm, das zusammenfassen, bedeutet das eben, Inhalte können, müssen nur einmal in einem zentralen CMS verwaltet werden und diese zentrale Verwaltung ermöglicht eben eine bessere Zusammenarbeit zwischen Redakteuren, Entwicklern und eben sämtlichen Teams und Personen, die quasi mit CMS, ähm, Themen zu tun haben und dadurch eben womöglich eine größere Flexibilität und eben ein schnelleres Time-to-Market. Wenn man sich den ganzen Headless, Headless-Trend quasi ansieht, dann sieht man das Thema so zum ersten Mal 2013, '14, ähm, aufpoppen. Es hat sich seitdem sehr viel getan. Es ist ein sehr wachsender Markt. Auch hier wiederum unterschiedlichste Studien und Statistiken dazu. Vielleicht nur ganz kurz: Gerade im E-Commerce-Bereich sehen wir grad sehr viel Bewegung in Richtung dieser headless Natur. Warum? Ähm, man sieht hier zum Beispiel, dass, ähm, gemäß dieser Umfrage sechsundsiebzig Prozent aller Unternehmen, die planen, neue E-Commerce-Technologien einzusetzen, das auf Basis von einer Headless-Architektur in den nächsten zwölf Monaten auch vorhaben. Ähm, zusammenfassend kann man eben, eben sagen, dass ein Headless CMS, ähm, das Thema Ladezeiten, Website-Performance sehr stark beeinflusst. Das Thema Omnichannel Publishing, das heißt, wie gesagt, im ersten Schritt kümmert sich ein Headless CMS gar nicht so sehr darum, ob das jetzt für eine Mobile App, eine Mobile Watch, Smartwatch oder eben die Website ist. Das Thema Personalisierung ist ein spannender Bereich. Da wird auch Sebastian dann gleich dazu etwas erzählen. Ebenso Themen SEO, großer, großer Punkt natürlich für Webseiten. Aber in Summe kann man sagen, einerseits viele Vorteile auch für Kundenexperiences, die User Experience im Frontend, aber auch, muss man am Ende des Tages sagen, ähm, vielleicht 'ne einfach zu bedienende Oberfläche für die Redakteure und Marketer. Zumindest ist das das Feedback, das wir so von Storyblock bekommen. Genau. Ähm, wir sehen das anhand von einigen Beispielen. Nur vielleicht ganz kurz ein, zwei Beispiele. UPC Business unternahm in den letzten Jahren eben auch die Migration zu einem Headless Content Management System und der große Output hier war am Ende des Tages schnellere Website-Ladezeiten, was wiederum sehr viel Geld bei Google Ads und Co. gespart hat, da eben Qualitätsfaktoren, zum Beispiel eben der Quality Factor von Google, ähm, auch die eigene Website-Performance sehr stark heranzieht. Das heißt, das ist ein, einer dieser Beispiele. Zweiter Punkt, auch vormittags erwähnt, Marco Polo, ein spannender Case, gerade im E-Commerce-Bereich, die eben sämtliche Länderwebseiten, sämtliche Lokalisierungsthemen mittlerweile über einen zentralen Headless Content Management Hub gelöst haben. Aber so weit, so gut. Sebastian, magst du direkt reinspringen in die Demo und unseren Zuhörern ein paar Einblicke geben, was wir so zum Thema Personalisierung und Co denken? Sehr gerne. Ich share jetzt meinen Screen. Das ist nicht Full, äh, Fullscreen, und zwar damit ich nämlich zwischen den verschiedenen, äh, Seiten hin und her springen kann. Äh, ich möchte euch heute gerne, äh, drei verschiedene Anwendungsszenarien, äh, im Headless-Umfeld zeigen. Äh, Dinge, die bei uns immer wieder, äh, gefragt werden: Ist das möglich mit Headless CMS? Wie mache ich das am besten mit Headless CMS? Und wir haben da ein paar Best Practices, die wir gerne, äh, herzeigen beziehungsweise die ihr auch gerne, äh, abgucken und, äh, selbst implementieren könnt. Das erste, äh, Thema ist oft, äh, ein Kontaktformular. Das klingt jetzt recht, äh, einfach und früher hat man eben das Kontaktformular, äh, über ein Plug-in in WordPress installiert und, äh, hatte dann auch gleich die ganzen Ergebnisse in WordPress und, äh, das war eigentlich relativ einfach out of the box. Man konnte es zusammenklicken und so weiter. In einem, äh, Headless-Szenario ist es leider nicht mehr ganz so einfach und man muss sich jetzt separat um das Frontend wie auch das Backend kümmern. Der große Vorteil bei dem Ganzen ist, ich kann mehrere verschiedene Frontends implementieren, die alle auf das gleiche Backend zugreifen und ich bin nicht mehr eingesperrt in einem Backend wie, äh, WordPress. Das heißt, ich brauche die Daten nicht, äh, in WordPress speichern und dann manuell in andere Systeme übertragen. Ich kann mittels API sofort, äh, die Verknüpfung mit, äh, neueren eigenen speziellen Systemen wie zum Beispiel Salesforce vornehmen. Storyblocks selbst, äh, die Kontaktformulare, die auf unserer Webseite sind, ähm, sind so implementiert, äh, dass eben das ganze HTML und das Frontend liegt eben bei der Webseite. Äh, die Logik, wie das Ganze verknüpft wird, äh, läuft über eine Serverless Function. Ähm, das heißt, es ist, äh, eine einfache Funktion, die eben nur eine Aufgabe hat, und zwar den Content von der Webseite entgegennehmen und dann in ein anderes, äh, System zu übertragen. Und das andere System, in das wir übertragen, ist dann Salesforce. Diese Serverless Function besteht normalerweise aus so zehn, vielleicht, äh, zwanzig Zeilen, äh, Code, ist von einem Entwickler relativ schnell implementiert und kann auf diese Art und Weise eben, ähm, die verschiedenen Komponenten verknüpfen.Ich werde jetzt kurz, äh, in Storyblock wechseln, um auch zu zeigen, wie das in unserem, äh, Visual Editor aussieht. Ähm, was ihr hier seht, ist unsere Live-Webseite. Äh, man kann hier sehen, äh, das Erste, wenn man, äh, sich in Storyblock rein begibt, äh, ist eben unser Dashboard. Man sieht hier, wie viele API-Requests, wie viel Traffic, wie viel Contact Activity und so weiter, äh, durchgeführt wurde. Auf der linken Seite ist die Navigation. Ich habe hier in der Navigation beispielsweise auch eine Activities-Overview. Die hat mir jetzt gezeigt, dass mich ein Kollege heute am Vormittag irrtümlich aus unserer Webseite rausgekickt hat. Ähm, sollte eigentlich nicht passieren, ist aber leider passiert beim Eintragen eines neuen Mitarbeiters. Das, äh, kann manchmal vorkommen. So, ich wechsle jetzt in die Content-Übersicht und suche hier nach unserem Enterprise, äh, Contact form. Und unser Enterprise, äh, Contact form öffnet sich dann im Visual Editor. Der Visual Editor ist, äh, für uns, äh, sehr wichtig, weil im Visual Editor kann man, ähm, Änderungen, die man am Content vornimmt, äh, bereits sehen. Bitte nicht verwechseln mit einem, äh, mit einem, äh, Drag-and-Drop-Editor, bei dem es möglich ist, die Webseite zusammenzubauen. Hier auf der linken Seite ist unsere Original-Webseite eingebunden. Die ist, äh, auf einem, äh, auf einem Server gehostet und ein kleines JavaScript in der Webseite verbindet hier die linke Seite mit der rechten Seite. Das heißt, wir haben hier separat links die Webseite, rechts ist der Editor und durch das JavaScript ist das Ganze verbunden. Wenn ich jetzt hier draufklicke, aktiviert sich rechts der Editor für unseren Content-Bereich und ich sehe auch, dass hier, äh, im Editor verschiedene, äh, Optionen für unser Formular hinterlegt sind. Das heißt, ich kann hier beispielsweise als Editor, äh, das Form-Template auswählen. Das heißt, es gibt hier verschiedene, äh, Templates, die auf der Webseite verwendet werden können, wie zum Beispiel Write for our Blog, Submit the Project, Unsubscribe from Feedback und so weiter. Ich kann hier auch einstellen, ob zum Beispiel nach erfolgreichem Abschicken, ähm, des Formulars auf eine Danke-Seite weitergeleitet werden soll. Das heißt, ich kann hier einfach eine unserer, ähm, Storyblock-Seiten auswählen und diese als Danke-Seite auswählen und ich kann hier sogar, ähm, die, ähm, Tracking-Pixel anlegen, äh, die eventuell in diesem Formular verwendet werden sollen. Das heißt, dieses ganze Formular kann in unserem, äh, Editor gestylt werden. Äh, die Logik, was damit passiert, ist aber ausgelagert und in diesem, äh, API Headless Best of Breed, äh, Best of Breed, ähm, Setup, äh, kann man hier einfach die besten Technologien zusammenschnallen. Das heißt, der Content kommt eben ausm Content Management System. Die Verarbeitung, äh, des Formulars, äh, passiert, äh, in einer serverless Function und, äh, unsere Sales People sind am besten in Salesforce. Das heißt, sie können dann direkt in Salesforce mit den neuen Leads, äh, weiterarbeiten. Das zweite Beispiel, auf das ich gerne eingehen möchte, ist Personalisierung. Äh, Personalisierung in einem Headless, äh, Szenario, ähm, ist, äh, kann auf viele verschiedene Arten erfolgen. Das heißt, wir haben viele Gespräche, äh, mit Interessenten, die eben, äh, immer von verschiedenen Arten von Personalisierung sprechen. Die wahrscheinlich einfachste Art von Personalisierung ist die Internationalisierung. Das heißt, ich, äh, ändere die Sprache anhand des Landes, von dem, ähm, ein entsprechender Websitebesucher kommt. Das kann ich anhand der, der Header im HTTP-Request auslesen, welche Sprache der gerne haben möchte und dann kann ich eben Deutsch, Englisch, Französisch und so weiter anzeigen. Es gibt aber dann auch, ähm, weitere, mit mehr Logik verbundene Personalisierungen, wie zum Beispiel, ich könnte die Tageszeit heranziehen und abhängig von der Tageszeit kann ich dann, ähm, verschiedene, äh, Produkte auf der Hauptseite anzeigen. Ich könnte auch beispielsweise, äh, das Wetter heranziehen. Und wenn ich weiß, dass, ähm, wenn ich weiß, ähm, dass, äh, es heute regnet, dann gibt's halt eben eher Regenartikel auf der Startseite der Webseite als, äh, Sonnenscheinartikel. Und normalerweise, wenn Kunden uns auf Personalisierung ansprechen, sprechen sie über eine der beiden folgenden, äh, Arten. Also das eine ist eben die Userpersonalisierung. Das heißt, ich kenne meinen User bereits. Er ist eingeloggt auf der Webseite und, ähm, und aufgrund dessen kann ich besondere Dinge anzeigen. Und das Zweite, was ich als Techniker sehr spannend finde, ist, äh, die, ähm, Personalisierung anhand von, ähm, Verhalten. Das heißt, wenn ich weiß oder wenn ich erkenne, dass ein User fünf Seiten in der gleichen Kategorie ansieht, dann werd ich ihm eben weitere Seiten in dieser Kategorie vorschlagen. Das ist, äh, wahrscheinlich die schwierigste Art, äh, der Personalisierung und benötigt eben, äh, mehr Infrastruktur. Das heißt, man muss mittracken, wo der User sich befunden hat. Dann muss man, äh, eine Suggestion Engine quasi aufsetzen, die, äh, Vorschläge liefert, was dem Kunden als Nächstes, äh, gezeigt werden soll. Das ist alles, äh, nicht so einfach, aber das sind Dinge, die man, äh, mit Headless-Systemen ebenfalls relativ gut, ähm, umsetzen kann, weil es, äh, eben, weil man eben das Datenmodell relativ frei gestalten kann und dann entsprechende, ähm, Metainformationen in unserem Modell, äh, mitgeben kann. Ähm, ein Kunde von uns, äh, Marco Polo, hat, äh, diverse Dinge in diesem, äh, Behavior-driven, ähm, Personalisierung bereits umgesetzt und da gibt's auch Case Studies dazu. Also einmal kurz suchen, ob man das findet, äh, weil's sehr, sehr spannend ist.Wir auf unserer Webseite haben, äh, noch eine sehr einfache Variante, ähm, der, ähm, Personalisierung implementiert. Und zwar wir verwenden einen Cookie, um zu tracken, wie oft ein Besucher auf der Webseite, äh, vorbeikommt. Das ist quasi unser Tracking für das Ganze. Und, äh, wenn er dann, äh, eine gewisse Anzahl an Besuchen, äh, auf der Webseite absolviert hat, verändern wir, äh, den Banner ganz oben. Das heißt, äh, das erste Mal bekommt er, dass er sich bitte, äh, einen neuen Account anlegen soll. Die nächsten drei Male bekommt er, dass er vielleicht, äh, eines unserer, unserer Developer- , ähm, Online-Events besuchen sollte und ab dem zehnten Mal bekommt er zum Beispiel, dass es etwas Neues im Produkt gibt, wie zum Beispiel, das ist vermutlich, äh, meine Kohorte, äh, dass der Image-Service, äh, upgedatet wurde und dass wir jetzt auch WebP, äh, unterstützen. So, und die dritte, ähm, ah, den dritten Anwendungsfall, ähm, zum Thema, ähm, zum Thema globale Kom-- zum Thema Headless und wie ich das implementiere, äh, ist für uns die globale Komponente. Und zwar ist das etwas, was immer öfter nachgefragt wird, wie ich beispielsweise eine Navigation oder andere Informationen, die sich auf jeder Seite wiederholen, in einem Headless-, äh, CMS ablege. Und für uns, äh, lautet, äh, die Antwort da relativ einfach, ähm, eine globale Komponente anzulegen und über die globale Komple-- äh, Komponente, Configuration... Und über die globale Komponente kann ich hier beispielsweise eine Navigation abbilden. Das heißt, ich habe hier oben die Navigation und man sieht hier bereits in der Vorschau, dass auf dieser Seite kein, ähm, kein, äh, Content, äh, existiert, sondern es kann nur, äh, die Navigation oben beziehungsweise der Footer unten, äh, customized werden. Und man sieht hier in unserer Navigation, der erste Eintrag ist Features und auf der rechten Seite im Feld Header ist eben auch der erste Eintrag ein Navigation Item mit dem Text Features. Und das Feature, äh, verlinkt dann auf eine Seite und insofern ist auch, äh, unser Navigation Item besteht aus einem, äh, Namen, einem Link und dieser Link führt dann zu einem, äh, zu einem internen Ziel. Das ist jetzt noch relativ einfach. Unsere Navigation besteht aber auch aus solchen Dropdowns, die eben, äh, mehrere Auswahlmöglichkeiten, äh, erlauben. Das heißt, ich hab da for all mit drei Unterpunkten, ich hab Use Cases mit drei Unterpunkten und so weiter. Und das ist, äh, in Storyblock ebenfalls abgebildet, indem ich dann eben eine Navigation Group anlege und innerhalb der Navigation Group gibt es dann verschiedene Nava-navigation Categories. Die erste Category ist dann for all, die zweite ist Use Cases, die dritte hat, wie wir hier sehen, keine Überschrift, damit es so aussieht, als würde, äh, Use Cases sich über zwei, äh, Spalten erstrecken. Wenn ich jetzt weiter reingehe auf for all, dann sehe ich, dass es da drinnen eins, zwei, drei, äh, Navigation Items wieder gibt und jedes dieser Navigation Items ist dann wieder, äh, zu einem, zu einer anderen Seite auf der Webseite verlinkt. Ich kann hier unten auch noch Text und die Icons anlegen und auf diese Art und Weise wurde beispielsweise, äh, die, die Navigationsleiste für storyblock.com implementiert und, äh, wir empfehlen das auch für jeden, der eben beispielsweise andere Dinge, äh, hinterlegen möchte, wie zum Beispiel haben wir hier auch als Beispiel, äh, das OG Image. Da gibt's eine Default, ähm, ein Default OG Image und dieses Default OG Image kann eben auch in dieser globalen Komponente konfiguriert werden. Gleiches könnte man auch mit anderen Konfigurationsvariablen, wie zum Beispiel dem Google Analytics Code oder ähnlichem machen, wenn man das zentral ersetzen können möchte. Genau, das ist, das sind die Anwendungsfälle, die wir für heute herausgepickt haben und, ähm, ich darf jetzt an Thomas zurückgeben, der uns, glaube ich, durch die Fragen leiten wird. Ja, vielen Dank, Sebastian. Ähm, vielleicht eine erste Frage, die von Maja im Chat aufgekommen ist. Ja. Auf welcher Programmiersprache ist Storyblock geschrieben? Ähm, prinzipiell, äh, können wir solche internen Informationen nicht hinausgeben. Äh, wer sich die API ansieht, wird erkennen, dass, äh, das Backend, äh, von Storyblock, äh, auf Ruby basiert und unser Frontend ist ganz normales HTML und JavaScript und, äh, ja, wurde ganz normal implementiert. Man kann, äh, Storyblock mit prinzipiell jeder Technologie verwenden, die APIs ansprechen kann und es gibt auch für viele Technologien, äh, die man dann, äh, selbst verwendet, äh, SDKs. Das heißt, wir haben ein JavaScript-SDK, wir haben ein Kotlin-SDK, wir haben ein iOS-SDK und so weiter, die, äh, für die Implementierung verwendet werden können. Sehr schön. Und es gibt auch daran noch eine Anschlussfrage: Kann man in Storyblock noch Portal-Einstellungen machen oder nur einzelne Seiten bearbeiten? Also ich denke, die Frage spielt Richtung Customizability von Storyblock als CMS an. Vielleicht kannst du kurz grob erklären, welche Bereiche, welche Areas in Storyblock selbst, äh, customizable sind und wie das funktioniert, ja.-wie da so unsere oder deine Meinung dazu ist. Ääähm, verstehe ich das richtig, dass die Storyblock-Oberfläche gemeint ist oder dass die Webseite gemeint ist? Ich denke, Storyblock als CMS, aber Maya, wenn vielleicht gerne direkt auch im Chat noch im Detail fragen, aber ich würde mal daraus interpretieren, dass der Storyblock als CMS und welche Customization-Möglichkeiten es hier im CMS gibt. Also prinzipiell Customisation-Möglichkeiten... Es... Also, Storyblock als System kann, äh, ebenso verwendet werden, wie es jetzt aussieht. Äh, Storyblock ist eine gehostete Lösung. Das heißt, der ganze Content wird, äh, von uns gehostet und kann dann eben über die APIs abgerufen werden. Es gibt einen relativ ausführlichen, äh, Settings-Bereich auf der Webseite, wo man eben das Verhalten vom CMS steuern kann. Das heißt, äh, ich kann beispielsweise definieren, äh, wo meine, äh, Vorschau, äh, Umgebungen sind. Ich kann, äh, User managen, ich kann, äh, die API Keys für verschiedene Environments anlegen und so weiter. Und, ähm, das obliegt dann dem mehrweiligen Admin der Organisation, dass eben da die entsprechenden, äh, Einstellungen vorgenommen werden. Es besteht auch, äh, die Möglichkeit des Whitelabelings für Storyblock, äh, das ist aber etwas, was ins Enterprise Offering fällt und da müsste man sich, äh, extra darüber unterhalten. Das heißt im Endeffekt, dass, äh, das Logo verschwindet, äh, dass man eben auch, äh, auf einer eigenen URL, äh, das hosten kann und so weiter. Super. Und, ähm, es gibt da, die Maya schreibt gerade: "Kann ich zentrale Einstellungen wie Farbescripts und so weiter machen? Gibt es Freigabe Deployment-Prozesse?" So, äh, zum ersten, äh, Einstellungen wie Farbescripts und so weiter, das wäre wieder, ähm, eine, eine, ein Fall für globale Komponenten. Also ich würde das alles in globalen Komponenten ablegen und das kann dann über, ähm, über die API verwendet werden. Ein weiterer Punkt, der eventuell in diesem Zusammenhang spannend ist, sind Data Sources. Über Data Sources kann ich, äh, zentral Key Value Paare speichern und das wird eben hauptsächlich verwendet für Bereiche, die sich wiederholen. Also wenn ich beispielsweise auf der ganzen Webseite die gleichen Kategorien für, für einzelne Artikel verwenden möchte, dann lege ich eine Data Source an und kann dann diese Data Source, ähm, durch, äh, alle Artikel durchziehen. Äh, das ist dann überall gleich geschrieben und wird über eine ID verlinkt und somit ist es, ähm, ist es relativ easy, ähm, zu managen. Äh, Freigabe Deployment Prozess, ja, gibt es. Und zwar gibt's die Releases App, äh, beziehungsweise Workflows. Nummer eins ist, ähm, der Status kann jeden, äh, Content Item, äh, eine Workflow Stage zugeordnet werden. Das heißt, äh, es ist vorkonfiguriert, äh, drafting, reviewing and ready to publish. Äh, ich kann dann in den höheren Plänen eigene, äh, eigene, eigene Workflow Stages hinzufügen und ich kann dann jedes Content Item eben der entsprechenden Stage, ähm, zuordnen. Ich kann dann einen User assignen, der das eventuell jetzt weiterbearbeiten sollte und erst, äh, wenn, äh, dieses, äh, Content Item in Ready to Publish ist, dann kann ich auch wirklich den Publish-Knopf drücken. Genau. Äh, kann Storyblock in einer dotnet-Umgebung benutzt werden? Ja, das funktioniert, solange eine, solange eine, also im Endeffekt ein Network Client existiert, der eben die API, ähm, zur API Requests aufbauen kann, kann Storyblock, äh, auch in einer dotnet-Umgebung benutzt werden. Sehr schön. (lacht) Ähm, Maya, gerne oder auch generell, ähm, wenn es da weitere Fragen gibt, Sebastian, ich denk, ähm, man kann-- Was würdest du empfehlen, wer so der beste Schritt, um, ähm, die diversen Customisation Möglichkeiten von Storyblock zu erkunden? Ähm, was würdest du hier empfehlen? Der einfachste Weg ist, einfach einen Account machen und, äh, einmal ausprobieren. Also es gibt, äh, ein Demo Setup, in dem man einfach mal mit einem, äh, mit einer Demo-Webseite spielen kann. Äh, wenn's, äh, in einem Enterprise-Umfeld, ähm, Interesse gibt, das zuvor gezeigte Enterprise Contact Form ausfüllen und, äh, mit uns Kontakt aufnehmen und wir erklären da gerne weiter, welche Möglichkeiten zur Implementierung das gibt, beziehungsweise es ist bissel, a bissel abhängig, ob's a Inhouse Development gibt oder ob man einen Partner, Partner benötigt. Wir können auch gerne Partner empfehlen, äh, die dann eben bei einer Implementierung helfen. Super, das klingt nach einem schönen Abschluss. Vielen Dank für die Demo, Sebastian. Vielen Dank allen Zuhörern. Wenn es Fragen gibt, gerne einfach bei storyblock.com vorbeischauen. Gerne auch Sebastian oder mich über LinkedIn anschreiben. Ähm, ja, wir würden uns freuen, von euch zu lesen. Ansonsten noch viel Spaß bei der UMKB Konferenz und bis bald hoffentlich. Vielen Dank. Bis bald. Tschüss. Tschüss.
Automatisch erstellt & redaktionell aufbereitet — kann vereinzelt Fehler enthalten.
