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

  • Improve the theme / switch to a newer one
  • Improve on Twitter, Facebook integrations – they are not working correctly with the responsive design
  • Other external resources such as data visualizations, weather, sport results
    Responsive visualisation with Raphael
    Small enough to work on mobile
    Sports results – not responsive at all
  • Work more with the layout
  • Implement bigger images on desktop (that is why we currently have a grey box next to images in articles – backend is not done yet)
  • Build a content breakpoint on subject pages

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.

Första dagen med en live Drupal sajt

Sådär, första dagen avklarad. Lanseringen började kl 6 då load balancern ändrades att peka på den nya sajten. Det blev att surfa igenom alla sidor och ändra endel inställningar som vi inte kunnat göra förrän den nya sajten fanns på den riktiga adressen. Vi kunde även ganska snabbt notera att Varnish konfigurationen ställde till med problem för två mappar, då den meddelade att sidan inte kunde hittas istället för de mappar som Drupal behövde. Detta kunde dock fixas snabbt och jag betvivlar att någon hann märka problemet som manifesterade sig genom att vissa javascript funktioner inte fungerade.

Vid halv elva var vi så nöjda med sajten att vi vågade gå på lunch och sa att det är ok att börja prata om att vi har en ny sajt. Vid tolv snåret kom en planerad 15 sekunders ändring i load balancern, då man ännu såg den gamla sajten. Den råkade dock fastna i Varnish, så det blev längre än 15 sekunder.

Vid 15 tiden lade vi sajten i underhållsläge för att göra de ändringar till sajten som vi redan före lansering visste vi ville rulla ut, men som vi väntade med för att se om vi skulle märka ngt mer som behövde ändras (och krävde driftsstopp). Som ni som jobbar med Drupal känner till är det inte sådär bara att göra en update, speciellt inte då man har en halv miljon noder.

Tyvärr så blev det överbelastning under tiden som vi gjorde driftsuppehållet, så därför tog det längre än väntat. Endel märkte av det, andra inte, beroende på vilken av cache servrarna som levererade sidan till dig och om sidan fanns i Varnish.

Efter det så redde det upp sig, och vår IT-leverantör jobbar vidare med konfigurationen så att det inte skall ske igen. Inom kort kommer vi också att flytta till en egen virtuell server – så ett till driftstopp är på kommande.

Responsmässigt kan man konstatera att det många reagerar på är navigering och layout – även om det här verkar vara en sak som delar åsikterna.

Många har också frågat om beta logon – vårt resonemang är att använda oss av ”release often, release early”. I allt för många stora IT-projekt så satsar man på att specificera funktioner under en lång tid, en tid som defacto blir så lång att specifikationerna föråldrats innan de ens hunnit börja förverkligas. Dessutom är specifikationer inte perfekta, utan behöver justeras.

Genom att gå ut med en sajt som inte är 100% färdig (vad är färdigt är ju en definitionsfråga, och en webbplats blir ju aldrig klar) vill vi kunna bygga en bättre sajt utgående från användarnas prioriteringar och behov. Därför har vi också valt att behålla beta logon nu medan vi extra aktivt tar emot användarrespons.

Vi kunde i allafall glädja åt oss åt 39 % fler unika besökare igår 🙂

Dag två har så här långt gått åt att finjustera Varnish-konfigurationen ytterligare. Våra gamla sajter har inte tidigare serverats via Varnish, vilket gav några oväntade problem med responsformulär och kommentarsfält och motsvarande som inkorrekt också lagrades i cache-minnet trots att de inte borde ha gjort det.

Under förmiddagens lopp så borde också de här problemen vara undanstökade, och nu kan vi ha glädjen av att också de gamla sajterna (som Mat & fritid) också levereras mycket snabbare än förr.

Hur fungerar bilder i IMS?

Bilder som används i artiklar som publiceras på svenska.yle.fi hämtas från bildhanteringssystemet IMS (Image managment system). Här kommer en kort förklaring av hur det är uppbyggt och skall användas.

Då en bild laddas upp behöver följande delar fyllas i:

Taggar
För att hitta bland alla dessa bilder har vi valt att använda taggar. Dessa taggar är i dagens läge ännu friform (dvs redaktören kan själv hitta på beskrivande ord eller förkortningar – huvudsaken är att de är ord som andra känner till och skulle kunna tänkas söka på då de söker en bild till sin artikel.). Taggarna sparas också inne i bilderna, och kan påverka hur relevant en sökmotor uppfattar att en artikel är. I framtiden blir det aktuellt att koppla ihop taggningen med ontologier (Läs ”Varför skall jag tagga min artikel?”).

Alt
Text som beskriver bilden. OBS! Inte en text som beskriver artikeln i vilken bilden kommer att användas. Skall vara en text som beskriver bilden så att någon som har nedsatt syn/är blind också kan förstå vad som finns på bilden. Används också av sökmotorerna för att bedömma en artikels relevans.

Copyright
Vem som tagit bilden och innehar copyright. Ifall bilden är tagen av ngn på Yle skriver man Förnamn Efternamn / Yle

Anmärkningar
Ett internt meddelandefält, som bör användas för att märka ut specialinfo om bilden, t.ex. om det är en bild från en bildbyrå med specialanvändningsregler.


De system som är kopplade till IMS har varierande lösningar för bildtext.

I nya svenska.yle.fi kan man efter att man hämtat sin bild från IMS lägga till en bildtext. Denna bildtext sparas i den enskilda artikeln. Den kan därför anpassas per artikel.

Du som använt IMS tillsammans med den gamla nyhetssajten – använd bildens ID då du vill sätta till en bild i nya svenska.yle.fi


Vad syns åt användaren?

  • Alt-texten syns för personer med nedsatt syn. Vissa webbläsare visar Alt-texten då man sätter muspilen på bilden.
  • Copyright visas utskrivet under bilden.
  • Bildtexten som skrivits in i Drupal visas utskrivet under bilden.

Om IMS
Vår bildhanteringssystem innehåller i skrivande stund ca 90 000 bilder. Systemet skapades och togs i bruk 2008/2009. Systemet är består av en frontend API och ett internt backend-system där bilderna laddas upp och redigeras. Vilket CMS som helst kan kopplas till IMS.

Då en bild laddas upp i backenden sparas originalbilden (ladda därför alltid upp bilden i så stort format som möjligt) på en intranät skiva, och samtidigt skapas automatiskt nio mindre versioner av bilden. Dessa nio är de versioner som syns i artiklarna (storleken beroende av layouten).

Förändringar som är på kommande under 2012 är möjligheten att ersätta en redan uppladdad bild samt större bildstorlekar. Beskärningen av bilder kommer att ändra från att ske per bildstorlek till att ske per relation (16:9, 1:1, 10:15).

Hur många bilder går inte att få i en större storlek?

En av utmaningarna med vår nya design är att bilderna i vårt bildhanteringssystem inte är tillräckligt stora för att passa in i de bredare versionerna av den responsiva designen.

Systemet har funnits så länge att det var ett problem bara att sätta standarden 640×360. Vår rekomendation har varit att man skall ladda upp bilden i originalstorlek till bildhanteringssystemet (IMS).

Igår då jag fick en dump av de storlekar som finns i systemet var det med spänning jag kollade hur väl det gått.

I grafen ovan kan ni se skillnaden mellan bildhanteringssystemet som kanalerna (Svenska) använder jämfört med nyheterna.

Den nya minimistorlek vi behöver är 880px. Det betyder att 31% av nyheternas bilder inte klarar av att fylla utrymmet. För kanalernas del är det 21%. Skillnaden förklaras dels av att kanalerna använder mer pressbilder som är högupplösta.

Ifall vi skulle välja att gå till en ännu större storlek står vi inför situationen att upp till 45 % av bilderna inte uppfyller kraven.

Alternativen vi står inför är:

  • Lägga till svarta kanter på samma sätt som man gjorde övergången till 16:9 i tv-världen – och kan vi då höja minimikravet till 880px för alla nya bilder som laddas in i systemet? Eller behåller vi kravet på 640 och sätter svarta kanter på allt som inte är 880px eller större? Snyggt lär det ju inte bli …
  • Slänga de bilder som inte uppfyller kraven