För ett tag sedan lyssnade jag på en intervju med Kevin Cheng och återuppväckte mitt intresse för att skapa serier. De har visat sig vara ett effektivt verktyg för att kommunicera användarupplevelser på webben.

Kevin Cheng driver sajten OK/Cancel dit jag brukar gå för att få mig ett gott skratt oss usability-nördar emellan. Sajten bygger kring hans serier om sig själv. Han håller också en kurs på konferensen User Interface med titeln Communicating Product Concepts with Comics, som gav Jared Spool anledning att intervjua honom.

Serier gör att många lättare förstår vad du menar

Det visar sig att serier är ett otroligt bra sätt att uttrycka idéer kring user experience, alltså på vilket sätt som användarna tar till sig och förhåller sig till information. I tidiga stadier av ett projekt visar serierna hur användarna kommer uppfatta en viss design och de kan även vara ett sätt att nå konsensus mellan kompetensgrupper kring vad sajten går ut på.

Serier tillåter också att du itererar (upprepar i syfte att förbättra gradvis) utan alltför höga krav på tid och resurser. Och nej, du behöver inte vara en snitsig illustratör. Streckgubbar tjänar också ett syfte och Kevin tillhandahåller även mallar, vilket du ser prov på här. Det viktiga är att du vet vad du snackar om och kan kommunicera!

Som trendspanare inom webb registrerar jag mig på ohälsosamt många sajter varje vecka. En detalj stör mig lite mer än andra och det är när jag ska mata in mitt födelsedatum.

I princip borde väl inte mitt födelsedatum behövas men jag kan ta det eftersom det är skönt egotrippat att få en födelsedagshälsning när man går in på en sajt.

Tankevurpa i formulärbygget

Men hur jobbigt är det inte att varje gång behöva skrolla ner från år 2007 till 1974? Inte för att man känner sig gammal, men för att det är onödigt pilligt.

Allra bäst är självklart att ge tusan i rullgardinsmenyer och låta användaren själv mata in födelsedatum i ren text och sedan med lite intelligent kod spara ner det i önskat datumformat.

Sanning: Ju färre gånger du byter inmatningstyp på fälten, desto snabbare går det att mata in innehåll. Rena textfält rockar.

Envisas man med rullgardsinmenyer för årtal så borde man väl ändå kunna anta att snittåldern på de som registrerar sig är någonstans mellan 20 och 35. Nåväl: i alla fall är det sällan spädbarn som går in och reggar sig.

Mitt heta tips till alla som har val av år i någon form är alltså: låt förvalet ligga på 1980 eller något annat år som känns hyfsat relevant. Smartast är ju att göra en uppslagning i databasen och ta snittåldern på den befintliga användarskaran.

Då kan jag tabba mig igenom formuläret och med ett fåtal(!) knapptryckningar på piltangenten nå mitt eget årtal.

Ibland är det så enkelt som man tror.

Med den cyber-anpassade akronymen UX inledde Brandon Schauer tvådagarskonferensen from Business to Buttons som väntat: amerikanskt storslaget med en snitsig slideshow inför 300 nickande nördar: "ja, precis så ligger det till..."

Brandon pekar framför allt på hur vi måste tänka mer strategiskt för att komma någon vart i i våra undersökningar av användarnas behov. Vi måste nu ta steget längre än användarnytta, usability och Return on Investment. Höstens buzzword blir Experience Strategy.

Det handlar bland annat om att placera sin egen strategi i relation till en större trend, att visuellt (med bilder och design) visa vart företaget eller organisationen är på väg och vad vara och en måste göra för att nå dit.

Inte ett ord om Internet

Det skönaste med konferensen var kanske att komma ur sessionen som jag deltog i under dag 2 och inse att vi inte pratat om Internet för en sekund; vi pratade om Experience Mapping.

Under ledning av kulturantropologen Ben Jacobson från Conifer Research lärde jag mig mer om etnografiska undersökningar och hur man använder dem för att att identifiera problem och behov. Tidigare skulle jag kanske helt enkelt kallat detta för fältstudier men genom att tydligt uppmärksamma att det finns en hel forskningssfär som sysslar med detta ger det lite mer tyngd åt metodens förmåga att ge konkreta och användbara resultat.

Precis om alla kulturer har användarkulturer sina egna

