Om Mårten Seiplax

Jobbar på svenska.yle.fi med det grafiska utseendet, kodning och sånt. Följ mig på Twitter eller Google +

Varför kan jag inte bestämma exakt var bilden/videon/citatet finns?

Det korta svaret:

Vi vet inte exakt hur innehållet kommer att visas beroende på om användaren har en mobil, pekdator eller dator. Vi vet heller inte vad som kommer att vara det sätt som användarna använder sig av om bara några år. Därför gör vi flera designmönster som systemet kan välja bland. Det bäst passande mönsteret visas till användaren utgående de parametrar vi kan avläsa om användarens utrustning.

Responsive design - så ser demon ut på big screen, laptop, tablet och mobil

Då jag säger att vi inte vet hur innehållet kommer att se ut så är det mer relationen mellan innehållsbitarna som vi inte känner till. Att kolla på sin egen dator med en viss webbläsare/skärmupplösning och utgående från det bestämma var radbrytningar skall finnas (för att ge ett visst utseende) är bortkastad tid och grus i maskineriet.

Samma sak gäller om det är en bilds/videos/bildgalleris placering till höger/vänster eller vilken storlek den skall ha. Systemet behöver kunna bestämma designmönster utgående från apparaten.

Ett exempel: Om Text-tv skulle använda samma innehåll som webbtjänsten skulle ett radbyte i rubriken ställa till problem då rubrikerna i Text-tv alltid bara är en rad.

Detta sätt att styra utseendet framtidssäkrar vårt innehåll. Vid systembyten är den stora stötestenen hur utseendet skall migreras. Med detta upplägg så kan vi bygga nya designmönster som passar det nya systemet utan att gammal formatering av innehållet blir i konflikt med det nya.

Det långa svaret:

Yle har bestämt att öppna sitt innehåll och börja använda sig av API:n (Application Programming Interface) (Yle avaa sisältöjään, pysy kuulolla! ). Under en av de många workshops som hölls då den strategin utformades talades det mycket om innehållsstrategi (content strategy).

Vad är det då? I korthet: Innehåll som är formaterat på ett sätt som gör att det kan användas på ett mångfacetterat sätt. På detta sätt framtidssäkras innehållet. Ett talande exempel om värdet av innehåll gavs av Karen McGrane: Tv-guide (Amerikansk tidning) beslöt sig länge före det fanns elektroniska programguider i tv, på webben eller i mobilen att skriva en kort-, medel- och lång- textbeskrivning av programmen. Ingen visste var texterna skulle användas, eller exakt hur de skulle användas. Video: Karen McGrane: Adapting Ourselves to Adaptive Content – An Event Apart

Det var intressant att få dessa exempel, för det är den linje vi också valt utan att ha följt med diskussionen om innehållsstrategi (content strategy). Förutom att vi inte tillåter att man själv kan bestämma var och hur bilder etc. placeras har vi heller inte en förhandsgranskningsmöjlighet. Orsaken var att vi vill att man inte skall stirra sig blind på att hur artikeln ser ut på den dator som man skriver den på.

Den design lösning som vi använder oss av upptäcker om man kommer till svenska.yle.fi med mobil, pekdator eller dator och anpassar sig därefter. För att det skall vara möjligt behöver vi veta att viss information alltid finns tillgänglig.

Exempel: Om en bild eller text saknas så har vi inget att visa, och behöver då i designmönstret planera för det.

Ibland finns det info som systemet inte klarar sig utan (t.ex. rubrik, beskrivning). Vi designar därför för olika format (med format menar jag att det finns en viss mängd information, t.ex. rubrik, ingress, bild, länk som man använder som modell då man gör ett designmönster).

Då nya apparater kommer ut på marknaden så kan vi designa för dessa utan att det blir en konflikt med de existerande designmönstren. Det förutsätter dock att formatet är väl uttänkt och inte används på ett motstridigt sätt.

Exempel: Vi kan visa text i fet stil inne i brödtexter på den vanliga webbplatsen. I någon applikation som vi bygger så kanske det inte är möjligt.

