amphtml
vor ein paar tagen hat google die spezifikationen für amphtml veröffentlicht und eine demo veröffentlicht, was sie in etwas damit zu tun gedenken. die demo kann man sich hier mit einem mobilen browser (oder einem mobilen user agent) ansehen (dort dann nach obama oder zum beispiel faz suchen). die spezifikationen für amphtml hat google auf github gepackt. google hat auch eine animation erstellt, die zeigten soll wie amp-seiten in den google-sucheergebnissen funktionieren könnten.
was google mit amp bezweckt ist klar, wenn man sich die demo oder die selbstbeschreibung des projekts ansieht: schnellere (mobile) webseiten. oder im sinne der gleichen facebook-idee: sofortseiten.
jeff jarvis ist naturgemäss begeistert und sieht seine idee der einfachen verteilung (distribution) von publizistischen inhalten im web durch amp gestärkt:
But I think AMP and Instant Articles are more than that. They are a giant step toward a new, distributed content ecology on the web.
wolfgang blau auch:
what excites me most about ampproject.org is how it might allow publishers to not just distribute, but aggregate more seamlessly.
tim kadlec formuliert den gedanken etwas ausführlicher aus:
It’s the distribution that makes AMP different. It’s the distribution that makes publishers suddenly so interested in building a highly performant version of their pages—something they’re all capable of doing otherwise. AMP’s promise of improved distribution is cutting through all the red tape that usually stands in the way.
This promise of improved distribution for pages using AMP HTML shifts the incentive. AMP isn’t encouraging better performance on the web; AMP is encouraging the use of their specific tool to build a version of a web page. It doesn’t feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web.
That troubles me.
und ich finde genau das spannend. google zwingt die verleger, bzw. alle die im netz veröffentlichen dazu, sich zu beschränken. so wie twitter einen zwingt sich kurz zu fassen, zwingt amp einen dazu sich den (technischen) regeln der auslieferungsbeschleunigung zu unterwerfen (was unterm strich zu erhöhtem lesekomfort führt).
das ist an sich schon eine gute sache, weil die verleger nun einen guten grund haben, von ihren vermarktern bessere, weniger arschig programmierte anzeigen zu verlangen. anzeigen sind zwar in amp-seiten möglich, müssen sich aber an bestimmte regeln halten (bis diese womöglich ausgehelbelt werden). felix salmon formuliert das im guardian (auf einer amp-seite) so:
Ultimately it comes down to power dynamics. Advertisers and media buyers have more power than any individual publisher: they can demand more intrusive ads, trackers, scripts, and publishers will comply, lest they lose revenue. But one entity is even more powerful than the ad industry – Google. If Google tells everybody to turn off those scripts, they will – and advertisers will be forced to compete on the basis of creative output, not technological firepower.
So another impact of AMP will be that news organizations will have to re-evaluate their use of third party scripts and demand use of best practices by these vendors.
noch spannender finde ich, dass plötzlich verleger, denen die idee von volltext-RSS-feeds schon immer zuwider war, plötzlich bei amp an bord zu sein scheinen. selbst die FAZ pfeffert jetzt ihre inhalte in einem format raus, mit dem leser diese inhalte plötzlich wie mit RSS lesen können. denn amp erlaubt, wie RSS, durch einen festen gestaltungsrahmen ein caching (zwischenspeichern) der inhalte durch apps, reader oder, wie oben demonstriert, suchmaschinen. konzeptionell und technisch sind die parallelen zu RSS offensichtlich. jeremy keith schreibt in seiner ausführlichen und lesenswerten amp-analyse:
So if an RSS feed is an alternate representation of a homepage or a listing of articles, then an AMP document is an alternate representation of a single article.
Now, my own personal take on providing alternate representations of documents is “Sure. Why not?” Here on adactio.com I provide RSS feeds. On The Session I provide RSS, JSON, and XML. And on Huffduffer I provide RSS, Atom, JSON, and XSPF, adding:
If you would like to see another format supported, share your idea.
Also, each individual item on Huffduffer has a corresponding oEmbed version (and, in theory, an RDF version)—an alternate representation of that item …in principle, not that different from AMP. The big difference with AMP is that it’s using HTML (of sorts) for its format.
All of this sounds pretty reasonable: provide an alternate representation of your canonical HTML pages so that user-agents (Twitter, Google, browsers) can render a faster-loading version …much like an RSS reader.
So should you start providing AMP versions of your pages? My initial reaction is “Sure. Why not?”
wie die auslieferung per amp-seite funktioniert, zeigt bereits die reader-app nuzzel. sie aggregiert und filtert links aus meinen social-media-feeds und zeigt mir empfehlungen aus meinem bekanntenkreis an. klicke ich auf den link zu einer seite die auch eine amp-version anbietet, lädt sie nicht die reguläre seite, sondern die mobil-optimierte amp-version. twitter hat angekündigt das auch so zu machen und, natürlich, auch google wird das das irgendwann in seine mobile suche integrieren.
ich bin ja schon immer ein agressiver verfechter der volltext-rss-idee, der idee, inhalte so einfach wie möglich zugänglich zu machen und niemandem vorzuschreiben wo oder wie er inhalte zu lesen hat. bereits vor 4 monaten habe ich facebooks instant articles-idee mit RSS verglichen und natürlich schlägt amp in die gleiche kerbe. mit einem unterschied natürlich: facebook und google (und apple) versuchen von anfang an wege der monetarisierung (sprich werbung) in ihre lösungen einzubauen.
es dürfte spannend sein, wie die verleger langfristig zu amp, instant articles oder ähnlichen initiativen von apple und anderen stehen werden. es ist nicht auszuschliessen, dass sie irgendwann muffensausen bekommen, angesichts des unabwendbaren kontrollverlusts. möglicherweise sind sie auch irgendwann völlig überfordert mit dem irren formate-müsli, das derzeit aus dem silicon valley geliefert wird: google hat ein eigenes format, facebook verlangt ein eigenes format und apple hat sein „apple-news-format“ noch gar nicht veröffentlicht.
mir ist das (natürlich) völlig egal, ich habe an zwei abenden das amp-format in diese seite integriert. das war nicht besonders kompliziert, im prinzip habe ich die druckseitenfunktion meines CMS missbraucht, bzw. umgebaut (und um ein paar funktionen erweitert). seiten auf dieser site lassen sich dank druck-CSS-stylesheet bestens ausdrucken (wer auch immer sowas macht), also liess sich die eingebaute druckfunktion, die über wirres.net/article/print/8649/1/6/ erreichbar war, zu einer amp-funktion umbauen. weil „print“ in der url aber doof ist, sind meine seiten offiziell über /article/amp/ ampifizierbar, natürlich auch diese: wirres.net/article/amp/8649/1/6/.
(eine noch sehr frühe amp-konversions beta-version für wordpress gibt es übrigens bereits.)
erstaunlich am ampproject ist, wie fehlerhaft es noch ist. die proprietäre video-erweiterung amp-video ist noch nicht ganz fertiggestellt, bzw. buggy, viele details scheinen noch unausgegoren und besonders witzig, googles eigenes beschleunigungswerkzeug empfiehlt dem ampproject verbesserungsmassnahmen:
auch die projektseite hält google für sehr verbesserungswürdig.
insgesamt sehe ich das amp-projekt als eine der spannensten sachen die dem web seit dem web 2.0 passiert ist. das web 3.0 wird (wieder) schlanker. und das ist in diesem fall eine gute sache.