• artifakter och verktyg,
• rum och platser,
• roller och hierarkier,
• ritualer och övertygelser samt
• samt symboler och språk.

Genom att förstå hur våra målgrupper förhåller sig till alla dessa kan vi erbjuda dem en bättre upplevelse.

Framför allt gick vi igenom modellen för Experience Mapping och fick oss tillhanda en bra metodik för att dokumentera användarbeteende och användarmönster i olika givna situationer baserat på de fem beståndsdelarna:

1. Entice - hur hittar man fram till upplevelsen
2. Enter - hur kommer man in/introduceras man i aktiviteten
3. Engage - hur upplevs/fungerar själva aktiviteten
4. Exit - hur går man ur upplevelsen
5. Extend - hur förlängs upplevelsen (souvenirer/foton/minnen)

Användartester räcker bara halva vägen

Något som jag själv försökt uttrycka under de senaste åren är att användarundersökningar och intervjuer bara räcker halva vägen om vi vill försöka utreda behov. Hade jag pluggat etnografi eller socialantropologi hade jag alltså kunnat uttrycka det bättre, som jag nu kan göra tack vara Ben Jacobson.

En människa har olika behov:

1. Explicita behov - behov som man själv på ett enkelt sätt kan uttrycka och berätta om
2. Taktila behov - behov som man inte är direkt medveten om men som kan komma fram i intervjuer (om intervjuaren är duktig) och på så sätt reflektera över dem och vara överens om dem
3. Latenta behov - behov som man inte alls är medveten om utan som egentligen bara kan komma fram genom observation eller genom att något "viktigt" tas ifrån dig

De latenta behoven kommer vi aldrig hitta i intervjuer - de hittar vi alltså bara genom att delta i aktiviteter och observera människor.

Mycket mer än usability

Det viktigaste budskapet jag bär med mig från konferensen From Business to Buttons är: mer och mer måste vi uppmärksamma och förhålla oss till den slutgiltiga upplevelsen mycket tidigare i utvecklingen av våra webbplatser.

Vi kan inte bara börja med att utveckla gränssnitt och informationsarkitekturer som vi iterativt testar - vi måste först identifiera vad vi vill att människorna ska känna/uppleva/se, hur det ska kännas i förhållande till liknande webbar, vilka regler som ska gälla och hur strategin ska se ut.

Någonstans handlar det om att vi måste bli bättre på att leka fram resultat och låta användarna leka sig fram på webbplatsen. Världen väntar på unika, enkla verktyg som ger dem fler fördelar.

Sluta inte läsa...

Det vackraste med personer som Brandon Schauer från Adaptive Path är förstås att de i sin blogg ger källhänvisningar till allt de pratar om, så att man själv kan gå dit och fördjupa sig.

Glöm inte heller bort att lyssna på min intervju med Brandon Schauer i första programmet av Webbtrender.

Självklart kommer jag återkomma till konferensen i flera blogginlägg och jag räknar iskallt med ett besök i Malmö i juni nästa år igen. Ett stort tack till arrangörerna för uppstarten av denna internationella konferens i vårt lilla hörn av världen. En mer prisvärd konferens i Sverige är svår att finna.

När jag förklarar Ajax är det många som frågar mig om jag kan ge några exempel på webbplatser som använder det. På allmän begäran kommer alltså här en snabbt ihopknåpad lista.

Ajax sägs ofta stå för asynkron javascript och xml, men faktum är att Ajax-tillämpningar inte behöver använda XML och Jesse James Garrett (mannen från Adaptive Path som myntade begreppet) vill inte att det ska var en akronym.

Ajax är snarare ett samlingsnamn för tekniker som gör det möjligt att ladda och visa innehåll från servern på en webbsida utan att ladda om själva sidan. Fördelarna över Java och Flash är snabbare laddningtid och ett gränssnitt som är förenligt med övriga webbplatsen.

Kom ihåg att ingen webbplats blir självklart bättre för att man smackar på lite Ajax: du kommer inte ifrån behovsanalys och användartester; och det kan ställa till en hel del problem med tillgängligheten.

Jag säger som Spider-Man: "With great power comes great responsibility".

Här kan du i alla fall spana in lite Ajax