Då Yle går in för att använda sig av API:n kommer vi också att vara beroende av att ha format och designmönster. Om vi vill hämta programinfo så behöver vi kunna lita på att vi alltid får ut rubrik, beskrivning och sändningstid. Om någon annan använder svenska.yle.fi:s artikel API så behöver de i sin tur kunna lita på att de får ut artiklar som är just vad det står att de är: artiklar. Om artikeln inte är en ren artikel så är det inte möjligt för dem att bygga egna designmönster som fungerar i alla situationer.

Ett bra exempel på där det inte ännu fungerar så bra är svenska.yle.fi/regioner (en ny version är på kommande). Orsaken det inte fungerar väl är att vi inte alltid vet om det finns en bild, samt att rubrik- och textlängd ibland varierar kraftigt. Designmönstret klarar i detta fall inte av att kompensera variationen i innehållets format. Det är också till format som dessa som sammanfattningen (ingressen) behövs som ren text (utan bilder, bildgallerier eller videon).

Då formatet inte går att lita på fungerar inte designmönstret:
Regioner - problem
Så som det borde se ut:
Regioner - hur det borde se ut

Värdet av att ha ett innehåll som inte sitter fast i ett utseende kan vi se på svenska.yle.fi då vi nu håller på och migrerar material från våra gamla sajter. Från nyhetssajten gick det bra då formatet var i gott skick och hade en tydlig struktur. Därför kan vi nu använda dem, och t.ex. på Radio Vega automatiskt lyfta in artiklar som publicerades just nu, men för tio år sedan.

Vi hade inte samma tur med Mat & fritid där artiklarna till 100% hade layoutstyrning inne i själva texterna. Dessa artiklar ser nu inte så bra ut som vi skulle vilja, och det kommer inte att gå att göra designmönster som fungerar felfritt då nya användningssätt uppstår.

The making of a Yle Drupal Distro (YDD)

From the start of the project (Swedish Yle’s New Drupal (SYND)) we had a goal to build it as a distro. What is better than that someone else can use the same code base? :) With YDD we reached the internal distro milestone, an important step if we also some day want to be able to make it a public distro.

During January we spent two weeks making our own code more abstract (for some reason there is always something that gets hard coded), making new features that were wanted for the PoC (Proof of concept) of FYND (Finnish Yle’s New Drupal), setting up a new dev environment and splitting up the install profiles to support YDD, SYND and FYND.

The structure we decided to use is as follows: YDD contains the basic functionality that all sites should have. SYND and FYND each contain their separate modifications. Example; recipes, maktbasen and some Svenska Yle specific styling is found only in SYND. The themes in fynd_themes and synd_themes are subthemes of the theme in yle_themes.

The GIT structure and install profile logic:

FYND

YDD

SYND
fynd_modules
fynd_features
fynd_themes
fynd_profile
yle_modules
yle_features
yle_themes
synd_modules
synd_features
synd_themes
synd_profile

With this structure we are able to use a common core, and if needed add more functionality, translations or styling per site. Issues we ran into include views that were created when the system was in Swedish. It does not work to then switch the system to English before exporting, the view will be in Swedish.

Another issue was that a view that limited content based on a taxonomy was exported with the VID, and not the machine name of the taxonomy. Solved by changing the view so that the machine name was used in the filter.

We also had some displacements of fields and taxonomies. They had been placed in the wrong feature, so they were not available when some features needed by SYND were not enabled in FYND.

Moving theming to the features and modules was also something that we now needed to do. Not all the views that had styling was going to be used in both SYND and FYND.

The RSS feed generated by Views is one open question. It would be good to share them between the install profiles, but settings like Site name and headlines are hard coded in the view.

Being more thorough in with what is placed where and making sure that the language always was English would have made the process even smoother.

One thing we should have done in the early phase is to change the name on the live production install profile. That we tried to do it at the same time as we had moved some of the modules from yle_modules to synd_modules caused problems when migrating the production database.

The process itself turned out to be a good way to also do a review of the code. Even though we have had two external reviews (thanks Bala, @dasphere) it sometimes takes deep knowledge of a site to realize that something has unnecessary overhead. Having to split the site forces you to look at parts of the code that otherwise does not get looked at that often. We ended up merging and/or removing four features/modules.

