Im CMS der New York Times kann man ein Bitcoin-Kurs-Widget einfügen

Bitcoin finde ich ja faszinierend,  und da ist mir etwas an dem aufgefallen, was die großen Medien so alles für Möglichkeiten haben (anders als ich mit meinem winzigen Entwicklerteam, cue the Empörung…): In einem Artikel über die seit „The Social Network“ übel beleumundeten Winklevoss-Brüder (und Zwillinge) konnte der Redakteur oder der Web Producer einfach den Bitcoin-Kurs als ein Widget einfügen:

How the Winklevoss Twins Found Vindication in a Bitcoin Fortune – The New York Times:

Continue reading →

Post-its auf digital: Entwürfe im CMS. Foto: Unsplash / Kelly Sikkema

Edge Case der User Experience: viele Entwürfe in WordPress

Kennen Sie das? Die Kollegen haben für ihre Gedankenstütze Klebezettelblöcke auf dem Schreibtisch liegen. Und da wird notiert, was länger als zwei Minuten dauern würde. Das ist gute Getting-Things-Done-Praxis. Ich habe das Buch von David Allen („Getting Things Done“ eben) damals verschlungen, und Teile davon in meine Praxis umgesetzt. Außerdem habe ich es schon 2x verschenkt. Weil ich nämlich eben auch ein Klebezettelmessie bin. Die Kollegen, von denen ich da spreche, bin zu einem Gutteil auch ich selbst. („Experten sagen…“)

Meine Klebezettel finden sich jetzt in Wunderlist ToDoist. Da habe ich verschiedene Listen angelegt, etwa für die Arbeit mit den aktuellen To-Dos, das ist die aktivste. (Außerdem müsste-man-mal-Listen und eine Liste für angehende Praktikant*innen bei uns.)

Aber auch fürs Bloggen habe ich einen Themenspeicher dort angelegt. Genauer: für jedes Blog ein eigenes Projekt. Der Titel des Eintrags ist dann der geplante Titel des Blogposts.

Manchmal reicht der Speicher aber nicht. Besichtige ich die dürren, nur aus dem Titel des künftigen Blogposts bestehenden Notizen, Monate später dort, wo gern auch noch mal Rechtschreibfehler enthalten sind, fällt mir oft nicht mehr ein, was ich eigentlich bloggen wollte. (Notiz an mich selbst: gleich Skelett des Beitrags mit anlegen, im Kommentar zur Aufgabe.)

Der noch bessere Weg ist es daher für mich, bereits einen Entwurf für einen Post mit einer Outline mit Stichworten anzufangen. Dass mir Posts gern mal aus dem Ruder laufen, vor allem im Einstieg – geschenkt. So eine Outline zwingt im Nachgang zu etwas mehr Sorgfalt. Derzeit liegen in meinem Blog mehr als 190 Entwürfe, die ich auch versuche abzuarbeiten. Warum so viele? Weil ich aus meinem Lieblingsclient zum Bloggen, MarsEdit, wegen der geplanten Neuinstallation alle ins Blog geschickt habe. Gern auch mal in unterschiedlichen Zuständen. Versionskontrolle von Blogpostentwürfen wäre auch ein Thema für einen Post. Heute soll es aber über die Übersichtlichkeit des Redakteursbackends in CMSen gehen.

Es ist ganz sicher ein Edge Case in der CMS-Entwicklung. Die User Story liest sich auch nicht ganz schmeichelhaft:

Als Redakteur möchte ich eine Ansicht im CMS-Backend haben, die es mir ermöglicht, den Zustand vieler (n= 50-100) angefangener Beiträge auf einen Blick einzusehen, damit ich schneller entscheiden kann, welchen Blogpost ich als nächsten fertigstelle.

Als Product Owner würde ich so eine Story auch nach hinten priorisieren. Der Business Value ist zweifelhaft. Einem Stakeholder in einem solchen Projekt würde ich sagen: Dafür ist das System nicht vorgesehen. Da sollen die Nutzer weniger anfangen und mehr beenden.