• Fysiklektion med hjälp av periodiska systemet (ett klockrent enkelt exempel)
• Håll din kalender synkad hos Kiko eller Google Calendar
• Skapa egna formulär hos JotForm eller Wufoo
• Mixa filmer hos eyespot
• Personlig portal hos Netvibes eller Protopage.
• Rättstavning hos Orangoo eller PrimalGrasp.
• Att-göra-listor hos Remember the milk, Backpack eller Todoist
• Tjöta med andra hos Gabbly eller Chat utan chatprogram hos Meebo.
• Hantera din tid med TimeTracker.

Vill du lära dig Ajax?

• Ajax: Getting started

Idén med accesskeys, eller snabbtangenter, på en webbplats är på något vis godhjärtad. Men ack så fel det ibland kan bli med gärningar som vill väl. Min rekommendation är att vara försiktig med accesskeys och helst endast använda dem om du vet exakt vilka andra program som dina besökare använder. Genom att erbjuda vanliga länkar på rätt ställen kan du komma långt.

En accesskey låter dig hoppa till en specifik del av webbsidan med hjälp av tangentbordet (ungefär som en genväg). Tanken är att låta användare som har svårt att använda en mus att snabbt komma till specifikt innehåll på sidan; vanligast är att kunna hoppa över navigeringen och komma direkt till innehållet. Om man till exempel har en skärmläsare som läser upp inehållet vill man inte höra navigeringen läsas upp varje gång; eller så kanske man vill hoppa direkt till inmatningen för ett formulär.

Ingen standard för tangentkombination

I Internet Explorer aktiverar man en access key genom att hålla nere Alt (PC) eller Ctrl (Mac) följt av den angivna snabbtangenten. På Opera använder man Shift + Esc för att växla till läget för accesskeys och i Firefox 2.0 har kombinationen nu ändrats och blivit Alt + Shift + Snabbtangent. Redan den fingerfärdighet som krävs för att aktivera en accesskey talar ju emot att människor med motoriska handikapp skulle använda dem(!)

Att själva aktiveringen av en accesskey sedan fungerar olika hjälper förstås inte. Om en länk har tilldelats en accesskey så måste man i Internet Explorer först trycka in kombinationen för denna accesskey och sedan trycka Enter för att följa länken. I Firefox och Opera följer man länken direkt och behöver inte trycka Enter.

Tangentkombinationerna krockar

Det mest omnämnda argumentet mot att använda accesskeys är att dessa tangentkombinationer som anges redan har tilldelats andra funktioner i andra program som används för att läsa innehåll på internet: till exempel JAWS och IBMs Home Page Reader. Den kanadensiska byrån WATS gjorde en studie av accesskeys sommaren 2002 då de upptäckte att i princip alla kombinationer av ALT + snabbtangent är upptagna!

Det innebär till exempel att om du talar om för besökaren att ALT + I ska ta dig till innehållet så krockar det med funktionen i HomePageReader där ALT + I startar Read Items mode. Och ALT + D krockar med Internet Explorers kommando som tar dig till adressfältet. Som användare blir jag förstås irriterad när snabbkommandon inte funkar.

Detta innebar sedermera att Kanadas regering, som tidigare implementerat access keys på sin webbplats, valde att gå ut med rekommendationen att man inte ska använda accesskeys. Se deras text om Skip Navigation links.

Ingen standard för vilka accesskeys som gör vad

Trots att det har utkristallerat sig någon form av praxis när det gäller definitionen av accesskeys (man använder ofta siffertangenter för att minimera risk för krock med andra program) så finns det ingen officiell världsstandard som säger att Alt + 1 skall leda till hemsidan. Alt + 1 krockar dessutom med snabbkommandot hos HomePageReader som startar headings mode.

Det närmaste vi kommer är kanske den specifikation för accesskeys som Storbritanniens regering publicerat och som är snarlik specifikationen hos Vägledningen 24-timmarswebben. Eftersom de stora guidelines-producenterna (jag tänker W3C och WaSP) anat sig till att accesskeys kanske inte är någon bra idé, så ger de faktiskt ingen sådan rekommendation, och de följer själva inte heller den rekommendation som sprider sig...

Någon annan som har tänkt en vända till är sajten accessify.com som låter användarna definiera sina egna accesskeys. Det ger användaren frihet och minimerar risken för krock med andra program. Men ska verkligen användaren behöva ägna sig åt det? Snacka om att frångå standarder.

