Tag: responsive design

Responsive banner ads

Responsive designResponsive design is hot, so responsive advertising is hot too. That’s why we see many new ads techniques and strategies. You will find a nice example of technique on Responsive Banner Ads with HTML5 and CSS3. Or maybe the GASP project will bring nice responsive html5 advertisements in future.
Also platforms like responsiveads.com introduce innovative techniques to show banners on responsive websites. And Google had announced to change their Adwords programm to responsive ads starting june of this year.

You will find responsive ads strategies on responsiveads.com too. To get some ideas take a look at their Ad Formats & Showcase page.

At the moment most advertisers have not adopt new responsive techniques. So i was looking for techniques and strategies to show conventional graphical banners on a responsive website. As i wrote earlier in responsive images (Dutch only) we can’t detect phone orientation or even screensize/viewport server side. Javascript can be a bridge between the media query detection of the viewport and the server side scripting. A solution for this is described on Firing Responsive jQuery Functions based on CSS Media Queries Rather than Window Width. The post gives also some other solutions: MediaCheck,jRespond and Breakpoints.js.

I found MediaCheck intuitive and uptodate so i build a proof of concept with it. Based on the viewport i load different banner formats on different positions. You can see the results by viewing the demo page on responisator or download the source on Github.

With MediaCheck you define your breakpoints based on CSS Mediaqueries like:


mediaCheck({
media: '(max-width: 420px)',
entry: function() {
console.log('starting 420');
},
exit: function() {
console.log('leaving 420');
}
});

MediaCheck is initialized with the jQuery Document Ready call so the banners are load after the page loads. This seems the main disadvantage of this method. On the other side this method prevents you from loading too much data to the client. None of the banners is hide or resize by CSS. You can use your banner loads for statistics. Every banner load should be a real view except from changing phone orientation maybe.

Responsive images

In een eerdere post schreef ik al dat het in het kader van responsive design het logisch lijkt niet alles client side op te lossen. Niet veel later leerde ik via @nielsvanmidden dat deze techniek RESS genoemd wordt. Voluit spreekt men dan van Responsive Design + Server Side Component.

Responsive images

In websites gebruikte afbeeldingen leek mij interessant om nader te bekijken. Ter illustratie een voorbeeld:

Een website geoptimaliseerd, of maximaal getoond, voor een breedte van 960 pixels. Zo’n site heeft bijvoorbeeld een header images van 960 x 300 pixels. Wordt deze website nu op een mobiele telefoon bekeken, dan wordt de header d.m.v. css op 100% schermbreedte gezet. De mobiel in portret view geeft de header dus afgebeeld als 320 x 100 pixels. Wordt deze afbeelding nu d.m.v. css (media queries) herschaald, dan wordt eerst de volledige afbeelding op de telefoon gedownload, de hardware van de telefoon herschaalt deze vervolgens. Was een afbeelding van 320 x 100 pixels van de server gedownload, dan was dit sneller gegaan en de gebruiker had minder dataverkeer verbruikt.

Mogelijke oplossing

