Yle byter visuellt utseende

Det har varit endel jobb med den gamla plattformen den sista tiden. Vi har förberett den för bytet till Yles nya visuella utseende.

Det är en utmaning att hitta alla ställen de gamla logotyperna existerar! (Tipsa mig om du ännu ser någon ;)

Det kan löna sig att tömma webbläsarens cache för att du säkert skall se ändringarna på svenska.yle.fi & co – det beror på att dels är våra egna cache (tillfälligt minne) servrar effektiva, men även webbläsarens cache kan ställa till det.

I och med att vi snart migrerar till S.Y.N.D handlar det främst om att sidans huvud och fot fått ett nytt utseende på våra gamla sajter. Du känner bra igen att största delen av den gamla sajten finns kvar med samma visuella utseende som tidigare.

För S.Y.N.D:s del går det också framåt, och inom några veckor skall vi börja köra sajten live internt. Efter det blir det en publik beta där alla intresserade kan bekanta sig med hur vi inom S.Y.N.D använt oss av Yles nya visuella utseende.

Här kan du se hur sajten just nu ser ut (skärmdumpar från vår utvecklingsmiljö, så texterna är inte representativa och vissa texter är ännu på engelska.)

Fast en del arbete kvarstår ser ni här en version som är rätt nära lanseringsversionen – det blir en ren layout som lyfter fram innehållet samtidigt som den tar hänsyn till den typ av apparat man använder.

Om du vill få en inblick i vad den responsiva designen kan betyda i praktiken kan du gå in på svenska.yle.fi/programguide med en apparat som har en skärmbredd som är mindre än 480px (fungerar också att bara krympa webbläsarens fönsterstorlek). Rent tekniskt är det en begränsad responsiv design lösning eftersom den tekniska plattformen inte ändrats.

Implementing a mobile first responsive design

About a month ago we had just created the basis for our responsive design, see Hur bygger man en sajt som fungerar både på mobil, tablet och desktop – på respektive form factors villkor?. Time to give an update on the progress.

The areas that we have been working on are markup & semantics, http requests, amount of loaded KB and screen size adjustment.

On the markup and semantics front we have made additional switches from a traditional <div> structure to one of HTML5 tags (we where happy that the <time> tag was re-introduced). Our timestamps are printed in a humanized format, see timeago – a jQuery plugin.

We also added support for schema.org and microformats.org/ on images and author information. Tests width Google Rich Snippets Testing Tool indicate that it will give added value in search results. Schema.org and RDF also has a draft pending that seems interesting.

With regards to keeping the amount of http requests down we use regular methods like sprites (depending on how big you have to make the sprite, it might actually also save a good deal on total KB size) and media querys combined with a script loader to only load relevant CSS styles and JS per device. @bengoodyear created a script for loading the share buttons only when the user indicates that he or she wants to use them. An additional nice feature is that on mobile you will be able to click the share buttons individually, thus removing the need to load them all.

Images has the biggest impact when considering amount of loaded KB. This is the reason why we load a small thumbnail (16:9) as the default image. If the screen size is big enough a bigger image will load automatically. To avoid a “jump” when the bigger image is loaded we added the size of the bigger image in the CSS, so what the end user might be able to see (depending on loading speeds) is that the image goes from being blurry to sharp. The right CSS for our set of four layout widths is applied with media query.

We built a custom solution as we have our home-brew Image Management System that we connected to Drupal. If you are using Drupals own image field, you might want to check out Responsive images module.

With regards to the amount of loaded CSS files I tried out Responder module – a good solution if you want to add a responsive design to a current theme. In our case since we are using Omega Responsive HTML5 theme and have added our own solutions it does not look like a module we will add.

The markup generated by Drupal and its modules is not the best, there is a lot that does not need to be there, thus adding both unnecessary KB weight, accessibility and styling issues. This is something we are still working on, and I assume we will have to make some kind of compromise.

To limit the amount of markup loaded we first add the navigation as a <ul> <li>- list, and then with that as a base use javascript to create a <select> pulldown-menu to be used in the mobile version. This way it is easier to select a link in the mobile version, and the screen is not filled up with a list of links.

Responsive videos is also a bit of a challenge. In our case we need to support Arenan, Youtube and Vimeo.

There is a new version of Arenan being launched next year, and we are working with the implementation of that one. A big improvement will be made on how it is embedded. It will now be added as a background in a div, that is replaced by a Flash player when the user clicks the play button. Sorry, no HTML5 video support yet due to rights management issues.

This means that we can also get a small size image for each video/audio clip, and re-size it the same way we re-size images.

Currently we are experiencing problems with the size of the video, when it actually starts playing. This is something we are working on together with the team building the new version of Arenan.

Right now we are looking at using Fitvids module on all iframes to add the scaling ability to Youtube, Vimeo and other embedded materials. Might be that iframe as a target tag is to broad ;) We will have to test and see, would have been nice if Vimeo and Youtube added a class name to their embed code, so that you would be able to target them.

With regards to the set of four widths we are using, the styling has progressed nicely. It takes a while to start thinking mobile first, but when you get a hang on it it comes naturally. The interesting questions that arise then are what kind of differences do you want on the different devices? Do you want bigger images if you are using a tablet? These are the kind of questions we are thinking about, and will test on users to see what the final version will look like.

Hur bygger man en sajt som fungerar både på mobil, tablet och desktop – på respektive form factors villkor?

Svaret är: Responsiv design, med vilket vi bestämt att bygga nya svenska.yle.fi. Beslutet grundar sig på att vi vill tillgodose det behov som uppstår då sajten används på en allt större flora av apparater.