Samtidigt avråder som sagt Kanadas regering från användning av accesskeys, och har gjort så i många år.

Opera har den bästa implementationen

Om jag ska utnämna en banbrytare som har gjort det bäst möjliga av accesskeys så får det bli Opera. Webbläsaren Opera har en så kallad "toggle" för att aktivera accesskeys. Det innebär att man först trycker Shift + Esc. Då befinner man sig i läge för accesskeys och kan använda dem utan att de krockar med andra program. Vill man komma ur det läget så trycker man Shift + Esc igen.

Det funkar alltså som Caps Lock-tangenten: tryck en gång så får du stora bokstäver, tryck en gång till så får du små bokstäver. Opera lägger också mycket möda på att förklara hur man kan använda webben utan mus.

När är det ok att använda Access keys?

Jag har använt accesskeys vid utvecklingen av ett gränssnitt för kundtjänst hos SL. Tjänsten används av kundservicepersonal för att söka uppgifter i tidtabeller. För att kunna söka snabbt erbjöd vi snabbtangenter för de flesta aktiviteter som går att utföra; men kompletterade också med snabbkommandon som aktiverades av JavaScript. JavaScript ger en större frihet, funkar snabbare och är inte beroende av specifika tangentkombinationer.

I det aktuella fallet visste jag exakt vilka personer som skulle använda tjänsten; det var ett begränsat antal människor; vi kunde testa på deras datorer att det fungerade och alla hade tidigare jobbat med snabbkommandon. Om du har denna kontroll, kör hårt - annars inte!

Min övertygelse är att du genom att tidigt erbjuda de viktigaste länkarna underlättar för alla besökare, utan att behöva använda accesskeys. Se hur fint Roger Johansson gör det på 456bereastreet. Två diskreta länkar högst upp, men ack så viktiga.

Webbläsarna måste förbättras

Till syvende och sist handlar det om att webbproducenter inte ska bygga in för mycket egensinnig funktionalitet när det gäller att ta sig runt på en webbplats, som kräver åverkan på gränssnitt utanför webbplatsen (exempelvis tangentbordet). Ur mitt perspektiv så är det webbläsaren som ska ge användaren kontroll över webbplatsen. Först då blir det naturlig del av arbetsgången för en normalanvändare.

Slåss för bättre webbläsare och kräv att de ger bättre stöd för muslös navigering. Så kommer vi vidare.

Om du vill läsa fler synpunkter kring accesskeys kan du bland annat ta en titt på Dave Shea's inlägg: I Do Not Use Accesskeys. Dave fick en hel del kommentarer :)

RSS är ett standardiserat XML-format som gör att innehåll kan spridas på ett enkelt sätt och göras tillgänglig för många människor. Men det finns fler standardiserade XML-format och dataformat som underlättar spridning av information som till exempel kontaktuppgifter eller kalenderuppgifter. Microformats är ett samlingsnamn för några enkla format som är fantastiskt enkla att tillämpa.

Varför microformats?

Det gäller att komma ihåg att dessa enkla format skapas för människor i första hand. Genom att formattera innehåll på ett standardiserat sätt kan informationen användas i andra webbtjänster. Om jag lägger ut information om ett evenemang och formatterar den enligt hCalendar så kan informationen om evenemanget enkelt läsas och återanvändas av andra.

hCalendar som exempel

Låt säga att jag vill lägga ut information om konferensen From Business to Buttons. I koden skriver jag så här (koden kan givetvis genereras automatiskt av ett lämpligt verktyg):


<div class="vevent">Jag ska besöka <a class="url summary" href="http://www.businesstobuttons.com/">From Business to Buttons</a> den <abbr class="dtstart" title="2007-06-14">14 juni</abbr>-<abbr class="dtend\" title="2007-06-15">15 juni</abbr> på <span class="location\">Malmö högskola</span>.
</div>


Det ser då ut så här för en vanlig besökare:

Observera att detta är en giltig hCalendar microformat och om en robot/spindel som förstår microformats besöker min webbplats kommer de hitta och förstå evenemangets namn, tidpunkt och plats. Informationen kan till exempel användas för att automatiskt hålla en kalender uppdaterad på en annan webbplats. Vill jag sätta lite extra krydda på det hela kan jag ange evenemangets geografiska placering med latitud och longitud(!)

Fler microformats