Working with Jari Lana who does Drupal for Ylex, Oppiminen & co was also a good way to get a fourth review, from someone who also could make improvements directly in the code.

Even if FYND is never launched, the work will not go to waste. SYND has reached a new abstraction level, got new features and improvements. If the need arises, a new site can be up and running in no time.

Currently svenska.yle.fi is running on the new YDD + SYND setup.

Vad är en patch? Steg för steg guide hur du själv gör en till Drupal

En patch kan jämföras med ett plåster med en unik passform för ett unikt skrubbsår. Patchen bygger man för att fixa något som man tycker är fel i en modul (core eller contrib) som man använder. Då man listat ut hur man kan fixa den kan man först applicera den på sin egen sajt, och sedan dela den med communityn så att alla kan få nytta av den. Passar väl rätt bra ihop med public service eller hur?

Min första patch skapade jag förra veckan. Vi använder Redirect modulen för att hantera namnbyten på artiklar. Om en artikel byter namn på vår sajt ändras nämligen också adressen till artikeln, och om artikeln då redan hunnit delas i social medier så skulle besökare den vägen inte hitta artikeln utan redirect modulen.

Problemet uppstår ifall artikeln först döps till ”Kalle Anka är bäst!”, sedan döps om till ”Kalle Anka bäst!”. Då skapas en hänvisning från ”Kalle Anka är bäst!” till ”Kalle Anka bäst!”. Om man sedan döper om artikeln till ”Kalle Anka är bäst!” döps artikeln om, och det finns redan en hänvisning som pekar på ”Kalle Anka är bäst!”. En infinite loop har skapats, då besökaren skickas runt i en cirkel utan att någonsin kunna stanna (Sajten märker dock av felet och bryter loopen, men besökaren kan inte läsa artikeln).

Det felmeddelande som visades var inte särskilt tydligt för en icke tekniskt kunnig. Där stod ”Oops, looks like this request tried to create an infinite loop. We do not allow such things here. We are a professional website!”.

Jag tänkte jag skulle översätta det till något tydligare, samt inkludera ett lösningsförslag åt den som skapade felet. Jag kunde dock inte göra det, för översättningsfunktionen kunde inte hitta meningen i fråga. Jag bestämde mig för att kolla på modulens kod, och kunde där konstatera att t() översättningsfunktionen saknades. Dessutom visades felet som ett grönt statusmeddelande. Jag ville ändra det till ett gult eller rött varningsmeddelande.

Genom en sökning på ”create Drupal patch” hittade jag en manual för att skapa en patch (Quick and simple patch). Man klarar sig med det som står på modulens ”versioner” sida, gör en patch för redirect. Följande Youtube video guidar dig genom git och drupal.org issue skapandet.

