AMA: Content-Management-Tools

[Anton]

Hi Community!

Ich heiße Anton und bin Head of Web & Creative bei Thought Leader Systems, einem HubSpot Diamond Partner aus Deutschland.

Ich blicke mittlerweile auf fast 20 Jahre CMS Erfahrung zurück. Sowohl als User, Admin als auch Designer & Entwickler.

Da HubSpot erst vor einigen Wochen das neue CMS Hub veröffentlicht hat, freue ich mich sehr, diese Woche das AMA zum Thema Content-Management-Tools bzw. Content-Management-Systeme (kurz CMS) zu hosten.

Mein Team und ich sind für die Umsetzung von Website Projekten in HubSpot, grafische, teils interaktive Klick-Prototypes als Umsetzungvorlage für andere Agenturen und Implementierungen von HubSpot Marketing in bestehende Systeme zuständig.

Da das Kundenportfolio bei Thought Leader Systems von Small-Business bis Enterprise alle Unternehmensgrößen umfasst, erarbeiten wir meistens maßgeschneiderte Lösungen, die auf unserer langjährigen Erfahrung beruhen. Dabei stehen die Usability und Automatisierung im Vordergrund.

Da sich diese AMA um das Thema CMS dreht:

Was ist ein CMS und wozu braucht man eins?

Wie der Name erahnen lässt, ist ein CMS ein Tool, um Inhalte auf einer Seite verwalten zu können. Kein Unternehmen sollte in der heutigen Zeit eine statische Website bzw. „Online-Visitenkarte“ besitzen, welche in unregelmäßigen Abständen überarbeitet wird bzw. werden muss.

Einige essenzielle Aspekte, an denen man ein (sehr) gutes CMS erkennt ist, dass

• einen/seinen Entwickler kontaktieren muss
• es sicher ist
• es optimalerweise auch nachhaltig ist. Ja, richtig gelesen, Nachhaltige Websites/CMS!

Was meine ich damit?

Stellen wir uns folgende Situation vor:

Ihr benötigt eine neue Website für euer Unternehmen; Ihr beauftragt eine Agentur, die Firmenwebsite (neu) zu erstellen; nach einem langwierigen Prozess, der mehrere Monate, wenn nicht gar Jahre dauert, wird die Website endlich veröffentlicht und jeder ist stolz auf das Resultat. Wenn nicht anders vereinbart, wird die Zusammenarbeit mit der Agentur beendet, da sie ihren Job erledigt hat. Zeit vergeht und an der Website wird entweder gar nicht oder sehr viel gearbeitet. Nach einem gewissen Zeitraum wirkt die Website aber recht alt im Vergleich zur Konkurrenz, die Inhalte sind möglicherweise nicht mehr aktuell, die Mediathek ist überfüllt, allein das Backup benötigt einen halben Tag und es gibt gibt unzählige Sicherheitsupdates.

Wenn ihr Pech habt, könnt ihr die aktuellen Sicherheitsupdates nicht mehr einspielen.

Was tun?

Im ersten Schritt versucht ihr die ehemalige Agentur zu kontaktieren und sie erneut zu beauftragen. Falls nicht, sucht ihr eine andere Agentur. Egal ob ehemalige Agentur oder neue Agentur, es ist nicht ausgeschlossen, dass ihr „Wir müssen alles abreißen und neuaufbauen!“ als Antwort bekommt. Daraufhin werdet ihr etliche interne & externe Gespräche führen, das neue Design abstimmen, Content erstellen (lassen). Irgendwann ist es so weit und ihr habt eine neue Website.

An diesem Punkt beginnt der Kreislauf aber erneut. Je nachdem wie lange der Prozess gedauert hat, kann die neue Website in wenigen Monaten oder Jahren dieselben Probleme wie die bisherige aufweisen.

Die Frage ist jetzt: Ist das Nachhaltig?

Investiert man gerne alle paar Jahre, teils sehr hohe Beträge und Unmengen an Zeit, Nerven? Ich denke nicht.

Nachhaltig ist, wenn man sich keine Gedanken um Sicherheitsupdates, generelle Updates etc. Gedanken machen muss.

Man sollte zu jedem Zeitpunkt die Seite weiterentwickeln und an die Bedürfnisse des Unternehmens anpassen können. Denn: Wenn dies zutrifft, wird die Website nie „outdated“ sein. Somit spart ihr euch mögliche Ausschreibungskosten, Frust, Arbeitszeit und hohe Umsetzungskosten.

Dafür braucht man ein sehr gutes und stabiles Rückgrat (CMS).

Ein Beispiel aus der Praxis:

Mein Team und ich haben erst neulich, für einen Kunden, innerhalb von wenigen Wochen den Grundstein für ein neues Corporate Design gelegt ihm und dieses als sogenanntes Custom Theme zur Verfügung gestellt. Auf dieser Basis wird die Website nach und nach um-/aufgebaut. Das Theme wurde so konzipiert und umgesetzt, dass es zu jedem künftigen Zeitpunkt, mit vergleichsweise wenig Entwicklungsaufwand erweitert werden kann. Des Weiteren haben wir das Theme so konzipiert und umgesetzt, dass der Kunde künftig zu jedem Zeitpunkt - ohne Programmierkenntnisse - das Design global verändern kann.

Hinweis: Mit einem konventionellen CMS wäre dies in einer solch kurzen Zeit nicht realisierbar gewesen.

• Was sind die Vorteile von CMS Hub gegenüber anderen CMS?
• Was gibt es bei einer CMS Migration zu beachten?
• Wie ist das CMS Hub zu bedienen?
• Hast du Best-Practise-Tipps?
• Kann ich selbstständig eine Seite mit dem CMS Hub aufbauen?
• Was müssen Entwickler beim arbeiten mit dem CMS Hub beachten, was man bei einem anderem CMS nicht beachten muss?

Sind nur einige Beispielfragen, die ich diese Woche beantworten möchte.

Jetzt seid ihr dran - Was möchtet ihr zum Thema CMS und CMS Hub wissen?

Ich freue mich auf eure Fragen und Kommentare!

Anton

[MiaSrebrnjak]

Hi @Anton,

vielen Dank für den tollen Artikel!

Hi @MatthiasWeber, @RomyFuchs1, @StefanWendt , @fabianschmidt, @mariomaier, @Dennis-DWFB, @CRM_Sandra, @SEckert, @ChristianRieck, @Jnix284, @Angela_W, @KHeidemannINF, @AnniSampt, @JWußmann, @VBebensee, @SPöverlein, @SStraughan, @Sascha_Wenzel, @MSK, @ABernetRallo,

ich wollte euch über diese “Ask-Me-Anything”-Fragerunde informieren.

Habt ihr Fragen zum HubSpot-Website-Builder & den Content-Management-Tools?

Danke!

Viele Grüße,

Mia, Community Team

[mhp11]

Hi @Anton,

hast du vielleicht Tipps, wie man die Ladezeit von Website-Seiten optimierien kann? Kannst du uns ein paar Best Practices empfehlen?

Grüße,

Michael

[Anton]

Hi @mhp11,

natürlich.

Es gibt viele Möglichkeiten die Ladezeiten zu optimieren.

Der erste Punkt sollte sein die Bilder für Web zu optimieren.

Dh. Wenn du die Bilder in einer Bildsoftware wie bspw. Photoshop bearbeitest, dann solltest du als erstes die Auflösung(DPI) überprüfen und anpassen. Hierbei ist eine DPI Anzahl von 72 als Standard angesehen.

Die Größe(Breite x Höhe) spielt auch eine Rolle. Im normalfall reichen dir Bilder von 800px Breite mehr als aus, wenn das Bild über - sagen wir mal - die Hälfte der Contentbreite angezeigt werden soll.

Für full-width Bilder sind 1920px Breite gut geeignet, da der aktuelle Standard eine Full-HD(1920px x 1080px) Auflösung bei Bildschirmen ist.

Wenn du die Bilder in Photoshop(o.ä) bearbeitest, solltest du die Bilder “Für Web speichern”, dabei werden die Bilder ohne irrelevante Informationen, gespeichert, wodurch du noch ein paar Bytes sparen kannst.

Falls du mit Vektor-Grafiken (bspw. in Illustrator), dann exportiere die Grafiken als SVG. Diese bieten den Vorteil, dass sie vergleichsweise zu JPG und PNG enorm wenig Speicherplatz benötigen.

Als Beispiel:

Wenn du eine Grafik in Illustrator als PNG, JPG und SVG exportierst, kannst du die Größe vergleichen.
Nehmen wir an, dass nach dem Export einer Grafik, die PNG ist 200kbyte und die JPG 150kbyte groß ist. Dann ist liegt die SVG vermutlich bei ca. 20-30Kbyte.

Somit ist sie nur ein Bruchteil so groß, hat den Vorteil, dass sie immer Scharf dargestellt wird und wirkt sich positiv auf die Ladezeit aus.

Ein weiterer Punkt bei der Bild optimierung ist, dass sogenannte “crunchen”.

Hierbei werden die Bilder soweit komprimiert, dass es - je nach Einstellung - kein Unterschied für das menschliche Auge wahrzunehmen ist, aber etliche Kbytes eingespart werden können.