Det finns även Microformats för kontakter (hCard) och man kan lära sig en hel del bara genom att börja använda rel-attributet enligt XFN, XHTML Friends Network. När du länkar till exempelvis en blogg kan du då ange om det är en person du har träffat, om det är en kompis, och så vidare. Förväxla inte det med rel-tag som i huvudsak används för kategorier - ett fenomen som säkerligen skickar meta keywords rakt in i historieböckerna.

Läs mer:

• About Microformats - projektets webbplats
• Tails Firefox Extension låter dig läsa microformats på en sida. Kan vara bra för att verifiera att det blev rätt.

Igår kväll byggde jag en webb i ett publiceringsverktyg på två timmar. Wiki-webbar är nog svaret på alla enklare sajter som behöver ett enkelt webbaserat publiceringsverktyg för att underhålla innehållet.

Under mina två timmar lyckades jag:

• installera ett wiki-verktyg på min server
• migrera innehåll och bilder från en annan webbplats till verktyget
• skapa en helt ny mall i CSS och XHTML som stämde överens med utseendet på den ursprungliga webbplatsen; den nya mallen följer givetvis webbstandarder och får inga anmärkningar i W3C:s valideringsverktyg

Tyvärr kan du inte beskåda skönheten eftersom det är en privat webbplats, såvida inte du också är bjuden till bröllopet ;)

Nu kan den blivande bruden och brudgummen via webben själva enkelt redigera sidorna, lägga in bilder och innehåll - samt även skapa nya sidor!

Dölja sidor för sökmotorer

För att säkerställa att inga sökmotorer ska plocka upp webbplatsen la jag även in koden:

<meta name="robots" content="noindex,nofollow" />

Den koden talar om för sökmotorerna att de inte ska indexera innehållet på webbplatsen och inte heller följa länkarna på webbplatsen. Det är bra kod att känna till om du skapar webbsidor som du endast vill att en begränsad publik ska ha tillgång till.

Go wiki!

Verktyget jag använde för det här turbo-projektet heter TigerWiki och är en minimalistisk wiki på några få kodrader som inte använder en databas; Minst sagt en snabb och effektiv lösning.

Om du vill titta på en wiki som klarar allt och lite till så rekommenderar jag PmWiki som har mängder med smarta verktyg kopplat till sig.

Om du letar efter ett verktyg för att dokumentera och samverka kring ett projekt rekommenderar jag MediaWiki som uppslagsverket Wikipedia bygger på. Hos Wikipedia kan du också läsa en hel del om vad en Wiki är.

Ordet "wiki" kommer förresten från Hawaii och betyder, ja just det: "snabb".

Jag använder dem inte och min webbplats syns bra i sökmotorerna. Många av mina kunder vill använda dem men vet inte om de funkar. Flertalet webbredaktörer har varken tid, ork eller kompetens för att skriva in dem på ett strukturerat sätt. Och sökmotorerna själv verkar inte bry sig om Meta Keywords.

Jag själv har oerhört låg tilltro till fenomenet Meta Keywords, en möjlighet att lägga in nyckelord, sökord och begrepp, som är synliga för sökmotorer men inte för vanliga besökare på en webbsida. På grund av missbruk, och låg tillämpningsgrad, övergav de flesta sökmotorer Meta Keywords som sökunderlag redan i slutet av 90-talet. Nyare sökmotorer som Google och FAST har aldrig ens haft stöd för Meta Keywords.

Missbruket dödade keywords-elementet

Tanken är god: tillåt webbägaren att delge vilka nyckelord som är relevanta för just den här webbsidan och på så sätt skapa ämnen och strukturer och stöd för att bedöma innehållets relevans. Men vad händer om Meta Keywords missbrukas och man skriver in nyckelord som inte alls har med sammanhanget att göra - då lurar vi användaren; eller om webbutvecklaren har för låg kompetens för att ange relevanta nyckelord på rätt ställen: ska då webbplatsen uteslutas även om innehållet är intressant?

Innehåll är kungligt

Nej, sökmotorerna insåg att det bästa sättet att avgöra vad sidan handlar om är att faktiskt analysera innehållet på sidan. Det är också där du som webbansvarig bör lägga ditt största fokus: innehållet. Titlar, rubriker, länktexter och upprepningar av förutbestämda fraser är nyckeln till en lyckad träffbild i dagens sökmotorer. Att många länkar till din webbplats, och på så sätt rekommenderar den, är det som kommer trycka upp dig mot toppen av sökresultaten och förbi konkurrenterna. Bästa sättet att få folk att länka till dig är förstås att erbjuda bra innehåll.