I korthet gjorde jag följande:

  1. Ändrade på min local dev version av redirect modulen för att kolla om jag överhuvudtaget kunde fixa problemet
  2. Installerade en ren version av Drupal 7.x (min local dev är så modifierad att det är bäst att testa och skapa patchen från en så ren install som möjligt
  3. Installerade git_deploy som behövs för att generera all info som behövs till patchen
  4. Installerade dev versionen av redirect (git clone av dev branch) och pathauto som behövdes för att testa den ändrade koden
  5. Gjorde ändringarna i filen
  6. Gå till modulens mapp med CMD, kör git status. Du ser då ett meddelande om att filen du ändrat har ändrats.
  7. Kör git diff > [description]-[issue-number]-[comment-number].patch (du kan testa att döpa den till vad som helst, för att se att det fungerar. Filen finns sedan i modulens mapp) Fortsätt sedan med följande steg och döp sedan om testfilen du skapade eller kör kommandot en gång till.
  8. Gick till drupal.org och redirect modulen och skapade en ny issue. Där beskrev jag problemet och hur jag tänkt lösa det. Ta issue nummern från url:en efter att du sparat din issue, och döp patchen enligt namngivningskonventionen. I mitt fall blev det missing_t_function-1903228-1.patch
  9. Skriv en kommentar och bifoga patchen, ändra status till needs review
  10. Vänta på att någon av upprätthållarna kollar på din patch och bifogar den först till dev branchen och sedan till den stabila versionen
  11. Om du inte kan vänta kan du också ta patchen i bruk bara på din egen sajt i väntan på att den blir tillgänglig via modulen
  12. Patchen denna bloggpost handlar om blev infogad i dev branchen efter en vecka

Här kan du läsa issuen jag skapade för patchen:
#1903228 – Missing t() function in drupal_set_message

Användartest – hur kan de hjälpa oss?

Vi har nu för fjärde gången gjort användartest enligt metoden som beskrivs i Steve Krugs bok Rocket surgery made easy. Du kan se en demonstration han gjort här.

Testet är i korthet en ca 15 minuters intervju med 4-5 personer där man ber testpersonen berätta högt hur den resonerar. Man bandar sedan röst + skärm för att kunna analysera i efterhand.

Erfarenheter hittills har varit goda, och det har fungerat väl att använda personer som jobbar inom Yle (inte direkt med webb). Det är tydligt att den här metoden fångar upp de största användarproblemen.

Vi har valt att utföra våra test på en demosajt där de ändringar som vi funderar på att införa finns insatta. I vårt senaste test passade vi också på att testa sådant som redan finns i produktion. Man kan också göra test med en demosajt på papper – det kan vara ett billigt sätt att testa en produkt i ett tidigt skede.

Exempel från senaste testet
Vi bad användarna söka reda på en person från en specifik kommun på svenska.yle.fi/maktbasen – alla fem testpersoner klickade först på listan över kommuner som styr vilken kommun som visas i visualiseringen av ”Köns- och åldersfördelning”. Då de märkte att den inte gick till listan över kommunfullmäktigeledamöter i den kommunen kunde de dock hitta vidare via navigeringen. Att de först klickade på visualiseringen är helt logiskt då man ser på det i efterhand, så där finns utrymme för förbättring.

Det som testet visade att fungerar bra är listan över senaste publicerade nyheter uppe i höger hörn. Normalt en plats som man inte tittar så mycket på. Ett annat var att vi tagit med rubriker från Yle Pohjanmaa, och vill veta hur användaren uppfattar placeringen och det att vi tagit med dem. Vi fick bekräftat att användarna tycker det är bra att de finns med, och att det är bra att de finns längst ner i listan av nyhetslyft så att man tydligt ser skillnad mellan olika källor.

Ett annat resultat som tål att tänkas på för dem som rubriksätter är hur mycket en rubrik kan påverka känslan av ifall saker och ting hör ihop (gruppering). I detta klipp kan du se tre testpersoners svar på frågan ”Vad tycker du om Yle Österbottens sida – föreställ dig att det är din när-region”.

T.ex. uppfattar personerna sidan som ostrukturerad, och det verkar bero på att det finns många mellanrubriker i stil med ”Nyheter” (andra synonymer ”Aktuellt”, ”Senaste nytt”) som ger intrycket av att ”här handlar det om några andra nyheter än dem som jag redan tittar på”. Ett annat exempel är kommentarer kring MGP (eller nöje), man utgår ifrån att det är en allmän mellanrubrik utan koppling till Yle Österbotten. Om man skrivit ”Malaxtjej aktuell i MGP” skulle användaren antagligen ha uppfattat det som en del av Yle Österbotten, och inte upplevt att det plötsligt kommer ett innehåll som inte passar in.

Fördelen med att göra testen internt är att de går att göra med kort varsel. Det är ett litet maskineri så man kan göra det så ofta som det känns relevant.

Testmetoden är också ett bra hjälpmedel inom en stor organisation där man lätt blir blind och projicerar sina interna strukturer utåt, på ett sätt som inte kanske alls är det som slutanvändaren tycker är viktigt.

Lite som den här illustrationen gjord med glimten i ögat :)


Från http://xkcd.com/773/

Användning av data från interna produktionssystem på webben