Hierfür gibt es unzähliche Anbieter im Netz und Software.

Ich persönlich nutze kraken.io. Dieser bietet etliche Optionen in der Web Oberfläche an. Eine der besten Funktionen hierbei sind URL-paster und Page cruncher.

Beim URL-paster kann man eine(oder mehrere) URL(s) zu Bildern eingeben. Kraken zieht und optimiert sie mit deienn gewählten Einstellungen. Anschließend kannst du entweder einzelne Bilder, alle auf einmal downloaden oder als ZIP in seine Dropbox hochladen(wenn man sie connected)

Beim Page-cruncher ist es ähnlich wie beim URL-paster. Allerdings gibt man hier die URL einer Seite an und Kraken zieht und optimiert alle Bilder auf dieser einen Seite. Anschließend werden die Bilder, optional sogar in der richtigen Ordner Struktur als ZIP oder Dropbox upload zur Verfügung gestellt.

Das erleichtert enorm das Suchen und ersetzen der optimierten Bilder.

(Für Entwickler gibt es auch eine API mit der man Bilder direkt beim Upload optimieren kann).

Falls du dich jetzt Fragen solltest, wann du welches Format verwenden solltest:

Meine persönliche Empfehlung ist:

SVG > PNG > JPG

Grund, warum PNG vor JPG gelistet wird ist, dass JPGs zwar kleiner aber auch eine schlechtere Qualität haben.

Ein weiterer Punkt der Ladezeit optimierung sind JavaScripts, nicht verwendete Ressourcen und ähnliches.

Um herauszufinden, was genau optimiert werden kann/muss empfehle ich die Seite mit einem Page Speed Tester wie GTMetrix oder Google Page Speed oder HubSpots Website Grader zu checken. Hierbei rate ich zu GTMetrix oder Website Grader, da sie konstantere Ergebnisse liefern.

Nachdem der Test durchgelaufen ist, kannst du in der Auswertung die entsprechenden sehen.
Hier ein Beispiel des Testergebnisses für die Desktop Version von hubspot.com

Die Serverresponsetime kann man ggf. mit der CDN Option noch weiter optimieren, aber in den meisten Fällen handelt es sich um JavaScripts, CSS und Bilder.
Als Beispiel hier das Ergebnis meiner privaten Seite, die aktuell (noch) nicht auf HubSpot basiert und seit knapp 3 Jahren nicht angefasst wurde

Wie man Bilder optimieren kann, habe ich ja bereits geschrieben.
Für JavaScripts würde ich folgendes empfehlen(wird jetzt etwas technisch):
Wenn du/ihr mit einem custom theme oder child-theme arbeitet, versucht das Laden von externen JavaScripts zu minimieren.

Beispiel:

Wenn ihr jQuery von einem externen Content-Delivery-Network(CDN) ladet, könnt versuchen es entweder aus dem theme Ordner oder aus dem File-Manager laden zu lassen.
Dazu einfach eine neue Datei erstellen, jQuery(oder das jeweilige Script) reinpasten, Datei hochladen, im Theme an der entsprechenden Stelle den externen durch “internen” link ersetzen.

Hintergrund ist, der Weg von HubSpot zu X ist immer länger als wenn du im System bleibst. Kürzere Wege = schnellere Ladezeiten.

Auch solltest du überprüfen, ob die Scripts bspw. ansynchron geladen werden.
Beim Asynchronen Laden entscheidet der Browser, wann er das jeweilige Script läd. Somit kann er die Seite ggf. schneller an den User ausliefern.

Ich persönlich bin der Meinung, dass die Anfrage von vielen, kleineren Scripts die Performance mehr beeinflusst als das laden einer größeren Datei.

Was meine ich damit?

Wenn du beispielsweise X Module hast, die alle etwas im JavaScript teil stehen, dann sind das alles seperate Scripts, die geladen werden. Wenn es sich hierbei allerdings um das selbe Script handelt, solltest du es als seperate Datei im Theme oder im File-Manager ablegen und es in der rechten Sidebar vom Modul entsprechend auswählen. Dann wird HubSpot das Script nur einmalig Laden.
Du kannst auch mehrere/alle Scripte in einer Datei zusammenfassen und diese dann einmalig laden lassen. Hierbei empfehle ich aber ein vorher/nachher test zu machen.

Ein letzter Punkt der genannt werden muss ist SSL & Redirects.