Aber warum ist das eigentlich so und wie müsste das in einer besseren Welt aussehen? Es wäre eine Liste mit Spalten, so ähnlich wie in Outlook. Stürzt das Programm ab, so speichert es in der Regel die bereits begonnenen Entwürfe ab. Es gibt dann nicht nur einen Eintrag mit dem Betreff, sondern auch dem Empfänger und einen Zeitstempel der letzten Änderung an dieser Mail. Seltsamerweise sind aber die meisten Outboxen oder Postausgänge nicht so durchkonzipiert wie die Inboxen. Inboxen sind für schnelle Abarbeitung ausgelegt, Outboxen nicht. Offenbar weil die Konzepter von einer 1:n-Beziehung ausgehen, vermute ich. Alle (=n) können dir schreiben, aber nur 1 kann nach außen senden. (Haben die eine Ahnung. Wer unter Andruckstress und hartem Redaktionsschluss produziert hat, kann erstaunlich viel produzieren. Zum Beispiel auf der Heimfahrt – da gehen zwei vollständige Blogposts, ohne Links, oder etwa drei bis vier Outlines.)

Das gewünschte System würde die Einträge also in einer stufenlos verstellbaren Ansicht anbieten – mehr Details, wenn der Autor das gern hätte. Wie man das Problem neu betrachten kann, beweist für mich die Desktop-WordPress-App für den Rechner. Anders als beim klassischen wp-Admin, dem beliebten und auch verhassten Backend der Blogsoftware, ist für das Anzeigen eines Posts da nicht eine Zeile, sondern gleich eine ganze Karte. Nimmt noch mehr Platz weg, ist zum Abarbeiten aber ein bisschen hilfreicher, weil man erahnen kann, worum es in dem Entwurf geht:

Dieses Stück Software heißt im WordPress-Slang Calypso, und der Talk, den ich dazu auf dem WordCamp Europe 2016 in Wien gesehen habe, zeigte mir: Bei Automattic macht man sich wirklich Gedanken, wie man die User Experience verbessern kann. Gleichzeitig muss man eben die Legacy-Software-Probleme des beliebtesten CMS der Welt beachten. Ein… weit aufgespreizter Spagat, um das nett zu sagen.

Die meisten Redaktionssysteme gehen auch von einem mehrstufigen Publishing-Workflow aus. Autor schreibt etwas, schickt das zum abnehmenden Redakteur, der gibt frei und plant den Beitrag ein. So ist etwa die Dashboard-Ansicht in einem anderen CMS, das ich gut kenne, eZ Publish zu verstehen.

Auch Non-CMS-Web-Publishing-Lösungen wie Jekyll lösen das Problem nicht. Dort hat man dann nur in dem Posts-Ornder der Installation lokal einen Haufen Markdown-Dokumente vorliegen, die man mit dem Finder oder dem Explorer previewen kann. Auch nicht ideal, um den Überblick zu behalten.

Meine Lösung ist jetzt jedenfalls pragmatisch. Ich bin kein Coder, daher kann ich mir nicht das Interface bauen, das ich brauche. Ich räume auf. Ein Post nach dem anderen. Ein CMS ist auch nur wie ein Wohnzimmer. Wenn ich mich da nicht mehr wohlfühle, muss ich einfach mal aufräumen. Da kann ich nicht einfach nach einer Fee rufen, die für mich klar Schiff macht. Es ist eine Herkulesarbeit, aber dann habe ich genug Blogposts im Köcher, die im Urlaub erscheinen können.

Nur noch 194 to go.

Photo by Kelly Sikkema on Unsplash

Gutenberg soll für WordPress so epochal sein wie Gutenberg für die Welt. Illustration: Flickr-Nutzer Frédéric BISSON

WordPress: Gutenberg verstehen

