Om Mårten Seiplax

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

Two teams, two sites – one year with a shared Drupal distro at Yle

Today one year ago FYND (Finnish Yles New Drupal) launched it’s first site. Read about the work that went into the preparations here.

It has been a year of shared development when we really have seen the advantages of working on the same distro, and working with open source.

One of the first things we decided on was to work as two teams in a similar way to how NBC Universal works with their Drupal sites (or cells if you want to compare to how Supercell works).

”Clash of Clans and Hay Day were each developed by teams of just five developers. Even now they are global smashes each has a team no bigger than 15.” Ilkka Paananen in Wired Magazine

Is Five the Optimal Team Size? …the cost per function point of a team of size 7 was $566 and that of a team of size 14 was $2970 – Jeff Sutherland…If you have 3 team members, then you will have 4 communication channels, if you have 4 then you have 9. I think the formula is m-1^2. In my opinion, a small team of 4 or 5 is ideal. – PMHut

One idea that also was put forward was that we should work as one big team (quite common in big organisations I guess). We did however pursue the idea of having two teams, since we assumed this would make us more focused and productive. It would also allow us to better understand the business goals and needs if we got them independently from two sources (Svenska Yle and Yle Luovat sisällöt).

Issues in YDD

One year on we are happy with the end results, as the distro has continued steadily on its development path.

The main advantages with two teams and two sites have been:

  • Twice the amount of tasks have gotten done – everyone benefits
  • Maintaing the distro core is a shared task
  • You focus on the task at hand – not a zillion tasks all over the place
  • When there has been a module problem, there has been a clone site to compare with
  • We can mitigate the risk when a new function or module is activated, as we can share the burden by activating it on one of the sites before activating it on the other
  • It has been possible to compare notes, and get an “external” view on different tasks
  • External human & tech resources can be shared between the teams
  • Cross reviewing (using pull requests)
  • Documentation and best practices are better maintained as you clearly see the need and gain. In our case two semi separated teams provide better quality assurance than before
    • One observation is that quality assurance has gone up. One theory we have discussed is that it is because the teams see the other team as an outside party. The team members become aware that someone else will suffer if they write bad code or do not test their code. Just like in open source development where many eyes check the code, we are doing the same on a low level.

Main disadvantages:

  • Time is needed for co-ordinating
  • Time is needed to separate the settings for the two sites, but this would be needed just by the fact that we are running sites with two different languages
  • Risk for conflicting business goals – but this has been kept at bay by clearly stating that the purpose of the system is to provide articles publishing according to subjects.
  • If you break something you will get blamed

Some of the functionality we have shared over the last year:

  • API connections
  • New version of the Image Management System
  • New meta data solutions for Finto and Freebase

The structure we made on the technical side has worked out nicely, and we have not run into any problems that we have been unable to solve.

We have also found that the business goals are quite similar, and it has not been a problem to agree on changes in the shared core functions.

There has also been spillover in other areas. The content teams can check out what the other teams are doing and get inspired to do the same in their own site.

Workflow

When there is a request for a new feature the product owner of svenska.yle.fi checks with the product owner at yle.fi/aihe (or vice versa) if they also are interested. If they are we will make it for both SYND and FYND (YDD wide). Depending on the type of issue and how important it is for the sites we will negotiate about which team builds it. Maintenance issues have been shared 50/50.

If it is not a shared goal it will be made for the site that requested it – or it might not get made at all. This is a good checking point, if the feature is not of interest in another site that has almost the same functionality it might not be such a crucial feature after all.

We have a shared issue backlog, but we separate the issues as for both SYND and FYND, or only one of them.

In one month we will celebrate two years with SYND. More about that later.

Ny version av IMS på svenska.yle.fi

Efter fem år och 165 000 bilder är det dags att ge IMS (Image management system) som används på svenska.yle.fi ett ansiktslyft. Den nya IMS-versionen har nya funktioner och ett nytt utseende. Om allt går enligt plan tas den i bruk onsdag 26.3.

För alla användare betyder det vissa förändringar, här kommer några skärmdumpar och info om förändringar:

Man öppnar IMS på samma sätt som tidigare

Man öppnar IMS på samma sätt som tidigare. Nu kan man också öppna bilden för redigering genom att klicka på bilden.

Så här ser första vyn ut där man kan välja vad man vill göra

Så här ser första vyn ut där man kan välja vad man vill göra

Bläddra och välj bild

Bläddra och välj bild

Vy man ser då en ny bild har laddats upp

Vy man ser då en ny bild har laddats upp

Om den bild man laddar upp inte är tillräckligt stor varnar systemet om detta. Minimistorlek är 1600×900. Systemet tillåter dock allt som är större än 640×360 px.

Det finns skäl att alltid eftersträva en så stor bild som möjligt. På svenska.yle.fi börjar vi nu använda en bild som är 880×495 px. Om bilden inte uppfyller den storleken kommer vi att förstora den artificiellt. Man kan jämföra med hur man gör med 4:3 bilder som sänds i tv som 16:9.

En annan aspekt är att högupplösta skärmar tas i bruk i allt större utsträckning. Det gör att vi väldigt snart är tvungna att ta i bruk en ännu större storlek fast vår bildbank i IMS inte har tillräckligt stora bilder. Ladda därför alltid upp bilden i största möjliga storlek.

Beskärning går nu att göra i 16:9-, 1:1- och 2:3-format

Beskärning går nu att göra i 16:9-, 1:1- och 2:3-format

Till de bildversioner som besökarna på svenska.yle.fi ser använder vi en automatiskt ansiktsigenkännings-funktion ifall en manuell beskärning saknas, vilket fungerar i 70-90% av fallen. Det ersätter med andra ord inte att en människa beskurit bilden. Då du skall beskära de enskilda formaten klickar du på respektive miniatyrversion (som automatiskt visar en förhandsversion av slutresultatet).

Om beskärningar inte gjorts så ser bilden ut så här för administratorer, så att man skall ha en möjlighet att se att bilden inte är beskärd.

Om beskärningarna saknas ser bilden ut så här för administratörer. Orsaken är att man då ser att bilden behöver beskäras.

Då du väljer en bild skall du alltid kontrollera att beskärningen är korrekt. I föregående version av IMS sparades inte beskärningsdatan eftersom beskärningarna sparades direkt i den enskilda bildfilen. Det ledde till att vi inte kunde återskapa hur bilden varit klippt tidigare. Oberoende av det så behöver en människa kontrollera 1:1- och 2:3-formaten som är helt nya och saknar beskärning.

Detta gör att en okänd procentandel av våra bilder nu är klippta på ett icke kontrollerat sätt (skedde per automatik vid migreringen).

Om du ser en bild som behöver korrigeras kan du öppna den i IMSen genom att gå in och redigera artikeln. Väl inne i artikeln öppnar du den specifika bilden i IMSen genom att klicka på bilden.

De enskilda fälten har fått förklaringar:

För att andra skall hitta din bild lönar det sig att  skriva bra taggar. Separera taggarna med kommatecken,

För att personer som har en synnedsättning också skall veta vad som visas på bilden är ALT-fältet obligatoriskt.

För att personer som har en synnedsättning också skall få veta vad som visas på bilden är ALT fältet obligatoriskt.

Detta fält var tidigare inte obligatoriskt. Om du redigerar en gammal bild blir du därför tvungen att skriva beskrivningen.