Många företag genomgår en förändring av hur den tidigare interna datan plötsligt behövs för publikationer på webben. Att ta i bruk data som tidigare inte behövt vara konsekvent gör att man stöter på liknande problem som inom datajournalismen, där det ofta krävs manuellt arbete för att städa upp datan och göra den användbar (Här kan du se ett exempel Google gjort).

Det kan också innebära en förändring i vem som uppdaterar informationen. Tidigare gick det kanske att en person med specialkunskap skötte all inmatning, men nu då det oftast behövs mer information i en snabbare takt behöver den sättas in direkt av den person som först får veta om ändringen/ får tilläggsinformation.

På Yle berörs många system, men det som kanske används av flest personer är Radioman och Plasma (används för att hantera programinformation och sändning).

Orsakerna till varför dessa system tas i bruk offentligt beror oftast på att det är mest logiskt (och sparar pengar) att göra det på ett enda ställe.

Ta till exempel informationen om program. Då den sätts in i Radioman så kan den automatiskt användas på Arenan, i Yles programtablåer på webben, i mobilen och i andra aktörers webbtjänster samt i papperstidningarna. Informationen går också att visa automatiskt på programmens och kanalernas webbsidor.

För användaren av dessa tjänster blir det också lättare att hitta det man söker, t.ex. finns det en bild på den person som deltog i programmet, det finns en programtext som innehåller namnet på de personer som deltog och ämnet som behandlades. På detta sätt ökar hittbarheten då sökmotorerna kan lokalisera rätt program direkt.

Den som surfar på Yles webbtjänster och ser ”Spelas just nu” puffar får veta inte bara vilket program som sänds just nu, utan kan också se en bild och läsa en text om vad programmet behandlar i den sändningen.

Den redaktör som skriver en artikel om ett ämne som det redan finns klipp om kan inkludera klippet från Arenan utan att behöva skriva in en kompletterad programtext, eller sätta till en bild. De som sedan läser artikeln har i sin tur lättare att avgöra ifall de relaterad klippen är intressanta.

Att ett system genererar datan för webbtjänsterna gör det också möjligt att bygga standardiserade lösningar, så att också webbutvecklingen blir enklare och billigare. Lösningarna blir mer framtidsäkra, och gör det möjligt att utnyttja annan internt tillgänglig information för att automatiskt koppla ihop program, artiklar, spelade låtar, Wikipedia artiklar samt andra externa webbplatser.

Det betyder också att ingen behöver ”klippa och klistra” information från ett system till ett annat, vilket frigör resurser till annat mer kreativt jobb.

Användargränsnitt: Hur det underlättar ditt jobb och ökar antalet läsare

Inom Drupal talar utvecklarna ofta om att beställarna inte förstår att prioritera användargränssnittet för de interna användarna. Det är en av Drupals akilleshälar, eftersom om det ofta inom beställar-organisationen inte finns en förståelse för att med Drupal så får man ett system som man bygger sitt eget system med. Då är det inte lika enkelspårigt att se till att användargränssnittet är sådant som slutanvändaren önskar sig. @pixelmord höll ett bra presentation gällande ämnet på Frontend United.

Ett användargränsnitt som inte stöder användarna leder till förluster eller förlorade möjligheter. Läs t.ex. ”The $300 Million Button”. Små insatser kan vara värda stora summor.

På svenska.yle.fi har vi tagit detta i beaktande på flera sätt, t.ex. så finns det en ”föreslå termer” knapp som automatiskt föreslår taggar/termer/kategorier till artiklar. Det ersätter inte att en människa läser igenom och bekräftar de relevanta förslagen. Däremot så underlättar det och snabbar upp redaktörens arbete då de inte manuellt måste söka efter varje ord de vill tagga artikeln med. Då finns det tid att söka efter de relevanta taggar som automatiken inte förstod att lägga till.

Ett annat exempel är att varje intern användare kan ha en egen lista på ”favorit-ämnessidor” dit han/hon* skickar sina artiklar. Utgående från ämnessidor visas artikeln till slutanvändaren.

Därför är viktigt att en artikel som är intressant för både ”Inrikes” och ”Österbotten” skickas till båda ämnessidorna – annars kommer inte användarna som huvudsakeligen väljer att läsa ”Inrikes” vs. ”Österbotten” inte att hitta och kunna läsa artikeln. Ett annat exempel kan vara ”Sport” och ”Västnyland”.