Server side wordt het gebruikte device bepaald. Vervolgens stuurt de server de afbeelding van de juiste afmeting. Voor de oplossing ga ik uit van een willekeurige webserver (LAMP) waarbij alle afbeeldingen in één directory staan. Bijvoorbeeld /images/ (subdirs toegestaan). Middels Mod rewrite stuur ik alle request /image/* naar mijn script (ti.php):

RewriteEngine On
RewriteCond $1 !=ti.php
RewriteRule ^(.*)$  /image/ti.php

In ti.php wordt het device bepaald. Afhankelijk van het device rendeert ti.php de juiste afbeelding. ti.php kent de oorspronkelijke REQUEST_URI. Het script kan de opgevraagde afbeelding openen, herschalen en renderen. Qua device zou je bijvoorbeeld kunnen splitsen op mobiele telefoons, tablets en desktops. Voor mobiele telefoons hoeft een afbeelding dan niet breder dan 480 pixels te zijn (???).

Het bepalen van een device kan gebeuren met Mobile Detect.

Voordeel van deze oplossing dat je deze op elke website server kunt installeren los van het CMS dat gebruikt wordt. Enige dat je feitelijk hoeft te doen is de files uploaden naar je directory met afbeeldingen. Dat gaat dan om een .htaccess bestand, ti.php en de Mobile Detect files. Er zijn ook geen wijzigingen nodig aan je html.

Deze oplossing werkt in theorie, in de praktijk zijn er ook enkele nadelen.

Te weinig profijt

Veel sites hebben weinig hele grote afbeeldingen, voor veel sites betreft het alleen de header. Hoewel er altijd winst is, kunnen de voordelen gering zijn. Voor een website met veel foto’s, die ook op desktop foto’s herschaalt middels css (of width i/d img tag) zou de winst daarentegen wel enorm kunnen zijn.

Landscape / portret view

Mobiele telefoons hebben meestal een landscape en portret view. Bij het wisselen tussen de landscape en portret view wordt de pagina niet herladen, afbeeldingen kunnen middels css wel opnieuw schalen. Voor images die je getoond wilt hebben met 100% van de schermbreedte betekent dit dus, dat de afbeelding die je laat laden minimaal een breedte moet hebben gelijk aan de maximale schermbreedte in de landscape view.
Vervolgens heb ik bijvoorbeeld gekeken naar: http://twitter.github.com/bootstrap/scaffolding.html#responsive “Supported devices”. Dan blijkt er eigenlijk een overlap tussen telefoons en tablets met een breedte tussen de 480 en 767 pixels. Dat zijn grote telefoons of kleine tablets.
Onduidelijk is of Mobile Detect nauwkeurig genoeg is om te bepalen of een device valt onder bijvoorbeeld maximaal 480px breed (landscape).
Zie hiervoor ook: Obtaining max device width. Indien de bepaling niet strikt genoeg is zou je voor elke telefoon voor de zekerheid moeten uitgaan van 767 pixels, een steeds geringer verschil met de originele 960 pixels.

A Simple Device Diagram for Responsive Design Planning laat zien dat er feitelijk maar één breakpoint mogelijk is. Dit breakpoint ligt dan bij 480px.

The MobileESP Project  is een andere library om devices te detecteren. MobileESP is beschikbaar voor PHP, Java, ASP.NET (C#), Python (voor Django), Ruby en Classic ASP (VBscript). Tevens is er een javascript versie en een api beschikbaar. Via MobileESP zou, mogelijk niet heel strikt, een onderscheid gemaakt kunnen worden tussen telefoon en tablets met een scherm tot 7inch en een groep met schermen tot 8inch. 7inch schermen zouden een resolutie hebben van 480×800. Via deze route zou je een breakpoint op 800 pixels kunnen bepalen.

Alternatief

Alternatief zou kunnen zijn om de server side Mobile Detect te vervangen door een client side javascript detectie. Voorbeeld is te vinden op https://github.com/filamentgroup/Responsive-Images. Eerste nadeel van deze methode lijkt dat je de images pas kunt laden nadat de pagina geladen is. In het genoemde voorbeeld wordt ook  met maar één breakpoint gewerkt. Het onderscheid is dus groot of klein. Probleem met de landscape en portret view blijft bestaan.

Het vak van de webbouwer en online marketeer wordt steeds leuker en uitdagender!

“Het vak van de webbouwer en online marketeer wordt in ieder geval steeds leuker en uitdagender!” dat schreef @qtag_qrcode in een reactie op het artikel    Responsive design, development en content in één flexibele aanpak. Inderdaad refereert hij daarbij terecht aan: 60% van internetverkeer is mobiel (zie het CBS persbericht van 23 oktober). Voor webbouwers is dit inderdaad een uitdaging. Of het ook leuker en uitdagender wordt, browsers, schermresoluties ondersteunen doen we al sinds we websites bouwen.

De benadering van content first is wel nieuw en interessant. En ik zou zeggen uiteraard kunnen we daarbij niet meer zonder de ‘responsive gedachte’. De meeste webbouwers denken bij responsive toch steeds aan de CSS3 media queries. Wat mij betreft zou het (weer) meer de breedte in mogen.

Uitgaande van CSS3 media queries geeft @nielsvanmidden ook als reactie op het bovengenoemde artikel een mooi overzicht van breekpunten. Een breekpunt is een minimale of maximale schermbreedte waarop je de weergave van je site aanpast. Je kunt dat heel strict toepassen, waarbij je je aandacht vooral richt op het device; bijvoorbeeld … pixels breed is een tablet in landscape mode. Een meer flexibelere aanpak wordt voorgesteld in Responsive Design: Why You’re Doing It Wrong. In dat artikel wordt voorgesteld je breekpunten te bepalen op wat je ziet in de browser(s) naarmate je het window verkleint of vergroot. Daarbij wordt dan ook meteen weer aandacht gevraagd voor de ondersteuning voor verschillende browsers. Microsoft ondersteunt media queries bijvoorbeeld pas vanaf IE9.

Hoe je uiteindelijk je breekpunten ook samenstelt in beide benaderingen kun je werken van klein naar groot of andersom. Per breekpunt kan ook de content aangepast worden. Verschillende breekpunten zullen vragen om het weglaten, toevoegen of herpositioneren van content. De contentkeuze wordt moeilijker bij een responsive benadering vanuit schermbreedte i.p.v. het soort device. Want zoals in 11 Reasons Why Responsive Design Isn’t That Cool! (punt 10) wordt aangegeven is het soort apparaat vaak bepalend in de behoefte van de gebruiker. De andere 10 genoemde redenen mogen ook niet onderschat worden. Schalen van plaatjes, elementen verbergen op basis van media queries optimaliseren de laadtijd van de website niet. De laadtijd, juist ook voor de mobiele gebruiker zo belangrijk, wordt overbodig lang doordat onnodige en onnodig grote bestanden geladen worden.

Voor een goede gebruikerservaring lijkt de inzet van media queries op termijn dan ook niet toereikend. Alternatief om toch weer aan de serverkant aan de slag te gaan. Mensen die met WordPress werken zouden bijvoorbeeld eens naar de wp_is_mobile()  functie kunnen kijken. Daarmee is het mogelijk om aan de serverkant vast content te schalen, tonen of juist niet tonen. Ook dit past prima in een content en / of mobile first benadering. Het combineren van client- en serveroplossingen vormt mogelijk een goed compromis tussen een losstaande mobiele website en een volledig op media queries gebaseerde responsive website.

Ook Jamedo Websites bouwt nu, mede op mijn advies, responsive designs op basis van media queries. Dat was reden genoeg om deze benadering nog eens kritsich te bekijken. En hoe ziet jouw website er eigenlijk uit op een mobiele telefoon of tablet? Via Responsinator.com kun je hiervan snel een goede indruk krijgen.