Redirecting to AMP (reader mode) for mobile

I’m not a big fan of AMP but I do have it active here on this blog using the official AMP plugin for WordPress, using it in “Reader” (aka “classic”) mode. That’s as far as I want to take it, but suppose (as was the case for an Autoptimize/ Critical CSS user I was helping out) you want to redirect all mobile traffic to AMP, then you could use below code snippet to do just that.

add_action('init','amp_if_mobile');
function amp_if_mobile() {
  $_request = $_SERVER['REQUEST_URI'];
	if ( strpos( $_request, '?amp' ) === false && strpos( $_request, '&amp' ) === false && ! is_admin() && wp_is_mobile() ) {
    if ( strpos( $_request, '?' ) === false ) {
      $_amp = '?amp';
    } else {
      $_amp = '&amp';
    }
    $amp_url = home_url() . $_request . $_amp;
    wp_redirect( $amp_url );
    exit;
  }
}

It might be a little rough around the edges, but it (mostly) gets the job done 😉

Mijn m.deredactie.be-alternatief nu ook met Sporza

futttas-sporzaHet was exact een jaar geleden dat ik nog iets over mijn m.deredactie.be-alternatief schreef en het was nog langer geleden dat ik er aan gesleuteld had. Omdat ik tussen mijn echte werk en mijn WordPress plugin spielereien nog wat tijd had, heb ik één en ander verbeterd;

  1. Je kunt nu ook Sporza-nieuws lezen
  2. Op PHP-installaties zonder APC-support (apc_store/ apc_fetch) wordt de cache nu op disk bijgehouden
  3. Op PHP-installaties zonder CURL-support wordt nu teruggevallen op file_get_contents
  4. Een reeks kleinere UI-verbeteringen en fixes voor PHP-notices
  5. Getest op PHP 5.2, 5.5, 7.0 en HHVM (op openshift)

De (crappy) sourcecode staat nog steeds op GitHub, bug-meldingen of pull-requests zijn daar zeer welkom 🙂

Mobile web vs. Native apps; Forrester’s take

So web is going away, being replaced by apps? Forrester researched and does not agree;

Based on this data and other findings in the new report, Forrester advises businesses to design their apps only for their best and most loyal or frequent customers – because those are the only one who will bother to download, configure and use the application regularly. For instance, most retailers say their mobile web sales outweigh their app sales, the report says. Meanwhile, outside of these larger players, many customers will use mobile websites instead of a business’ native app.

My biased interpretation; unless you think can compete with Facebook for mobile users’ attention, mobile apps should maybe not be your most important investment. Maybe PPK conceeded victory too soon after all?

QuirksMode: “The problem with Angular”

I’ve previously already expressed my doubts about the how well-suited AngularJS is for mobile web development (in Dutch, though, as I was discussing the merits of the mobile news-site of the Flemish broadcaster VRT).
QuirksMode’s PPK dove in a lot deeper in his “The problem with Angular“, stating amongst other things;

Angular is aimed at corporate IT departments rather than front-enders, many of whom are turned off by its peculiar coding style, its emulation of an HTML templating system that belongs on the server instead of in the browser, and its serious and fundamental performance issues. I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognize Angular’s performance problems.

The performance problems PPK mentions are not the initial download of angular.js in the browser (which is one of the reasons why I dislike it), but the fact that angular.js does a huge amount of DOM-manipulations, which are costly, especially on mobile. This quote says it all;

Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers — especially not the mobile ones. This job belongs on the server.

But do read PPK’s article for more insights on Angular and the road it is heading down with AngularJS 2.0!

Uw eigen mobielere deredactie in 5 stappen