Farligt att använda Meta Keywords

Richard Ball från Apogee Web Consulting varnar faktiskt för att det kan vara ofördelaktigt att använda Meta Keywords eftersom du underlättar för konkurrenterna att helt enkelt "stjäla" och ta fram listor över de nyckelord och fraser som du värderar högt. På så sätt kan de lättare justera sina sidor så att de inbegriper även "dina" nyckelord.

Flytta fokus från Meta Keywords

Min slutsats när det gäller Meta Keywords är att det tar för lång tid att skriva in nyckelord för varje webbsida och det kostar långt mer än det smakar. Samtidigt lägger de flesta alltför lite tid på att kontinuerligt gå igenom och förbättra innehållet på sidorna så att de på ett icke konstlat sätt ger utrymme för strategiskt viktiga ord och uttryck. Genom att lägga tiden från arbetet med Meta Keywords på att i stället optimera innehållet på sidorna så kommer nyckelorden, ironiskt nog, ge betydligt mer verkan.

Läs mer:

• Meta Keywords Advice, Richard Ball
• Death of a Meta Tag, Danny Sullivan
• Wikipedia: Meta tag

Många webbformgivare uttrycker ett missnöje med att vi på webben måste hålla oss till vissa givna typsnitt för att vara säkra på att sidorna ser ut som vi tänkt. Friheten är begränsad.

men sIFR ställer allt på ända

sIFR är en teknik som låter dig ersätta textelement på skärmen med texter i Flash.

Helt enkelt betyder det att dina rubriker (och citat och så vidare) kan skrivas i valfritt typsnitt, vare sig det är Bodoni, Garamond, Jokerman, Papyrus eller vilken annan font som helst, utan att användaren behöver ha typsnittet installerat på sin dator!

Tekniken fungerar så länge användaren har JavaScript aktiverat och en Flash-spelare installerad, annars skrivs rubrikerna ut som vanligt i HTML.

Och du, behöver jag nämna att det lever upp till gällande krav på tillgänglighet!

Läs mer om tekniken: Introducing sIFR: The Healthy Alternative to Browser Text

Till min stora glädje ser jag att tabeller på webben allt oftare används, som de ska, för att presentera data snarare än för design.

En nackdel med presentation av data i tabeller på webben är dock generellt att det inte går att sortera tabellen enligt valfri kolumn. I andra applikationer är det mer regel än undantag att det just går att sortera.

Många utvecklare löser detta genom att låta användarens klick på en rubrik leda till en ny fråga till databasen, sidan laddas om och voilá! så presenteras tabellen med en ny sortering. Dilemmat är dock att detta är resurskrävande och en ny databasfråga tar tid att ställa.

Måste vi verkligen hämta all data igen från databasen, bara för att sortera om den? Givetvis inte. Ta en titt på sammanställningen nedan över några av mina drömmotorcyklar.

Sortera kolumner utan att ladda om sidan

Klicka på en rubrik och datat sorteras om i stigande eller fallande ordning, om du har JavaScript.

Och eftersom du undrar, visst är detta en lösning som inte ställer till bekymmer avseende tabellens tillgänglighet. Koden för tabellen följer standarder och W3Cs rekommendationer.

Om du vill erbjuda JavaScript-fattiga användare en alternativ lösning för sotering går det fortfarande att komplettera med en lösning som hämtar ny data och laddar om sidan. Huruvida det behovet finns måste du själv ta ställning till. Lösningen som presenteras här ger dig dock ett snabbt och smidigt sätt att göra tabellerna dynamiska för merparten av dina besökare.

Så här gör du för att möjliggöra sortering av dina kolumner

1. Inkludera skriptet, så här:

<script src="sorttable.js">></script>

2. Markera tabellen som sorteringsbar genom att ange klassen "sortable":

<table class="sortable">

3. Säkerställ att tabellen har ett id-nummer:

<table class="sortable" id="unikt_id">

Skriptet bifogas. Glöm inte att snygga till tabellen med CSS.

(Källa: The Daily Kryogenix: sorttable)