Vi har märkt att denna funktion inte används optimalt inom organisationen, så jag passar därför här på att visa hur man gör för att ställa in sina egna favorit ämnessidor:

Gör så här:
1. Gå till din profil (klicka t.ex. på ditt eget namn i en artikel du skrivit)

2. Klicka på ”Redigera”

3. Rulla ner till ”Favorit-ämnessidor”

4. Skriv in de ämnessidor du önskar (sätt ”Första sidan” sist i listan)

5. Spara

Så här ser det sedan ut då du går in och skall skriva en artikel:

Funderar du på vilka ämnessidor som skulle vara optimala för dig? Sätt till alla sidor du någonsin brukar använda, dvs jobbar du inom nyhetsorganisationen är exemplen ovan åtminstone dem du behöver – detta eftersom de också fungerar som en undermedveten påminnelse då du skall välja vart du skall skicka artikeln.

Ett traditionellt sätt att lösa detta skulle ha varit att tvinga den interna användaren att söka efter varje ämnenssida manuellt, eller att lista dem alla (ca 50 st) åt alla användare. Ingendera är särskilt optimalt eller användarvänligt, speciellt inte på en plattform som skall stödja ett snabbt arbetsflöde för allt från Strömsös recept, vanliga artiklar, bloggar till nödmeddelanden.

* Det är vid tillfällen som detta man kan tycka att hen vore ett praktiskt ord att använda.

Theme layer i Drupal 8 – DrupalCon

Under Drupalcon i Munchen kunde man bekanta sig med de projekt som är på gång inför Drupal 8 (planerad lansering Augusti 2013). Det projekt som kommer att påverka flest användare är Spark / Dries tillkännagivande av Spark. Spark är en WYSIWYG editor som fungerar direkt på sidan, responsiv layout designer, mobil verktygsfält och mobil anpassningar. Allt detta gör det mycket lättare att se hur de ändringar man gör ser ut.

En demo hur Spark fungerar

Spark kommer att finnas som contrib för D7, och målet är att bli del av Core i D8.

Kärnan i Spark utgörs av Aloha Editor som Drupalcon till ära tillkännagav att de ändrat sin licenseringsmodell så att Aloha kan användas i Drupal utan restriktioner.

Aloha Editor är den mest imponerande WYSIWYG editor jag sett. Det är inte bara kodmässigt en bra lösning, utan den ger också användaren en mycket bättre användarupplevelse – mer i stil med hur man redigerar text i Word eller Google Docs. Den klarar till och med av att hantera text som kopieras från Word utan att markupen blir full av onödig kod.

En klar fördel med Spark är också att ”förhandsgranska”-funktionen blir onödig. Detta för att ändringarna man gjort ligger färdigt framme med rätt utseende. På samma sätt som i ett textbehandlingsprogram kan man fritt ändra, för att sedan spara då man själv är nöjd.

Vi funderar på att antingen ta i bruk Spark på Drupal 7 eller att testa Aloha Editorn ovanpå våra befintliga lösningar. Att sätta den på de existerande redigeringssidorna (ej inline i frontend) vore enbart i sig lockande då redigeringsupplevelsen blir så mycket bättre.

Ett annat mål är att snabba upp front end, då den just nu i många system, inte bara Drupal tar en oproportionerligt stor del av tiden. Se t.ex. ”The performance golden rule”.

På BoF (Birds of a feather) diskussionerna om Drupal 8 talades det mycket om Twig som den nya lösningen för templat-lagret. Det verkar som om det råder en konsensus om att det är den bästa vägen framåt. Det jag främst tycker verkar fint är att man kan hämta ut innehållet ur Arrayn på ett tydligare sätt. Många funktioner flyttar också ut från templaten.

Här kan du se presentationen och höra ljudet från A designer-friendly theme system in Drupal 8?

Om du vill testa Twig finns det ett sandbox projekt här. Nackdelar som det talades om är Twigs licens-modell som ännu inte är kompatibel med Drupals, och att Twig som system på ett sätt introducerar ett till lager i templatsystemet.