Gutenberg verstehen, das war der Plan. Am besten von einem WordPress-Experten erklären lassen, das wäre perfekt.

Von meinem veritablen Respekt vor WordPress-Community-Legende Mor10 habe ich schon erzählt. Morten Rand-Hendriksen ist ein WordPress-Dozent, dessen Kurse sich schon hunderttausende Nutzer bei Lynda.com/Video2Brain angesehen haben. Das erste Mal habe ich ihn in Wien beim WordCamp Europe 2016 sprechen gesehen.

Jetzt, im Dezember 2017, hat er wieder zugeschlagen, also nur im übertragenen Sinne, er ist einfach viel zu freundlich. Auf dem WordCamp US 2017 in Nashville, dem größten zweitgrößten WordPress-Treffen weltweit, hat er seine Gedanken zum großen WordPress-Projekt Gutenberg vorgestellt.

Für die, die nicht wissen, was Gutenberg im WordPress-Kontext bedeutet

WordPress gilt als das erfolgreichste Web-CMS der Welt. Dabei ist es das nicht. Es ist ein Blog-CMS. Erst mit den geeigneten Erweiterungen, Plugins, wird WordPress als CMS für Magazin-Webseiten tauglich. Das haben wir bei TargetVideo gemacht, und unseren eigenen Stack für unsere Anforderungen bei Amazon Web Services kreiert, und tausende andere Agenturen, Startups und KMUs tun das auch, in einem extrem ausdifferenzierten Ökosystem. Es gibt alles schon einmal.

Was heißt das? Es gibt für viele Standardanfragen ein Standardset an Features, was man installiert, und dann kann WordPress auch das. So wie Neo Kampfsportarten in „Matrix“ lernt.

via GIPHY

Auf einmal geht es. Und WordPress kann Kung Fu – mit dem richtigen Theme. Alles geht – das ist der Plugin-Theme-Weg, den Millionen von WordPress-Nutzern kennen.

Back to black: Gutenberg

Mit Gutenberg wird sich das ändern, und ich hatte mir schon lange nicht mehr den Fortschritt der Entwicklung bei dem, was ich für den neuen Editor hielt, angesehen. Jetzt also das Video von Mor10. Und in 27 Minuten verrät er alles, was man wissen muss. Ich schweige kurz. Video ansehen, dann geht es weiter: https://wordpress.tv/2017/12/10/morten-rand-hendriksen-gutenberg-and-the-wordpress-of-tomorrow/

Einige der Fragen, die am Anschluss gestellt werden, sind tatsächlich gut. Das ist selten bei solchen Veranstaltungen. Und im Q&A-Teil gibt auch Morten Rand-Hendriksen zu, dass er zuerst Gutenberg als Editor-Ersatz gesehen habe. Aber das ist nicht alles. Ich hätte gefragt, wie ACF und Gutenberg zusammengehen. Aber dafür gibt es auch ein GitHub-Issue – schon seit Juni.

Gutenberg ist der Versuch, WordPress ohne einen deftigen Versionsnummernsprung, wie das andere Software (auch Konkurrent Typo3) macht und gemacht hat, zu einem voll flexiblen Inhalteverwaltungssystem zu machen. 4.9.1 ist jetzt, Gutenberg kommt (vielleicht/wohl) mit 5.0. Richtiger wäre wohl 6.0. Oder WordPress 95.

Und das geht einher zwar mit einer engen Verknüpfung von Form und Inhalt. Und das ist auch der Punkt, an dem ich eher kritisch bin, was das angeht. Viele professionelle WordPress-Projekte entstehen als decoupled frontend, auch bei TargetVideo.

WordPress-Erfinder und benevolent dictator for life Matt Mullenweg gibt den Rahmen und die Begründung für Gutenberg in wolkigen Phrasen wieder, wie er das immer macht, in seinem Post

„We called it Gutenberg for a reason“:

The printing press ushered in social, political, and economic sea changes. Gutenberg changed everything. WordPress has always been about websites, but it’s not just about websites. It’s about freedom, about possibility, and about carving out your own livelihood, whether it’s by making a living through your site or by working in the WordPress ecosystem itself. We’re democratizing publishing — and democratizing work — for everyone, regardless of language, ability, or economic wherewithal.

Wenn man das zersägt und weiter denkt, gibt er damit zu: Gutenberg soll alles ändern für WordPress. (Eine Softwareschmiede, HumanMade, die in der WordPress-Welt Rang und Namen hat, bietet sogar ein Whitepaper für diese dramatische Veränderung an.)

Was genau ändert Gutenberg?

Der bisherige Content-Blob, das Objekt, in das alles hineingepumpt wurde, und das Datenbankabfragen etwa nach einem Wechsel des Page Builder-Plugins fast nur noch Müll ausspucken ließ, wird durch etwas strukturierteren Content, kleinere Häppchen, die so genannten Blocks ersetzt. Der Wandel zu Gutenberg beginnt am Editor, wie Mor10 erklärt, weil das einfach der logische Anknüpfungspunkt ist. Aber auch Sidebar und Co. können sich durch Gutenberg massiv ändern.

PageBuilder sind eine Plage im WordPress-Kontext, einfach deshalb, weil sie so mächtig sind und dem System Funktionen gibt, die es out-of-the-box (Core WordPress) nicht hat. Mor10 hat PageBuilder auch erst für die ersten Opfer von Gutenberg gehalten, hat aber mittlerweile seine Meinung etwas revidiert.

Das neue System, Blocks statt Blob, ist epochal anders als bisher, und eine der beliebtesten Agenturen aus der WordPress-Welt, Yoast, hat das auch im Oktober noch kritisiert:

Here at Yoast, we are worried about the use of new technology combined with the introduction of big new concepts. This is bound to make for a rocky experience.

Morten ist ganz begeistert von den neuen Möglichkeiten, er ruft alle zu Experimenten auf. Ist auch richtig, aber mit wenig Geld gilt: Ich habe Bedenken, weil das alles auch Geld kostet – neue Wege ausprobieren, verwerfen und wieder neue Wege finden.

Das Umstellen der bestehenden WordPress-Installationen, die für ganz bestimmte Usecases mit Tonnen von Plugins angepasst wurden, wird viel Arbeitszeit kosten. Schlaue WordPress-Community-Mitglieder haben ihren Kunden schon empfohlen, dafür Budget fürs nächste Jahr einzuplanen. Eine Stimme:

The Gutenberg transition comes at a very high cost for small businesses. These businesses usually only have the resources to deal with their own daily business, but that’s pretty much it. However, with Gutenberg development processes need to change, products need to be modified or completely recoded, people need to improve their coding skills (learn JavaScript deeply), documentation needs to be rewritten, customers need to be educated, new staff needs to be hired to deal with the additional workload and so on. All of this while there is not much time left.

Oder aus einem GitHub-Ticket des Marketing-CoReps von WordPress zum Thema:

Small businesses often come to WordPress for the reasons we promote: technical SEO, ease of publishing, owning your own data. Convincing them to stay, when another option may be cheaper (WIX, Squarespace, even Dot Com), may become a challenge. Businesses don’t make decisions based upon community loyalty; they make decisions based upon finances.

Possible Solution

I would love to see the version that will be shipped with 5.0 set sooner than later. This will allow WordPress educators, agencies, businesses, the Make Team, and development shops to prepare the general public for the rollout with marketing materials, documentation, and, of course, compatible code.

Was ist mein Fazit zu Gutenberg?

Die Umstellung auf Gutenberg sollte länger dauern, als das bei einem neuen Release normalerweise der Fall wäre. Zu viel ändert sich, was kleine Teams und kleine Webseiten überfordern würde. Ich wollte nur meine Gedanken mal in einen längeren Faden knüpfen.