* När du tittar på demon, tänk på att den här versionen är en statisk html kopia, och att den saknar lösningar specifikt per apparat. Den är grunden med vilken vi börjar se vilka tilläggslösningar vi behöver göra för att få den att fungera optimalt i alla apparater.

Den modell vi gått in för betyder att vi byter utseende ‘on the fly’ med media querys beroende på hur stor skärm sajten visas på. För att det skall fungera lika smidigt för ngn som använder mobilen som för ngn vid sin dator behöver man utgå ifrån mobilens behov först.

Mobilen har förutom en liten skärm också långsammare nätförbindelse, och stöder inte alla nya tekniker. På en dator är det möjligt att lägga till saker som saknas i mobilen.

Vi har därför beslutat att leverera en liten bild som standard. Den laddas av alla apparater, som sedan byts ut till en större version beroende på vilken skärmstorlek som används. Problemet med den lösningen är att det uppstår en omritning av sidan, då den större bilden laddas in med viss fördröjning. Det problemet går att lösa genom att kombinera bild-utbytningsfunktionen med CSS (styr sidans utseende). Eftersom CSS:en är skild för varje skärmstorlek kan storlekarna för bilderna också anpassas korrekt.

Rent markup-mässigt vill vi inte ladda hela sökvägen för fem gånger, utan räknar med att lösa det med en egen bildutbytningsfunktion. Så här ser den dock ut i skrivande stund:

<img alt="Yle" src="http://www.yle.fi/ims/nyheter/2011/43/611054ea59521d6b15/611054ea59521d6b15_8.jpg" data-src-fluid="http://www.yle.fi/ims/nyheter/2011/43/611054ea59521d6b15/611054ea59521d6b15_8.jpg" data-src-narrow="http://www.yle.fi/ims/nyheter/2011/43/611054ea59521d6b15/611054ea59521d6b15_4.jpg" data-src-normal="http://www.yle.fi/ims/nyheter/2011/43/611054ea59521d6b15/611054ea59521d6b15_6.jpg" data-src-wide="http://www.yle.fi/ims/nyheter/2011/43/611054ea59521d6b15/611054ea59521d6b15_5.jpg">

Men layouten då?
I och med de fyra olika storlekar som sidan kan ses i måste man hitta på sådana layoutlösningar (layoutblock) som fungerar smidigt i alla storlekar. Detta för att redaktören som skriver artiklarna inte skall behöva kolla att textmängden inte ställer till problem i ngn viss skärmstorlek.

Ett utmaning uppstod i att omforma raden med fyra puffar bredvid varandra till en med två bredvid varandra. Lösningen ligger i att använda en CSS selector på varannat block för att bryta blocken annorlunda beroende skärmstorlek. Alternativet att krympa spaltbredden skulle ha lett till en allt för stor chans att orden skulle ha varit så långa att de inte rymts inom spaltbredden.

En annan är att ta bort bakgrundsfärger från layoutblocken då de visas i mobilen, då det inte längre är intressant att visa layouten som är gjord för större skärmar. Lösningen ligger i att använda media querys även för att lägga till bakgrundsfärgen i de större skärmstorlekarna, så att de aldrig ens finns i mobilversionen.

Vilka är nästa steg?
Nu går vi vidare och testar denna version, och bestämmer vilka specifika lösningar vi gör per apparat (dvs Android, Ipad, Nokia). Redan nu vet vi att demon inte fungerar så som vi vill på Android (Samsung Galaxy Tab) i och med att den inte visas i tablet läge. Javascript-lösningen är heller inte perfekt, i och med att den räknar skärmbredd annorlunda än media queryn, vilket gör att det i vissa skärmstorlekar blir fel bildstorlek i kombination med de fyra sidstorlekarna. En lösning vi ännu inte gjort, men kommer att ställas inför är hur vi visar och lägger in videon (istället för bilder). Då vi är nöjda med hur det fungerar kommer vi att bygga fler modeller för layoutblocken, och lägga på fler visuella stilar på de modeller som redan existerar.

What would be a good set of page widths with the current set of screen resolutions?

We have decided to work with responsive design and are in the process of setting the widths of the pages. I took a look at the screen resolutions our visitors are using at the moment.

The setup we are looking at right now would have four brackets:

  • Less than 740px (mobile or small tablet) – would see a fluid page
  • Less than 980px (tablets or notebooks) – would see a fixed-width page of 740px
  • Less than 1220px (smaller screens) – would see a fixed-width page of 980px
  • Wider than 1220px (big screens) – would see a fixed-width page of 1220px

When the current number of screen resolutions is applied to these brackets this is the outcome:

  • 2,5 % = Less than 740px
  • 2,2 % = Less than 980px
  • 16 % = Less than 1220px
  • 80 % = Wider than 1220px

These numbers represent 94 % of all visits to our site, the remaining 6 % are spread over 2,300 different screen resolutions.

If we would have a wider page for bigger screens, the result would be:

  • 2,5 % = Less than740px
  • 2,2 % = Less than 980px
  • 49 % = Less than 1360px – would see a fixed-width page of 980px
  • 45 % = Wider than 1360px – would see a fixed-width page of 1360px

It’s also possible to move the width bracket for smaller screen sizes, but that immediately creates a cascade effect. The tablet user is not happy when grouped with the mobile users, and someone using a screen resolution of 1192px is not happy being grouped with the users of a 768px screen.

Additionally, the numbers don’t tell the full story as they don’t take into account that a user might display the browser window in a smaller size than the screen resolution they have.

What brackets are you using, and any particular reasons why you chose them?