@JohnAlbin visade också sin kartläggning av theme layer i D7 jämfört med D8. Det är en viss skillnad i komplexitet :) Uppdatering 11.9 – här kan du jämföra kartläggningen av D7 med den i D8.

Det talades också om möjligheten att skapa genriska hooks, vilka kunder återanvändas av contrib moduler. Skulle isåfall kunna betyda mindre templat-kod i modulerna. Blir intressant att se om det blir av.

Kan också notera att temandet väcker större intresse, t.ex. tog sittplatserna slut vid åtminstone två tillfällen.

Missa heller inte Drupal 8: What you need to know.

Övrigt
@emmajanedotnet höll en bra presentation av vad man bör tänka på då man väljer bastema. Det här skulle jag själv ha velat höra för ett och ett halvt år sedan. Frågan är ifall ngt kunnat göra jämförelsen då, rätt mycket har ju hunnit hända. Har du inte valt bastema ännu, kolla på denna.

Case: svenska.yle.fi as a mobile first responsive design

This is a blog version of the presentation I held at Drupal Camp Helsinki 2.6.2012

If you prefer, watch this recording of the presentation:

So why mobile first web app, and not an app or mobile specific site?

We knew we wanted to have a mobile first responsive design, so we talked to people about what their experiences where and became even more convinced that this is the way to go forward.

I recently read two good blogposts on the subject, one by Josh Clark

“First, a growing number of people are using mobile as the only way they access the Web. A pair of studies late last year from Pew and from On Device Research showed that over 25% of people in the US who browse the Web on smartphones almost never use any other platform.” … ”There’s a digital-divide issue here. People who can afford only one screen or internet connection are choosing the phone. If you want to reach them at all, you have to reach them on mobile. We can’t settle for serving such a huge audience a stripped-down experience or force them to swim through a desktop layout in a small screen.” – Josh Clark

in Netmagazine and an other on by Bruce Lawson in Smashing magazine.

It pretty much summarizes they way we at svenska.yle.fi look at it.

By designing the system (not site, I see it much more as an ecosystem when designing responsive sites) mobile first, and not hiding content from mobile users you are reaching a bigger audience. The same by not requiring users to download an app and keep updating an app. It is also less expensive to maintain, and one has to remember the cost of marketing the app so that users find it.

With an web app/mobile first site shared content is always displayed in the best way possible for the end user, depending on the device.

The perhaps most successful web app is Financial Times. It is much more device tailored than our site, but we embraces the same thinking.

When we look at our numbers, we have gone up from 8.5 % mobile usage (of total traffic) in January 2012 to 13 % in May. – svenska.yle.fi

Actually making it mobile first