Abgesehen von rechtlichen Institutionen können Google und Co. Können dich bei nicht verwenden von SSL negativ bewerten und die Seite langsamer ausliefern. Bei HubSpot bekommst du immer ein SSL Zertifikat zum Paket dazu, welches automatisch aktiviert wird. Falls du mehr brauchen solltest, kannst du sie gegen Aufpreis erwerben.
Auch besteht die möglichkeit eigene, HubSpot fremden SSL Zertifikate zu verwenden - das ist aber immer ein Thema des jeweilgen Domaindienstes.

Habe dies in meiner ganzen Laufzeit als “HubSpotter” nur einmal bei einem Kunden erlebt.

Bei redirects ist es anders.

Das gute an HubSpot ist, dass es automatisch ein Redirect anlegt, sobald du Änderungen am Seiten, Post, Blog o.ä Link vornimmst. Nachteil: So können über lange Zeit sogenannte redirect-Ketten entstehen, welche von Google & Co. negativ bewertet werden.

Beispiel:

Seite A wurde 2016 mit der URL Home Page | PageGroup erstellt

Nach dem Livegang wurde es auf Home Page | PageGroup , nach einigen Monaten auf Home Page | PageGroup usw. geändert.

Somit legt HubSpot ein redirect von /about auf /company/about und schließlich /company/about-us an.

Wenn man die redirects nicht auflöst hast du somit eine Redirect Kette. Da von A>B>C(Ergebnis) umgeleitet wird.

Jeder redirect kostet Zeit.

Um heraus zufinden ob und falls ja, wie viele redirects im im Umlauf habt, empfehle ich ein Tool wie SEMRush zu nutzen und anschließend die möglichen Redirects aufzuräumen/aufzulösen

Hoffe das hilft dir weiter. Falls du noch Fragen haben solltest, einfach Fragen

Gruß,

Anton

[mhp11]

Wahnsinn, tolle Tipps, danke @Anton! Ich werde mir das mit der Bildoptimierung und den redirects auf jeden Fall merken!

Michael

[KHeidemannINF]

Hallo @Anton ,

@MiaSrebrnjak hat mir liebenswürdigerweise den Tipp gegeben, mich hat Dich zu wenden. Wir haben folgendes DSGVO-Problem:
Auf unserer Website sind einige Videos von Youtube eingebunden. Laut DSGVO darf man das aber nur, wenn vor dem Klick zum Abspielen explizit noch einmal ein Consent eingeholt wird (ein Pop-up oder so), dass den User darauf hinweist, dass es sich um ein Youtube wieder handelt und dem User klar ist, dass es dann eine “Verbindung” zu der Plattform gibt. Das Unterbinden von Cookies (datenschutzkonforme Einbindung des Links über den erweiterten Datenschutz-Modus von Youtube) und der Hinweis in den Datenschutz-Richtlinien reicht leider nicht aus.
Habt Ihr da eine Lösung für?

Sonnige Grüße aus Hannover,

Katrin

[Anton]

Hi @KHeidemannINF,

Wir haben verschiedene Ansätze hierfür.

Mögichkeit 1(am häufigsten)

Wir verwenden ein 3rd-party Cookie Consent tool, weil es unser Kunde verwendet und wir eh HubSpot einbinden müssen. Diese erkennen, wenn so eingestellt, Youtube Links und geben die von dir gewünschte Funktionalität. Falls der Kunde kein Cookie Consent hat, empfehlen wir OneTrust.

Möglichkeit 2

Eingie Kunden wünschen etwas komplett seperates. Dafür setzen wir unser eingens entwickeltes JavaScript ein.

Bei dem JavaScript ist die Logik, dass es nach iFrames sucht, welche auf YouTube zugreifen und erst ein Overlay mit einem Text, Checkbox und deaktiviertem Button anzeigen. Sobald der Besucher die Checkbox mit dem Hinweis “Hey, bist du sicher, dass du den Cookie aktivieren möchtest?” aktiviert, wird der Button klickbar und sobald der User den Button klickt, wird der Cookie gesetzt.

Möglichkeit 3

Custom Modul.

Der YouTube Cookie wird nur bei dem Standard Embed Code gesetzt.

Wir haben ein Custom Modul, welches den Youtube Link in eine vorgefertigte iFrame einsetzt.

Wie das custom Modul aussieht kannst du hier nachlesen.

Möglichkeit 4 (ähnlich wie 3)

Mini JavaScript.

Dieses sucht auf der gesammten Seite nach

https://youtube.com/

und ersetzt es durch

https://youtube-nocookie.com/

(bei vielen Videos auf einer Seite kann sich dies aber negativ auf den Page Speed auswirken)

Am einfachsten und gängisten ist aber, wie bereits erwähnt, die 3rd-Party Lösung.

Hoffe, das hilft dir weiter. Falls du noch weitere Fragen haben solltest, kannst du natürlich jederzeit Fragen

Gruß,

Anton