Illustration: Flickr-Nutzer Frédéric BISSON

Ich hasse Klatschen

Für mich hat der Umstieg vom Herz auf die klatschende Hand bei Medium genauso viel Verdruss gebracht wie denjenigen, die das Herz bei Twitter kritisiert haben. So habe ich bei Medium eine Geschichte gelesen, die ich unterstützen wollte:

I built a chatbot in 2 hours and this is what I learned: „Clapping shows how much you appreciated Shival Gupta’s story.“

(Via.)

Aber Klatschen für eine Geschichte, die eher beruflich relevant ist?

Das passt nicht zu mir. Ich klatsche nicht bei Schlagern mit und auch nicht bei einer Polonaise. Aber ohne das Feedback kann ich mich nicht bedanken.

Können wir nicht bitte zurück zum Herz gehen, Medium?

Mein IndieWebCamp 2.0

Manchmal muss man Metaphern benutzen, die man selbst eigentlich nicht mag. Alles, was Versionsnummer hochzählt, mag ich nicht. Bei meinem ehemaligen Arbeitgeber ProSiebenSat.1 gab es für den Trend zum nicht-linearen TV-Konsum den Begriff TV 3.0. (Was 2.0 war, wurde meines Wissens nach nicht definiert.) In der Fachpresse der Businesskasper und Anzugträger gibt es den Begriff Industrie 4.0. Es meint letztlich die Digitalisierung der Industrienation Deutschland. Denn Deutschland hat den Trend zu mehr Software statt Hardware ein bisschen verschlafen und ist dort sicher nicht mehr Weltmeister.

Ich war jetzt also auf meinem zweiten IndieWebCamp in Nürnberg, weil das erste so gut war. Beim ersten Besuch, über den ich hier auch geschrieben habe, habe ich mir das PRogrammieren an meiner eigenen Webseite noch gespart. Die Sehnsucht nach der Familie war groß, sodass ich den Besuch in Nürnberg damals abgekürzt habe. Diesmal wollte ich aber rund um das Buch, an dem ich schreibe, mir auch eine zeitgemäße Autorseite erstellen. Dominic Grzbielok, Blogger, Journalist (Ironie, Freunde!), Produktmanager, Teamlead, Projektmanager, Buchautor. 

All das wollte ich mit Jekyll, einem Webseitengenerator für technisch affine Digitalmenschen, erstellen. Das habe ich nach einem halben Tag Problemen auch geschafft, die Seite ist auch inzwischen online. Schon, um mich unter Druck zu setzen, auch weiter an ihr zu arbeiten: http://dominic.grzbielok.de/

Mit das Beste daran: Damit sind in meinem Hosting-Paket wieder mal 200 MB frei geworden, weil ich die WordPress-Seite, die ich mal auf einen blauen Dunst in 2014 angefangen habe, gleich gelöscht habe. 200 MB für vier Artikel erschien mir etwas übertrieben. (Wenn ich noch ein paar weitere alte Projekte lösche, kann ich vielleicht das Paket auch downgraden, das ich bei dem Anbieter habe. Das ist ein eher mittelfristiges Ziel.)

Was habe ich also geschafft an diesem Code-Wochenende?

  • Informationsarchitektur für die Seite und auch die Homepage erstellt
    • Am meisten gleicht das einer Webseite, die ein Autor für sich erstellen würde – zum Start will ich in etwa die Informationsdichte eines Onepagers haben. Also einer Website, auf der man mit Scrollen allein navigieren kann und einen Überblick bekommt.
  • Trello-Board mit To-Dos angelegt und befüllt
  • Jekyll-Seite geklont, Theme lief nicht
  • wieder, nach Anpassungen gelöscht (Rinse and Repeat, 3x)
  • wieder, neues Theme ausprobiert
  • Gem für Push zu S3 installiert
  • S3-Bucket angelegt
  • CloudFront-Distribution angelegt
  • Begonnen, an Jekyll-Collections zu arbeiten

