deredactie.be

Nieuwe m.deredactie.be niet meer mobiel!

by

(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.

Why I love the mobile web

by

This is why I’m a big fan of good mobile websites; the normal BBC Sport Formula 1 page loads in 6 seconds, where the mobile version loads in a mere 2 seconds (when over cable, DSL and 3G are off course slower). Same content, less clutter and based on progressive enhancement for ultimate responsiveness (from low-end phone on a mobile data network to a tablet on WiFi). Guess which site I use on all my devices (smartphone, netbook, the family tablet and my work laptop)?
The details, for both document complete and fully loaded (between round brackets) as seen from the Brussels webpagetest.org node using IE9 and the cable-bandwidth profile;

bbc sport desktop thumbnailbbc sport mobile
load time 6.011s (7.371s) 2.057s (3.243s)
download size 988 KB (1015 KB) 184 KB (657 KB)
requests 134 (141) 32 (65)
test report webpagetest.org result webpagetest.org result

Notice the big difference between document loaded and fully loaded on mobile; that’s where the progressive enhancement kicks in. If you visit the same mobile site with a small screen-size device or without JavaScript, page load time drops to 1.467s for just 76 KB.
An even more extreme example; the desktop news-site for the VRT (the non-commercial broadcaster here in the northern part of Belgium) loads in 10,598s (11,482s) for a whopping 4.337 KB (4.406 KB) (on cable, it gets way worse when on DSL-bandwidth!) while their (one site fits all) mobile site only needs 0,869s (1.475s) for 116KB (120KB). Guess which site I use?
The conclusion is simple; don’t assume that just adding some mediaqueries will make your dog-slow site truly mobile-ready. It’s 2013 and websites should be lean and mean, but most of them still remain way too fat for our smartphones.

deredactie.be: “browser is zoekmachine”

by

Enkele weken geleden maakten we ons collectief vrolijk over de man en vrouw in de straat, die niet uitgelegd kregen wat een browser is.
httpv://www.youtube.com/watch?v=o4MwTvtyrUQ
Gelukkig is daar deredactie.be, die in het artikel “Gebruiker kiest zelf browser bij Microsoft” haarfijn uitlegt wat dat is;

Mensen die het nieuwe besturingssysteem van Windows gebruiken, kunnen vanaf nu zelf hun eigen browser, of zoekmachine op het internet, uitkiezen. Vroeger was dat automatisch de eigen browser Internet Explorer, maar de Europese Commissie tekende daar protest tegen aan.
Softwaregigant Microsoft bood tot nu toe altijd de eigen browser Internet Explorer aan als zoekmachine op het internet. Wie een alternatief verkoos, zoals Mozilla van concurrent Firefox, moest dat specifiek downloaden.
De Europese Commissie vond dat niet kunnen, en daardoor heeft Microsoft het systeem nu veranderd. Wie een computer met Windows 7 aankoopt, krijgt bij de start een scherm waarop er een browser kan worden gekozen.
Dat opent perspectieven voor andere zoekmachines zoals Firefox, dat al langer aan een sterke opmars bezig is, en Google. De Europese Commissie heeft positief gereageerd op het besluit van Microsoft.

Als ze daar aan de Reyerslaan “browser” persé willen vertalen, dan is “internet-bladeraar” misschien toch een beter alternatief? Of weet gij nog iets beters?

deredactie.be down, depannage-versie op futtta.be

by

Het loopt niet zo lekker op deredactie.be; de videozone deed firefox en safari crashen, invalid atom-feeds veroorzaakten stack-traces op http://m.beta.deredactie.be en de hele site is momenteel kapot.
Wie op deze blog terechtkomt op zoek naar deredactie; op http://futtta.be/deextractie/mobile.php?deffont=medium kun je tijdelijk de inhoud van deredactie raadplegen. Het is een onafgewerkte (en normalerwijs overbodige) light versie van deredactie op basis van de eveneens onofficiele volledige feed die op http://feeds.feedburner.com/deprotestactie te vinden is.
Yet another great post powered by mlogger

deredactie.be doet full monty in de feed; applaus!

by

De nieuwe versie van deredactie.be is een grote stap vooruit. Niet zozeer omwille van wat ge wel, maar eerder om wat ge niet -direct- ziet; ze hebben hun inhoud bevrijd. De atom-feeds lijken nu immers de volledige artikels te bevatten. Ge kunt niet zeggen dat ze stil blijven staan, daar aan de Reyerslaan! Applaus!

Mijn deredactie-journaalplayer gefixt

by

Dju, m’n journaalplayer is was kapot!
Dat heb je natuurlijk met spielereien op basis van ongedocumenteerde 3rd party xml-feeds; als de bron wijzigt, dan werkt je webhackje ook niet meer. De atom-feed die ik gebruikte, was sinds de lancering van de videozone (en de stille redesign) van deredactie immers niet meer beschikbaar.
Uit een snel testje bleek dat de nieuwe videozone andere feeds (voor Journaal en Terzake) gebruikt. Die feeds bevatten zowel entries voor de integrale afleveringen van de afgelopen dagen als voor alle individuele fragmenten uit die verschillende edities. Aangezien een entry in de ATOM-file evenwaardig is aan elke andere entry, wordt de relatie tussen die verschillende entries dan maar in de comments in de XML meegegeven. Of hoe XML ook gestructureerde rommel kan zijn.
Maar aangezien er op deredactie nog altijd geen grote knop “Bekijk hier het Journaal” staat, omdat een kat zijn jongen niet terugvindt in de videozone en vooral omdat ik het niet leuk vind als mijn speledingetjes niet meer werken, heb ik één en ander toch aangepast aan de nieuwe feeds (waarbij ik op basis van de titel de individuele fragmenten van de meest recente aflevering uit de ATOM-feed filter).
Hoera, m’n journaalplayer werkt dus terug.

Free your content now!

by

Bert Van Wassenhove considers RSS to still be “a diamond in the rough” which has not yet been picked up by the mainstream public. The reason for this, according to him, is that:

[Newspapers] copied their paper/website logic to RSS feeds without adapting it to the medium. As a result, you get long lists of news articles with no difference between front-page news and a small article at the back of the newspaper.

To solve this problem, he proposes editors to (also) offer a “front-page feed”, which would contain only the most popular (automatic) or most important (handpicked) items.
Not a bad idea at all (are you listening, deredactie?), but even more important; shouldn’t news-websites start treating RSS as a publication-channel in its own right, containing the entire article (and why not even enclosures for AV-material)? Because, expecting me to click through, seriously?

RSS-feeds can indeed be a great way for readers to focus on content, without the overhead of the “normal” website-context. Heck, I’d even accept some text-ads and links to related items in there if need be. Publishers will sooner or later really have to let go of the concept of their (semi-)walled garden as the only place where visitors are allowed to consume their content (as they had to let go of the paper-only distribution-model). Focus on reach (“content views”) instead of pageviews, allow your readers to decide in which context the content is consumed (think rss-reader, think syndication, think mash-ups, …)!
I happened to stumble across this full atom-feed for deredactie.be, containing entire articles and enclosures for images, audio and video and it’s just great! I’m sure it could help info-overloaded users to keep more up-to-date with the news and that an official (because this one isn’t) full feed from deredactie could massively improve the reach of the great VRT nieuwsdienst content (according to CIM they’re really not doing that great when compared to the competition).
So, let me quote Bert; “Mr. editor in chief, please help RSS to become the success it deserves to be” and I’ll happily add “Set your content free!” to that.

Het deredactie-Journaal ook in uw mediaplayer?

by

Er kwamen links en rechts wat positieve reactie op mijn ‘deredactie journaalplayer’. Laatste in de rij was Wouter, die op zijn blog een perl-script deelde dat op basis van de atomfeed een m3u-playlist genereert om het VRT nieuws in VLC te bekijken.
Fantastisch idee van Wouter, ik heb dat dan ook snel in mijn atom-parsend scriptje gepropt. Vandaar; vanaf nu kun je het deredactie Journaal niet enkel in je browser, maar ook in je favoriete mediaplayer bekijken;

Ik heb één en ander zelfs (oppervlakkig) getest en dat lijkt correct te werken in Windows Media Player, VLC, Totem en Winamp. Apple Quicktime daarentegen lijkt het niet te doen; wel geluid maar geen beeld met de mp4/m3u-versie, terwijl de individuele mp4’s wel correct worden afgespeeld. M3U is oorspronkelijk natuurlijk audio-geörienteerd, misschien valt QT daarover en moet ik er nog een extra playlist-formaat tegenaan gooien? Er zijn wel minstens evenveel playlist-formaten dan dat er videocodes zijn, maar SMIL ligt voor de hand?
Voor de web-versie heb ik JWFLV (de flash video player) geupgrade van naar de nieuwe 4.2-versie, wat voornamelijk de inhoudstafel ten goede komt; de verhoudingen van thumbnails worden nu gerespecteerd en die visuele playlist scrolt nu mee terwijl je kijkt. Nifty jongen, die JW!

My Mobile bookmarks

by

A quick list of the most frequently used sites on my mobile phone.

  1. gmail mobile: my “homepage”. attachments and images could be handled better, but still, a great mobile web-app.
  2. google reader mobile: too many blogs, too little time. reading up on my blogfeeds everywhere i can (and yes, that includes the loo)
  3. smartphone/pda version of bbc news; the beeb was one of the first to have a version for PDA’s and smartphone’s, still great stuff.
  4. deredactie mobile: I just love the mobile version of their awful “desktop-oriented” website. Guess they took a close look at the BBC’s mobile site, no? Anyway, it would be even greater if they added links to multimedia (i.e. not force-feed video as they do on their very-very-broadband-version) and if they optimized the color usage because the readability of the purple night-version is sub-optimal.
  5. facebook mobile: I never really liked Facebook, but I must admit I’ve found myself spending time on it on an almost daily basis. The mobile version is an important part of that usage pattern.

Less frequently used mobile sites include; Truvo’s yellow and white pages, Wapedia (as wikipedia doesn’t provide a mobile version, they should) and Linkedin mobile. And although the webkit-based nokia browser handles normal sites quite well, the only non-mobile-optimized site in my bookmarks is my blog’s dashboard.
And you, what sites do you visit on your IPhone, Blackberry or Nokia e71?

Is the web too fat for your IPhone?

by

So you have a spiffy mobile phone with a top notch browser that does a decent job at displaying “desktop-oriented” websites and you use it to surf the web regularly, visiting some of the bigger news-sites in Belgium. What does that mean, from the point of view of data transfer and bandwidth usage?

data usage for 4 pages on 5 sites (click on image for more, methodology see below)

That sure is a lot of data, Captain! What does that mean?

  1. You will have to be patient, because downloading 1 or 2 Mb for that initial page will probably be gruesomely slow (especially if you’re on EDGE because there’s no 3G-coverage)
  2. You will end up paying good money for all that data transfer, because data is money when you’re on mobile time
  3. You might even curse your handset or crashing browser (more on google), because all that data will end up in RAM and these devices do not come with tons of that.

In these broadband-times, website builders seem to have completely forgotten about best practices for download size of complete web pages (html + all js/css/images/…). This means that a lot of websites should be considered non-accessible on mobile devices.
If you want your normal website to be usable on IPhone’s, HTC’s and other Nokia’s, you’ll have to start taking download size into account again. That means taking some technical measures (using mod_deflate and mod_expires for example) and making hard functional choices to remove some stuff (on this blog dropping the rather useless mybloglog-widget saved me 210Kb, going from 10 to 7 posts per page another 200). And if you want to target mobile users specifically, you’d better invest in a mobile-specific version of your site!

The methodology followed to measure these download sizes;

  • disable flash (there’s no such thing on mobiles, with flash these figures would have been even far worse)
  • disable memory cache (in about:config), because it can’t be cleared easily
  • clear disk cache
  • open up firebug and click on ‘net’ to monitor downloads
  • download homepage, random 2nd page, random 3th page and the homepage again

The spreadsheet (on google docs) contains more data (compare above results with those for 2 mobile-specific sites)