[AllisonZ]

Hey @Anton !
Vielen Dank für das spannende AMA

Ich arbeite schon seit einigen Jahren bei HubSpot (Support, dann Onboarding, jetzt Solutions Engineer), und habe viele Projekte betreut. Wenn ich über das CMS spreche, habe ich mir eine kleine Liste zusammengestellt von den Vorteilen des HubSpot CMS gegenüber anderen Anbietern.
Wo siehst du, dass HubSpot klar im Vorteil liegt?

Danke vorab!

Liebe Grüße,

Allison

[Anton]

Hi @AllisonZ,

schön dich kennenzulernen

Sehr gerne. Ich versuche es mal aus verschiedenen Perspektiven zu beantworten.

Als User:

Die Einfachheit. Es ist super einfach Seiten, E-Mails etc. zu erstellen und zu maintainen, da man, bestenfalls mit standardisierten, Templates arbeitet und somit Änderungen global vorgenommen werden können. Spart eine Menge Zeit. Auch ist die Staging Umgebung etwas, was bei anderen Systemen nur über Umwege und teilweise mehr Kosten(Plugins & Arbeitszeit) möglich ist. Ein weiterer Punkt ist natürlich die Personalisierung die ein Kernaspekt von HubSpot ist. So muss man nicht X Seiten für jeden möglichen Zwecke anlegen und den Überblick behalten.

Als Admin:

Das alles an einem Ort ist und alles einfach mit einander arbeitet ist unglaublich effizient. Man muss sich kaum Gedanken machen, ob etwas funktionieren wird, den das wird es in 99,9% der Fälle.

Beispielsweise hatte mich heute eine Kollegin gefragt, ob es möglich sei, ein pers.-token der eine URL beinhaltet als Link in einem Modul zu verwenden. Nach kurzem Testing: ja. Einfach den Token als {{ contact.token }} in das URL Feld einpflegen und siehe da - HubSpot meckert zwar, dass es keine korrekte Formatierung für eine URL ist, aber es funktioniert.

Desweiteren kann es günstiger als eine Mischung an verschiedener Software sein. Wenn man aber nur das CMS Starter betrachtet, dann ist es in den meisten Fällen günstiger.

Beispiel:

Bei einem self-hosted CMS (auch wenn es auf den ersten Blick kostenlos erscheint) ist es dies nicht.

• Man hat Webspace/Server kosten die, aufs Jahr gerechnet, ein großen Teil der CMS Starter Kosten ausmachen
• Man hat Pluginkosten. Gibt es bei HubSpot zwar auch, wenn man seperate Apps kauft/verbindet, aber die Core-Funktionen sind alle im Preis inbegriffen und übersteigen die Grundfunktionalität jedes self-hosted CMS
• Bedenke die Maintanace Kosten. In meiner alten Agentur, war ich teilweise Wochen mit der Instandhaltung einer Seite beschäftigt, da der Kunde einfach alles reingeladen hat und die Seite schlussendlich über 20Gbyte groß war. Bei jedem Backup musste ich vorher dem Webspaceanbieter bescheid geben, damit er die Serverressourcen hochfährt, da ansonsten der Server kapituliert hat. (Kein gutes Webspace Paket, aber ich hoffe es ist klar, auf was ich hinaus möchte)

Wenn es einmal läuft, dann läufts und man muss sich keine Gedanken um Backups & Updates machen. Selbst uralte Funktionen werden teilweise noch weiter unterstützt.

Als Developer:

So schnell und so einfach, wie man Themes, Seiten und weitere Assets programmieren und maintainen kann ist mir bis vor HubSpot nicht bekannt gewesen. Der Grad an Detail in welches man als Developer eintauchen und optimieren kann, erleichtert jedem Developer das Leben. Wenn man die Code Menge anschaut, die man in einem anderen System/Sprache benötigt um das selbe/ähnliche Ergebnis zu erhalten - sagen wir mal Hubl bedarf deutlich weniger Zeit und Zeilen.
Beispielsweise habe ich in der Konfigurationsdatei für mein persönliches Theme aktuell über 3000 Zeilen(ich rechne bei Fertigstellung mit min. 8000 Zeilen) geschrieben, damit kann ich später das komplette Design, ohne die CSS händisch anpassen zu müssen, beliebig verändern.

Der Einstieg in die Entwicklung mit Hubl ist sehr einfach. So konnte ich einen meiner Developer, bspw. innerhalb von wenigen Wochen auf ein ziemlich gutes Niveau bringen sodass er nach kürzester Zeit mit Sachen ankam, die wirklich beeindruckend waren.