Making the site mobile first sets some limitations, and also affects the design process. People are designing from mobile to desktop, or from desktop to mobile. In my experience it works best to work on all sizes at the same time, while keeping the technical limitations of mobile in mind (designing in the browser, read more in this slide by Edward O’Riordan @edwardoriordan (Front End United 2012 Amsterdam).

Drupal, Omega and mobile first

The way Omega/Drupal includes (compresses) the CSS files prevents us from using javascript to load the CSS files only when needed (blogpost about how it could be solved).

The reason for wanting to use Javascript is because media queries always are loaded even though they are not used.

I am planning to try out if changing the weights of the CSS groups can join some of the compressed CSS groups we currently have.

We also ran into extra work with IE specific CSS files, as it is impossible to use weights to add them after the Omega CSS files. We ended up using more targeted CSS selectors for IE.

The amount of DIV’s is also something that is not optimal, as you can see in this image. More than half of the DIV’s could be removed.

Which theme, fluid or set of sizes?

The hottest theme in 2011 was Omega, and we decided to go with that one as we saw it as opportunity to get something off the shelf that was not perfect, but works. We wanted to focus our resources on making the solutions that were not available to us the best possible (and theme independent).

We decided to go with a set of sizes because it gives us better control over the layout.

I was asked a question during the presentation; ”What theme would you use if you would start from scratch with the knowledge you now have”. The answer is I don’t know, I would definitely look at what options are available – and most likely end up with a custom theme because of our specific needs.

Layout

We decided to go for a very sparsely decorated layout, to keep the UI clean and to make the basic responsive design as light as possible. We wanted to gain experience before we had built a swamp that it is difficult to dig yourself out of.

I also wanted to develop a new method, and embrace the possibilites – while leaving pixel perfect behind.

To do this I defined areas for graphics (at this stage the top of the page can be modified and display anything you like to make in Photoshop). This way I kept the layout completely CSS generated. An other defined area is for banners. They can be added anywhere, but we are still in the process of working out how they best are constructed.

Images

The first thing we tackled were images. Fortunately we have our own homebrew Image Management System (IMS) that made it possible to get the images in many different sizes.

The solution we implemented first displays a regular small image that works on mobile, and then if javascript detects that the screen size is wide enough switches to a bigger size.

First load

<img itemprop="image" alt="VPS, augusti 2011" title="VPS slog HJK." src="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_6.jpg" width="200" height="113" class="imsImg" data-ims-id="58628" />

After the javascript has been loaded

<img itemprop="image" alt="VPS, augusti 2011" title="VPS slog HJK." src="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_5.jpg" width="200" height="113" class="imsImg processed" data-ims-id="58628" data-src-fluid="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_5.jpg" data-src-narrow="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_4.jpg" data-src-normal="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_6.jpg" data-src-wide="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_5.jpg">

In the javascript we have set different sizes to be loaded depending on the image size that best fits the layout template the image is displayed in. The layout template also has different settings per size.

To prevent the images from making the page flicker when the bigger image is loaded and inserted into the page we specified the image size in the CSS. This makes the image look blurry for a while when the page is loading, and then has a “sharpen” effect when the bigger image is displayed.

Video & audio

Most of our videos and audio are embedded from our media service Arena, and fortunately it was also being rebuilt at the same time. This meant that we got a Flash free first embed, that has a big effect on our mobile first approach and the rwd solution is out of the box. The solution could be improved by making the embed mobile first (the image is one size only). Flash is required for playback.

For Youtube and Vimeo we are using FitVids.js

KB size and http requests

The image and video solution means that the KB size was solved. One can argue that only one image file should be sent to the desktop users (instead of two), but I find the solution benefiting also them, because the image will display faster even though it is blurry.

To limit the amount of http requests, KB size and user experience (quick load for all sizes) we made the social media share buttons load only after the user on desktop hover on the text. On mobile they are loaded only after the user clicks on them.

To make articles load quickly only the article itself and content closely associated with the article is loaded (article text, image, lists of related articles, most read, most commented). If the javascript detects that there is sufficient screen space it loads the content of the subject page the article belongs to. If not, links are displayed that takes the mobile user to the same content.

So did it pay off? I think so :)

The data was collected with Yslow for Firefox.

The reason the subject pages are not lighter on mobile is that we currently do not have a breakpoint that would allow us to not load part of the page content on mobile (but offer a link like we do on articles).

Lessons learned

In Views, always unclick to remove the extra markup – and give the block a unique style name so that your CSS is not dependent on block names.

We used a small image in our first iteration, and got feedback on that it was to small – so we changed that. Now we get some feedback that it is too big. I think think this is related to the fact that mobile is becoming the primary device, and you want to have the full version – you don’t want a preview that forces you to use a desktop to see the full image. So some more work needed to make all user types happy.

Iframes and auto height is causing grief. No perfect solution yet.

What to do next

This is the presentation itself (via Slideshare)

Drupal Camp Helsinki nu på lördag 2.6

En påminnelse till alla som är intresserade av Drupal, nu på lördag 2.6 kommer Drupal Camp Helsinki att hållas i Yles utrymmen i Böle, Helsingfors. Bland annat kommer vi att berätta mer om hur nylanseringen av svenska.yle.fi gick till, responsiv design & mobile first och hur vi jobbar med meta data nu och planer för framtiden. Det kompletta programmet finns på drupalcamp.fi. Det kommer också att finnas en stream på Arenan för dem som inte har möjlighet att närvara i Helsingfors.