openshift configureer uw redactieuwredacie op openshift uwredactie op openshiftOok al kunt ge mijn alternatieve mobiele redactie hier bekijken, dan zout ge toch, om redenen die geheel de uwe zijn, misschien liever uw hoogst persoonlijke redactie hebben?
Wel, dat kan in 5 eenvoudige stappen dankzij Openshift, het freemium PAAS platform van Red Hat en dat gaat ongeveer zo:

  1. Maak een gratis account aan bij Openshift
  2. Klik op “Create your first application now
  3. Vul PHP in in het zoekvenster en selecteer de PHP 5.4 cartridge
  4. Vul een naam in voor de public URL, copy/paste https://github.com/futtta/redactie in het source code veld en klik op “Create application
  5. Even geduld terwijl uw eigenste redactie wordt aangemaakt. In het laatste scherm kunt ge eventueel git access configureren (“Will you be changing the code of this application?”) of direct op “Visit app in the browser” (in mijn geval naar http://mijnredactie-futtta.rhcloud.com/) klikken.

Spreading the news, tiens!

Verder sleutelen aan mijn m.deredactie.be-alternatief

futtta-redactie-tabs-compressorDat ze daar aan de Reyerslaan niet stilzitten; http://m.deredactie.be/ is nu ook bruikbaar op een JavaScript-loze browser! Dat klinkt misschien onbelangrijk, maar zo een basis-versie die werkt, ongeacht de browser, is een grote stap in wat ik de juiste richting acht. Spijtig genoeg blijft de site voor de rest onder Google’s verwachtingen en de laadtijd en total download size blijven een mobiele site onwaardig. Daar ten gronde iets aan veranderen binnen het kader van de gekozen architectuur (MVC in de browser) zal niet eenvoudig zijn.
Daarom ben ik dus ook niet blijven stilzitten en sleutelde ik verder aan mijn alternatief voor m.deredactie.be. Video werkt nog steeds niet (misschien moet ik eens kijken of ik iets kan doen met de JS-file van de VRT), maar onder andere deze verbeteringen zijn er wel bij:

  • Op de homepage hebben “hoofdpunten”en “laatste nieuws” nu elk een eigen tab (ik ben zelf niet overtuigd van de kleurenkeuze, maar soit).
  • Op de detail-pagina’s kun je artikels delen op sociale media (met lyteshare.js)
  • De html is opgekuist en valideert nu bijna op de W3 validator (bijna maar nog niet helemaal; de imgsrc attributen op placeholder-divs voor image lazyloading mogen niet).

Daarnaast zitten er nog een handvol bugfixes en andere kleine wijzigingen in, cfr de  “done” lijst op Trello. Pagespeed Insights score en webpagetest.org testresultaten zijn nog steeds “up to snuff”. De geüpdate code staat op GitHub en het resultaat (als je het projectje niet zelf wilt/ durft/ kunt installeren) zie je op http://futtta.be/redactie/.

Mijn alternatief voor m.deredactie.be

Dat ik niet content was met de vernieuwde mobiele redactie.be schreef ik hier al. Maar commentaar spuien kan iedere blogger, afbreken is makkelijker dan opbouwen en het beste argument is een uitgewerkt alternatief. Vandaar; ik werkte de afgelopen maanden tussen de soep en de patatten aan een eigen “progressive enhanced” Proof of Concept van een mobiele deredactie.be (in PHP) die op alle browsers werkt, minder mobiele data verbruikt en sneller rendert (hier moet ge zijn, ongeduldigaard).
Waarom ik denk dat deze aanzet beter is dan de officiële versie van de VRT? Wel, de POC

  • futttas-redactie-pagespeed-insightsis op elke browser te bekijken, ook als er geen (of slechte) JavaScript-ondersteuning is. Opera Mini? Lynx? De Netfront op uw grootvader’s Nokia? Geen probleem!
  • kan makkelijk uitgebreid worden om afhankelijk van context de presentatie anders toe doen, bv. op tablet de nieuwscategorieën permanent aan de linkerkant
  • de download-size is véél kleiner (en vreet dus minder van uw mobile data-abonnement); 472KB (document complete) en 979KB (fully downloaded) vs 126 en 127KB
  • de site rendert véél sneller (en spaart uw batterij dan ook meer); 7.419s vs 1.557s
  • Google PageSpeed Insight geeft m.deredactie.be een mobile score van 61/100 tegenover 97/100 voor deze POC (91/100 indien de data niet uit de cache, maar van VRT komt)

Je kunt:

Een paar technische feitjes;

  • De basis-versie werkt volledig zonder JavaScript. Als JS aanwezig is en “up to snuff” (cfr. cut the mustard), wordt de ervaring “verrijkt” (fixed header, uitklapbare navigatie, lazy-loading van images …).
  • Alle CSS en JS staat -weliswaar slordig maar oh zo performant- inline (behalve aniHead.js, een onafgewerkte en dus inactieve “verrijkings”-PoC in de PoC, type aniHead(); in de console om te activeren).
  • De POC gebruikt dezelfde data-feeds als m.deredactie.be, maar haalt die server-side binnen (dependancy; Curl)
  • Data wordt -gecomprimeerd- gecachet in APC cache (dependancy; APC)
  • Externe HTML in de data-feeds (iframe, script of object van bv. Twitter & Facebook) wordt rudimentair weggefilterd, maar dat is een optie in de code ($trustHTML=false;)
  • De code-kwaliteit is ongetwijfeld beneden alle peil (geen OO, geen MVC, veel spaghetti), maar ik ben dan ook geen èchte developer.
  • Grootste missing feature is video (er zijn er nog, zie Trello-board)

Zo, dat is het zo wat. Bekijk het eens, geef commentaar, fork op GitHub, fix bugs, voeg features toe. Maar wat je ook doet, vergeet niet dat de content van VRT is en blijft en dat je daar dus niet zomaar wat mee kunt doen.

Android Chrome bug when styling unicode character?

symbols CSS weirdness in chrome for androidWhile experimenting with the use of Unicode characters in a small proof of concept, I stumbled upon what I think is a bug in Chrome for Android. Apparently character ☰, which renders as ☰ and which most people consider the “options”-icon, cannot be given a color in Chrome for Android whereas other Unicode characters can.
As you can see when visiting this test-page, the 3 symbols styled correctly (font color white) in most browsers (tested on IE8, FF on W7, Ubuntu and Android, Chrome on W7 and Ubuntu), but the options-symbol is not white on Chrome for Android (at least on my Samsung Galaxy S4).
So, does this qualify as a bug, or did I just mess up? Anyone happens to know a workaround?

Nieuwe m.deredactie.be niet meer mobiel!

(Update December 2014: ik bouwde zelf een alternatieve versie die sneller en toegankelijker is op http://futtta.be/redactie/)


m.deredactie.be homepageIk ❤ mobiele websites, zelfs op de desktop. Bij het refreshen van m.deredactie.be vandaag (12 mei) kwam ik op de nieuwe versie uit. De developers hebben zich ongetwijfeld goed geamuseerd om niet alleen de nieuwe look & feel te implementeren, maar ook om de achterliggende technologie grondig te herbouwen naar een JavaScript-based UI volgens de “single page application“-filosofie (iemand heeft zich wel héél erg in angular.js verdiept, daar aan de Reyerslaan).
Maar ik, eenvoudige gebruiker, ben minder enthousiast. De site ziet er misschien moderner uit, maar is minder bruikbaar; zonder javascript is er niets te zien (neem een voorbeeld aan “cut the mustard“, progressive enhancement zoals de BBC die predikt), “above the fold” staan er enkel afbeeldingen en vooral; alles is plots trager!
Want over snelheid kun je niet discussiëren; sneller is beter, trager is slechter, zeker mobiel. De voorgaande versie van m.deredactie.be “woog” pakweg 150KB en laadde volledig in minder dan 2 seconden, maar de nieuwe versie tikt af op 2560KB in 6 seconden (gemeten op webpagetest.org met “cable” bandbreedte-profiel, met “fast mobile” wordt dat 17s).
Is m.deredactie.be een mobiele site? 2 megabyte aan data zeggen van niet.