Ein weiterer Punkt (mischung aus User, Admin und Developer) sind natürlich die Globalen Elemente. Man legt es einmal an und wenn Einträge ändert, muss man nicht X Seiten überarbeiten. Somit wieder Zeit & Kosten Ersparnis. Hat man zwar in anderen CMS nur, wenn es das Theme hergibt, da solche Elemente Theme basiert sind. Bei HubSpot können sie Theme unabhängig angelegt werden. Ich rate zwar jedem Kunden davon ab, aber die Möglichkeit besteht.

Hoffe, das dir diese Antwort weiterhilft

Gruß,

Anton

[AllisonZ]

Hi @Anton ,
Entschuldige die späte Rückmeldung!

Wow

Danke für die super Zusammenfassung. Das habe ich mal direkt an meine Sales Reps weitergeleitet. Das sind top Argumente für die Nutzung von unserem CMS, vor allem, da es jetzt auch schon eine kostenlose Version gibt.

Ich weiß jetzt auch, an welchen Partner ich mich wenden kann für CMS Projekte

Liebe Grüße,

Allison

[MaLi22]

Hallo @Anton, danke für das AMA!

Habt ihr vielleicht Erfahrung mit einer Website-Migration einer TYPO3 Website gemacht?

Kann ein Website-Umzug irgendwelche negativen Auswirkungen haben, auf die man sich vorbereiten soll?

Danke!

VG

Marie

[Anton]

Hi @MaLi22,

Natürlich haben wir Erfahrungen mit Typo3 Migrationen.

Plant ihr umzusteigen, oder seid ihr bereits umgestiegen?

Bei einem Umzug von CMS zu CMS(eher wegen Serverumstellung) kann es zu folgenden Punkten kommen:

• Rankings und SEO gehen nach dem Livegang in den ersten Wochen leicht in den Keller, fangen sich aber schnell wieder.
• Falls ihr die Domain/DNS settings noch nicht verknüpft/eingestellt habt: Je nach Domain Anbieter kann es unter Umständen bis zu 48h dauern, bis die DNS Settings übernommen und somit die Domain/Seite live geht. Oft kannst du die sogenannte TTL Settings in den Domain settings des jeweiligen Domain Anbieters anpassen und die Zeit verkürzen, dies ist aber immer individuell.
  Falls du dir nicht sicher bist, würde ich dir in dem Fall empfehlen, dich mit eurer IT oder Domain Anbieter in Verbindung zu setzen und dies frühzeitig zu klären. Nicht das es am Tag des Livegangs heißt “Jetzt heißt es rumsitzen und Tee/Kaffee trinken bis die Änderungen aktualisiert wurden”
• Ganz wichtig: Niemals, eine Seite am Freitag oder vor Feiertagen Live schalten. Das kann einigen Personen das Wochenende/Feiertage kosten. Ich hatte vor Jahren mal einen Livegang am 23.12 um 17 Uhr, da es der Kunde explizit gewünscht hatte. Kannst dir ja vorstellen, wie ich Weihnachten verbracht habe.

Ein weiterer Punkt den ihr beachten solltet ist

• Ihr müsst die User, also die Personen, die von eurer Seite aus im neuen System aus arbeiten werden, frühzeitig ins neue System einführen. In der HubSpot Academy(in jedem Portal integriert), gibt es für (sehr) viele Anwendertypen Kurse, die wirklich gut sind und der jeweiligen Person einen guten Einstieg in das CMS oder die jeweilige Funktion liefern.

Es gibt, meiner Meinung nach, nichts schlimmeres, als wenn ein Team, welches auf CMS A(in dem Fall Typo3) auf CMS B (in dem Fall HubSpot) switched und nicht weis, wie es funktioniert und versucht die Arbeitsweise aus CMS A in CMS B beizubehalten. Vieles funktioniert natrürlich sehr ähnlich, wenn nicht gar gleich, aber es gibt immer Unterschiede.

Wenn schon alles aufgebaut ist, empfehle ich euch eine Tabelle/Checkliste im Tool eurer Wahl mit folgenden Informationen zu erstellen, damit das Testing einfacher ist und man nicht den Überblick verliert

• Seitenname ( Wie heißt die Seite)
• interner Seitenname (optional; kann je nach eurer Namenskonvention aber helfen die Seiten schnell in HubSpot zu finden)
• Alte URL (falls sich die URL Struktur geändert hat; wie sie vorher auf Typo3 war)
• Neue URL (falls sich die URL Struktur geändert hat; wie ist sie jetzt auf HubSpot)
• Kommentar (für Anmerkungen wie bspw. “CTA im Header ist Rot statt grün”)