Damit bin ich nicht zufrieden. Aber ich bin auch kein Entwickler. Vielleicht habe ich mal irgendwann Zeit für ein richtiges Bootcamp. Lust hätte ich ja schon. Meine etwas weniger ambitionierte Jekyll-Seite zum Buch habe ich ja auch hinbekommen: http://www.relaunch-buch.de/ 

Ich habe bisher noch gar nichts über das Camp geschrieben. Aber wie immer war die Atmosphäre außerordentlich entspannt und kollegial, auch dank eines Code of Conducts, wirklich senioriger IndieWebCamp-Vordenker (Gründer Aaron Parecki; Gastgeber Joschi Kuphal; Agenturgründer Jeremy Keith). Aber gemeinsam allein haben wir alle an unterschiedlichen Projekten gearbeitet, daher ist ein direkter Vergleich kaum möglich.

 

 

 

 

 

The WordPress 1%: Lektionen aus dem Scaling auf 1 Million Nutzer

Der Aufruf war unmissverständlich: Wenn du zum ersten Mal auf einem WordCamp bist, mache eine Session. Ich habe das nicht geplant, und ich wollte es auch nicht tun. Aber dann kam der Moment der Sessionplanung beim WordCamp Cologne 2016 und da war noch eine Lücke – also habe ich meine Session gepitcht.

Seit einem Jahr beschäftige ich mich intensiver mit WordPress. Und zwar als CMS für Magazinseiten. Das ist schon mehr als WordPress von Haus aus eigentlich kann. Das Besondere an Magazinseiten ist nämlich, wenn man mit menschlichen Redakteuren zusammenarbeitet, dass diese die Magazinseiten auch händisch bestücken wollen mit Teasern. Im alten Zeitschriftensprech hieß das Komponieren. Etwas Ähnliches tun auch Onlineredaktionen noch. Die Mischung muss auch hier stimmen. Henri Nannen wäre froh, wenn er das noch mit erleben könnte.

Und so haben wir uns in der Anfangszeit des Verticalbetriebs bei TargetVideo für den Site Builder Visual Composer entschieden. Der stellte sich dann bald als eher ein Problem denn als eine Lösung heraus. Deshalb sind wir dabei, den aus unseren Verticals wieder zu entfernen. Das war eins der wichtigsten Learnings.

Aber auch andere betreiben große WordPress-Installationen, von denen kann man lernen. So etwa von zwei Artikeln, die haarklein schildern, wie man auf AWS WordPress zum richtigen Laufen bringt. Das ist nämlich nicht trivial. WordPress ist nicht dafür gedacht, auf einem verteilten Stack zu laufen. Dafür muss man einiges tun.