Till de nya funktionerna hör:

  • I de situationer som svenska.yle.fi av layoutmässigaskäl behöver veta bildens format och storlek kommer 16:9 formatet att användas
  • Exempel: En bild som du laddar upp kommer alltid att finnas också som 16:9. Om bilden är satt som huvudmedia i en artikel kommer den med nuvarande layout aldrig att visas som 1:1 eller 2:3. 1:1-, original- och 2:3-beskärningen kan du använda inne i en artikels brödtext genom att då du sätter in bilden välja en av dem.
  • Inne i artiklar kan man välja att en bild är 1:1, 16:9, originalformat eller 2:3
  • Inne i artiklar kan man välja att en bild är viktig, den kommer då att visas i ett större format än en bild som är insatt som standard
  • Du kan ladda ner en bild i den storlek som Arenan behöver direkt från IMS
  • Bilderna levereras nu via en CDN (Content Distrubution Network) som gör att bilden levereras snabbare för att den kommer från ett datacenter som är nära användaren
  • Rotera bilden direkt i IMS
  • Bilderna kan visas i vilken pixel-storlek som helst, vilket gör att vi kan skapa bättre användarupplevelser. Vi kan ladda bilder exakt så stora som de på riktigt behöver vara, och användaren behöver inte ladda ner en för tung bild.
  • IMS kan stänga av visningen av alla bilder i svenska.yle.fi om vi av ngn orsak måste minska på hela sajtens vikt. Kan bli aktuellt t.ex. vid en DoS-attack.
  • ”Ersätt bilden”-funktionen beaktar att bildens bredd/höjd kan ha ändrat

De första dagarna kommer bilderna på svenska.yle.fi och admin att vara lite långsammare, men snabbas upp vartefter fler och fler av bilderna har visats och lagras i CDN:ens cache.

Tack till Rasmus och Tero för deras insatser.

Improve workflow & UI by making a Entity Reference View with multiple fields

User story: Help editors pick the correct representation of an article when connecting it to be displayed in a new department.

Background: We noticed that editors where picking the wrong representation of an article as there can be many of them. The reason for this being that we let editors customize the representation of their article depending on the department where it is being used.

Solution: Change the Entity Reference (usually a simple entity selection field) to a Entity Reference View.

Step by step: 1. Go and create a new view, add a Entity Reference display, and add the fields (filters etc just like a regular view) you want to display to the editors. If you select more than one field you will need to specify the ”Search fields” (Format –> Settings). In our case we added the date and department title. We are also thinking of setting a sort criteria DESC as it is likely most editors are looking for recently published content.

2. Go to your content type, and edit the field that is a Entity Reference. Change the reference selection to a view, and then pick the view you created. In ”View used to select the entities” select the display you made.

Entity reference

3. This is the end result with some additional CSS work:

Styled entity reference

Just adding the fields would have improved the editorial workflow, but just a little bit of CSS helped to make it even more usable. I removed the default wrappers and added some custom CSS classes for the fields. This way I was able to adjust the styling of the title, date and department.

.reference-autocomplete {
  border-bottom: 1px solid #f1f1f1 !important;
  padding: 3px 2px;
}
.reference-autocomplete:hover{
  border-color: transparent !important;
}
.reference-autocomplete span.er-node-title {
  font-weight: bold;
}
.reference-autocomplete span.er-post-date {
  color: #555;
  font-size: 0.8em;
}
.reference-autocomplete:hover span.er-post-date {
  color: #f1f1f1;
}
.reference-autocomplete:hover span.er-promo-parent-subject-page, .reference-autocomplete:hover span.er-kicker, .reference-autocomplete:hover span.er-content-type {
  background-color: #f3f4ee;
  border-radius: 3px;
  color: #0072b9;
  padding: 1px 2px;
}
.reference-autocomplete span.er-promo-parent-subject-page, .reference-autocomplete span.er-kicker, .reference-autocomplete span.er-content-type{
  color: #555;
  font-size: 0.7em;
  font-weight: bold;
  text-transform: uppercase;
}

Decided to style all Entity References in the admin theme with a bit more padding and a border-bottom line as it improves readability.

When trying to inspect the autocomplete div I noticed it was quite difficult to grab it via the inspect element function, but grabbing it via ”Copy as HTML” worked. This is what the basic markup looks like on a regular Entity Reference Simple field.

<div id="autocomplete"><ul><li><div><div class="reference-autocomplete">Österbotten</div></div></li><li><div><div class="reference-autocomplete">Kontakta Yle Österbotten</div></div></li><li><div><div class="reference-autocomplete">Lyssna på Radio Vega Österbotten!</div></div></li><li><div><div class="reference-autocomplete">Valet i Österbotten</div></div></li></ul></div>

The class-name of the line you hover on is named ”selected”.

Thanks to Olli Vesslin.

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.