Vor und auch nach einem Umzug empfehle ich alle Links durchzuklicken, optische Tests zu machen und euch einige Tage nach dem Go-Live genug Zeit zu blocken, da es immer etwas geben wird, was optimiert werden muss.

Hoffe, das Hilft dir weiter

Viele Grüße,

Anton

[LisaStappert]

Hi @Anton ,
Danke dir für dieses super AMA und die vielen Insights (und den Mention von der HubSpot Academy in einer deiner Antworten​).

In deinem Post redest du von Nachhaltigkeit der Seite. Hast du da vielleicht noch ein paar Tipps, wie man sicherstellt, dass die eigene Website nicht schon ein paar Monate nach dem Relaunch wieder veraltet ist? Gibt es da ein paar bewährte Methoden, wie ihr das bei euch und eurer Kundschaft regelt, die du mit uns teilen kannst?

Danke dir schonmal vorab!
Liebe Grüße
Lisa

[Anton]

Hi @LisaStappert,

meiner Meinung nach bedarf es einer, vergleichsweise großen, vorangestellten Planung und einem großen initialen Mehraufwand.

Unser Vorgehen bei Kunden, die großen Wert auf Nachhaltigkeit legen ist natürlich zuerst eine Analyse und Definition von Zielen und Wünschen inkl. möglichen künftigen Anpassungen des Designs. Hinzu kommt natürlich auch unsere Erfahrung bei der wir schon teilweise, vor dem Kunden wissen, was er möchte und was nicht. Wenn er also beispielsweise “ich möchte X haben” sagt, fragen wir ob er auch “Y” haben will, da es unserer Erfahrung nach immer so war.

Anschließend erstellen wir Developer, die Module und das custom Theme, welches genau auf die Bedürfnisse des Kunden zugeschnitten sind. Somit versuchen wir sicherzustellen, dass wir in Zukunft die größt mögliche Kontrolle haben und bspw. Designänderungen globale Auswirkungen haben, ohne jede Seite individuell anpassen zu müssen. Hierbei arbeiten wir nach dem Atomic-Design Prinzip.

Diese herangehensweise erleichtert es uns schnell und effizient zu arbeiten. Ein weiterer Vorteil für den Kunden ist, dass es vergleichsweise wenig Zeit in Anspruch nimmt, wodurch er Kosten spart. Also Win-Win

Auch arbeiten wir, wo möglich, mit (Personalization)Tokens um Angaben aus den Settings global editieren zu können.

Ganz einfaches Beispiel:

Nahezu jede Website hat im Footer das Jahr. In vergangenheit habe ich oft erlebt, dass es sich hierbei um ein Textfeld, statischen Text in der HTML o.ä. handelt. Das bedeutet, dass man im Prinzip immer am 1.1 des neuen Jahres den Footer aktualisieren muss. Da ich der Überzeugung bin, dass nahezu jeder Mensch auf der Welt am 1.1 besseres zu tun hat als an die Website zu denken setzen wir hier den Hubl

{{ year }}

ein.

Dadurch wird das Jahr automatisch gepflegt und man muss nicht mehr daran denken. Selbiges gilt für sämtliche Adressen/Anschriften und alles, was man aus den HubSpot Settings an Tokens bekommt. Somit stellen wir sicher, dass mögliche Änderungen bspw. bei Umzügen global sind und nicht x E-Mails, Seiten usw. überprüft müssen, den dabei fällt immer mindestens ein Asset herunter.

Ein weiterer Tipp für Nachhaltigkeit ist die Pflege des File-Managers.

Wir erstellen dort eine Ordnerstruktur, die jeder beim ersten Blick versteht und damit arbeiten kann.

Beispielsweise:

• theme-assets
  • fonts
  • icons
  • placeholder
• pages
  • page-a
    • images
    • downloads
  • page-b
    • images
  • usw.
• emails
  • email-a
    • images
  • email-b
• usw.

Wie überall bedarf ein solches Vorgehen (anfangs) eine unglaubliche Disziplin, aber nach einer Zeit kommt man schnell in dieses System rein.

Tipp aus der Technik:

Alle Ordner, Bilder, Dateien immer kleinschreiben und Leerzeichen durch Binde- oder Unterstrich ersetzen. Dadurch wird das Risiko von möglichen Verlinkungsfehlern auf 0 reduziert. Hintergrund hierfür ist, dass Browser Leerzeichen durch “%20” ersetzen, was zur Unauffindbarkeit des Assets führen kann. Kommt bei HubSpot zwar extrem selten vor, aber sicher ist sicher.