Anstatt sich meinen Vortrag anzusehen, kann man auch einfach zwei Blogposts folgen, die ich aus vollem Herze empfehlen kann: beim Cloudonauten (https://cloudonaut.io/wordpress-on-aws-you-are-holding-it-wrong/) und bei Big Bite Creative (https://bigbitecreative.com/scalable-wordpress-with-aws-elastic-beanstalk/)

Mir ging es bei dem Vortrag nicht um Kundengewinnung oder Kudos von der Community. Mir ging es um Feedback: Ist der Weg mit Elasticache der richtig? Kann man mit Advanced Custom Fields Visual Composer ablösen? Oder kommt man dann bloß in eine andere div-Hölle?

Hier sind meine Folien. Außerdem habe ich sie bei Slideshare zur Verfügung gestellt, damit ich dort von der besseren Auffindbarkeit profitieren kann.

Sobald die Videos online sind, füge ich im folgenden Absatz noch den Link ein:

Und hier ist mein Vortrag, bei dem es sich lohnt, zur Diskussion zu skippen – ich hoffe, die wurde auch aufgenommen. Für die Diskussion habe ich den Vortrag nämlich gehalten. Das Feedback, das ich da bekommen habe, hätte ich in so kurzer Zeit im Netz in der Community nie zusammenbekommen.

Rückblick: Wie war das WordCamp Cologne?

Ich habe vor kurzem darüber geschrieben, dass ich selbst überrascht war, dass ich mich für den Besuch des WordCamp Cologne entschieden habe. Aber irgendwas an der Erfahrung in Wien und meiner kurzen (1 Jahr) intensiven Beschäftigung mit WordPress hat mich veranlasst, noch mal 20 Euro für ein Ticket und viel mehr für die Reisekosten auszugeben. Und ich bin glücklich, dass ich das getan habe.

Gehen wir einen Schritt zurück. Meines Wissens gab es in München noch nie ein WordCamp, und das nächstgelegene in Nürnberg habe ich 2016 nicht besucht, weil ich lieber zum gleichzeitig stattfindenden Indie Web Camp gefahren bin (war auch richtig so, ich habe über das Camp geschrieben). So war das bisher größte WordCamp überhaupt, das 2016er WordCamp Europe in Wien, mein erstes WordCamp. Und das ist kein typisches. Es ist eine Erfahrung, die eher an eine Konferenz grenzt – mit vollem Community-Anschluss. 2000 Leute.

In Köln waren es um die 100, da konnte man als guter Netzwerker mit einem Großteil sprechen. Die Qualität der Teilnehmer war wirklich beeindruckend. In einer Kaffeepause stellte ich auf einmal fest, dass ich mit Bernhard Kau rede, dessen Schritt-für-Schritt-Anleitung für eine Integration von Elasticsearch auf Heroku mit ElasticPress ich jetzt schon zwei mal befolgt habe. Anderen Teilnehmern konnte ich Tipps aus meiner Praxis geben. Dafür sind doch Community-Treffen da. Deine Helden/Vorbilder zum Anfassen, und du gibst etwas zurück.

Ich bin kein guter Netzwerker, Partys sind für mich der Horror. Daher finde ich Veranstaltungen wie die in Köln, wo die Anzahl der Teilnehmer noch unter der Dunbar-Zahl bleibt, sehr angenehm. Und bei einem Bar-Camp mit immer vier Paralleltracks bietet sich die Gelegenheit zum Austausch in den Sessions (7 hintereinander, sehr viel Futter), in den engen Gängen in der Kölner Co-Working- und Startup-Location Startplatz in den Kaffeepausen und beim leckeren Essen.

Bei vier Tracks ist es immer schwer, über „DAS“ WordCamp Cologne oder die Konferenz zu schreiben, weil jeder eins/eine andere erlebt habt. Für mich hat sich Köln sehr gelohnt. Ich habe einen guten Überblick über die Szene bekommen, von WordPressdesignern bis hin zu Plugin-Autoren.

Ich bin vor allem froh über einige neue Kontakte, die sich bereits per Mail, Twitter oder sonst vertiefen ließen. Und darüber, dass ich mich dazu habe hinreißen lassen, eine Session beim WordCamp Cologne zu leiten. Ganz spontan. Ohne Vorbereitung. Darauf bin ich stolz.

Alle guten Namen, Domains, Marken sind weg

Dass ich Podcasts höre, ist bekannt. Im Sommer und Herbst 2016 ist Automatic ein recht umtriebiger Podcast-Sponsor. Das Technologieunternehmen vertreibt direkt ein Modul, das man auf den ODB2-Port im Auto aufstecken kann.

Ein anderes Thema, das mich beschäftigt, ist WordPress. Über meine Faszination für das Blog-CMS, das als CMS verstanden wird und auch genutzt wird, denke ich den lieben langen Arbeitstag nach, und hier tue ich das oft genug auch. Die Firma, die Matt Mullenweg für WordPress gegründet hat, heißt Automattic – so wie alles rund um Mullenweg nach seinem Vornamen heißt. Sein Blog ist ma.tt. Wahrscheinlich die coolste exotische Domain, die ich kenne.

Wie soll man also als Technik-Fan, der ich bin, die beiden Produkte auseinander halten? Beim Hören geht das nicht. Automatic. Automattic. Klingt gleich. Zwar sind die in sehr unterschiedlichen Segmenten unterwegs, diese ganz unterschiedlichen Firmen. Aber Automatic tut mir leid. Gegen 25% des CMS-Marktes kommst du in meinem Kopf nicht an.

Das größte WordCamp kostet 40 Euro. Die größte Typo3-Konferenz 590 Euro

Und zwar allein für das Ticket. Die Reisekosten sollten bei beiden Städten (Wien, München) etwa gleich hoch sein. Hier gibt es die Tickets: t3con.

Das ist kein besonders hoher Preis für eine Konferenz, Google IO oder WWDC sind teurer, aber dennoch ein weiteres Indiz für die Beliebtheit von WordPress. Bei beiden Ticketpreisen kommen ja noch die Reisekosten hinzu. Die kann man staffeln – von Couchsurfing bis zum 5-Sterne-Hotel ist alles dabei.

Aber eine Reise für annähernd 1000 Euro – die muss man als Mitarbeiter erst einmal gegenüber dem Chef / der Reisekostenverantwortlichen verantworten. Das ist mir in meiner Karriere nur bei sehr wichtigen Events gelungen. Etwa bei DER Messe zu einem Thema, wo man mit einem Stand vertreten war. Für eine Entwicklerkonferenz in Deutschland ist das eher schwierig, zumal in kleinen Unternehmen.

AMP bei WordPress: zu empfehlen oder nicht?

Als Konkurrent zu Facebook kopiert Google oft Initiativen des Social-Media-Giganten. (Das geht übrigens in jede Richtung zwischen Apple, Facebook, Google und Amazon, und Microsoft auch.) Eines dieser Projekte ist AMP, die Accelerated Mobile Pages. Diese sind anders als bei Facebook nicht nur in einer App verfügbar, sondern stellen eine besondere Form des HTMLs dar, das zu schnelleren Seitenaufbauten führen soll.

Wir können uns an dieser Stelle darüber streiten, ob das wirklich ein Subset von HTML ist oder etwas Anderes. (Ich bin der Meinung, es ist eine nicht standardkonforme Abweichung, die Chrome dennoch interpretieren kann.) Aber das ist Haarespalten. Wichtig ist es, dass AMP Vorteile bringt.

Wie schwierig ist es, das zu implementieren? Die Antwort: Wenn man auf Beitragsbilder verzichten kann und auch auf den Visual Composer, dann ist es ganz einfach. Einfach das AMP-Plugin von Automattic nehmen und installieren, dazu noch Glue von Yoast installieren – damit kann man Farben ändern. Umrühren, Cache leeren – fertig.

Ein paar mehr Schritte werden aber notwendig sein, wenn man das mit dem Visual Composer kompatibel machen will.

Für den Nutzer und auch das Google-Ranking ist eh auf alle Fälle zu empfehlen. Die Washington Post setzt es etwa flächendeckend ein. Die ge-AMP-te Version ist auf alle Fälle schneller, wie ein Blick mit GTmetrix zeigt:

www_washingtonpost_com__www_washingtonpost_com___GTmetrix-AMP-Vergleich

Bei einer normalen Site sollten definitiv Vorteile zu erzielen sein, auch weil die Abhängigkeit von anderen Plugins relativ gering ist. Ein WordPress mit AMP sollte schneller sein als eins mit vielen Plugins. Und das ist dann das eine Plugin mehr wert, finde ich.

Ob Google dann die AMP-Seiten belohnt, und diese Aktion nicht nur für große Verlage und Publisher gilt, muss sich erst noch zeigen. Auch bei diesem Blog habe ich das jetzt eingerichtet. Die Ladezeitvorteile sind auch hier enorm:

krautsource-info-waterfall-amp-nonamp