Desweiteren wissen unsere Hausinternen Content-Creator(die Personen, die Seiten aufbauen), dass sie bspw. Bilder und andere Assets bei Änderungen ersetzen und nicht neu hochladen sollen. Dadurch versuchen wir den File-Manager schlank zu halten - gibt meiner Meinung nach - nichts schlimmeres als wahllos hochgeladene Assets bei denen man nicht auf den ersten Blick erkennt zu was sie gehören.

Dem Kunden sagen wir das natürlich auch, allerdings ist es ihm überlassen, ob er sich daran hält. Schließlich ist ein neues Bild schneller irgendwo hochgeladen als das jeweilige Bild im File-Manager zu suchen und zu tauschen.

Hoffe, dass dir diese Insights weiterhelfen

Viele Grüße

Anton

[LisaStappert]

Hi @Anton,

Danke dir für die ausführlichen Tipps. Zwar hab ich HubL im Footer schon genutzt (ich stimme dir voll und ganz zu zum Thema 1.1.) , aber auf die Idee auch die Unternehmensadresse so global aktualisieren zu können bin ich bislang noch nicht gekommen. Wieder was gelernt

Wünsche dir eine super Woche.
Liebe Grüße

Lisa

[MiaSrebrnjak]

Hi @Anton, vielen Dank für die tollen Antworten!

Ich wollte dich bei einer Frage in der Community um deine Hilfe bitten:

Formulare sind ein essenzieller Teil der Website - für die Datenqualität im CRM ist es wichtig, dass die Eingaben vorm Absenden des Formulars überprüft werden.

@Dennis-DWFB hat gestern diesbezüglich eine interessante Frage in der Community gestellt:

"Mittlerweile ist es relativ erwartbar in anderen Formularen, dass beispielsweise Vorschläge bei der Eingabe von Stadtnamen kommen. Wenn man zum Beispiel “Halle” eintippt, dass man dann gefragt wird ob es Halle an der Saale ist etc.

hat sich zufällig schon mal jemand mit Autofills in HubSpot beschäftigt?"

Ist das eine Art der Formular-Validierung?

Wenn ich mich nicht irre, werden standardmäßig in HubSpot-Formularen nur E-Mail Adressen überprüft; wäre es mit einem Custom-Coded-Template möglich, auch benutzerdefinierte Formular-Validierung zu verwenden?

Vielen Dank für deine Hilfe!

[Anton]

Hi @MiaSrebrnjak,

vielen Dank!

Sehr gute Frage. Einen solchen Fall hatte ich noch nie, deswegen ist die nachfolgende Antwort nur theoretisch.

Wenn es um spezielle Anpassungen/Verhalten von HubSpot Formularen geht, kommt man meiner Meinung nach, nicht um ein custom Modul herum. Gibt natürlich auch andere Wege, aber dieses ist am einfachsten im Setup.

Ein solches Custom Modul besteht mindestens aus einer Formular Funktion und einem Standard Embed Code, welcher mit den Hubls aus der Formular Funktion modifiziert wurde. Möchte man weitere Variablen individuell anpassen, so muss man weitere Funktionen hinzufügen.

Der Code sieht dabei so aus

{# das normale Form Snippet / Vor gebrauch des Moduls löschen #}
{% form
	form_to_use="{{ module.form_field.form_id }}"
	response_response_type="{{ module.form_field.response_type }}"
	response_message="{{ module.form_field.message }}"
	response_redirect_id="{{ module.form_field.redirect_id }}"
	response_redirect_url="{{module.form_field.redirect_url}}"
	gotowebinar_webinar_key="{{ module.form_field.gotowebinar_webinar_key }}"
%}

{# das Custom Form Module #}
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2.js"></script>
<script>
 hbspt.forms.create({
 region: "na1",
 portalId: "XXX", {# muss durch die HubId ersetzt werden #}
 formId: "{{ module.form_field.form_id }}",
 css: "", {# füge ich persönlich immer hinzu, damit mögliche Designanpassungen im Formular das Design nicht überschreiben #},
 onFormSubmit: "{{ module.form_field.redirect_id }}"
 });
</script>

Mehr Einstellungen findet man in der Form Api Dokumentation.

Wenn man den Autocomplete für - in dem Fall - Städte möchte, braucht man eine permanente/aktive Abfrage, welche mit einem custom JavaScript oder Serverless Functions (nur in CMS Hub Enterprise enthalten) realisiert werden kann.

Dort könnte man eine Geolocation API wie Google Maps o.ä dafür nutzen, bei Eingaben im jeweiligen Inputfeld abzufragen und damit einen Autocomplete zu erzeugen.

Hoffe das hilft weiter oder bringt zumindest auf weitere Gedanken

Viele Grüße

Anton

[MiaSrebrnjak]

Super, vielen Dank @Anton! Das hilft auf jeden Fall weiter!