Igår meddelade Apple att de hade jobbat på en ny Mac Pro, som ska släppas under hösten. Arbetshästen, som används vid video- och ljudproduktioner har inte uppdaterats på länge, så meddelandet var nog välkommet hos många. Förutom nyheten släppte Apple även en presentationssida av den nya datorn. Jag har studerat den närmare och tänkte berätta några highlights.
Kombinerar CSS3 och film för att visa animationer
Hela sajten är en så kallad ”one page website”. Besökaren kan navigera mellan olika sektioner, steg för steg. Vanligast på sådana sajter är att man får scrolla mellan sektionerna. Här har Apple valt att animera övergångarna med en kombination av CSS3 och film. När besökarne inleder en scroll transformeras bildobjekten. Du kan själv testa genom att dra upp och ned några pixlar. När användaren har scrollat tillräckligt långt, tar ett filmklipp över. Detta klipp är övergången till nästa sektion.
Det är en snygg lösning. Problemet är dock att du måste vänta på att filmen har spelats färdigt till du kan navigera tillbaka. Tröskelvärdet för när animationen ska sätta igång är något lågt.
Ingen vanlig scroll
När klippet är slut visas en vanlig container med nästa sektions innehåll. Dock har den sektionen aldrig, i layouten, legat under den föregående. Istället har den varit osynlig och visas nu i fullskärmsläge. Det innebär att någon scrollbar aldrig uppträder. Denna scrollbar hade varit ett hinder i att göra de snygga övergångarna. Den hade ju flyttat sektionen i höjdled vid scroll, vilket hade inneburit konstiga hopp i animationen. Istället detekteras scroll med logik i ett JavaScript, som agerar motor för övergångarna.
Anpassning av datamängd
Apple verkar onekligen ha tänkt på datamängden. Filmklippen levereras sammanfogade i ett klipp, som i sin tur finns i olika storlekar beroende på besökarens plattform. Klippet verkar väga 18.6MB för vanliga desktop-användare.
Vad de väger på min iPhone har jag inte tagit reda på. Även om klippet är ganska stort påverkar det inte sidladdningen nämnvärt. Det behöver nämligen inte laddas klart innan sajten kan visas, eftersom man kan räkna med att besökaren inte navigerar fortare mellan sektionerna än vad som behövs.
Som vanligt lyckas Apple inte bara imponera på sina fanboys, utan även mig som frontend-utvecklare med sina sajter. Den här är inget undantag. Jag har inte sett den här typen av one page-design tidigare och hoppas fler anammar den. Förhoppningsvis ser någon till att göra den fullt fungerbar även för användare utan JS med. I Apples fall är sajten bara en tom, svart ruta…
Istället för att guida dig med text till vårt bibliotek för metafält bjuder vi på en screencast. Det är en kort genomgång av hur du skapar metaboxar med textfält.
Planen var att på tio timmar sätta ihop ett API med all data ur Livsmedelsverkets databas. På tio timmar skulle det finnas ett API, en läsbar dokumentation och även en demoapplikation. På tio timmar skulle allt fungera och faktiskt vara så klart att utvecklare kunde använda det. Det lyckades vi med.
Målen för hackathons är inte alltid ett körbart resultat. Ibland passar många team på att lära sig nya tekniker, utveckla sina kunskaper eller bara lattja med koden. Vi ville dock nå fram till en färdig produkt. För att lyckas med det behövde vi identifiera de största hindren och ta oss förbi dem. I det här inlägget tänkte jag berätta om några delar av vår strategi.
Upprätta en backlog med tydliga och korta aktiviteter
Planeringen av projektet inleddes med ett möte där vi upprättade en backlog. Vi visste att hela scopet inte skulle kunna täckas, utan såg till att endast ta med de fundamentala funktionerna i v1.0. Andreas utsågs till projektledare. Han förde in alla aktiviteter i loggen. Därefter bestämde vi vilka aktiviteter som skulle ingå. Genom att hålla scopet smalt så att vi kunde ha en releasbar version med några timmars marginal innan deadline. Denna backlog skulle vi även komma att jobba utifrån vid eventuell tid till vidareutveckling.
Ha en färdig infrastruktur
Ett sånt här projekt är beroende av en tydlig infrastruktur. I vårt fall är den ganska rudimentär. Vi kör en VPS med webbserver och databas. I vilket fall som helst ville vi ha den på plats innan hackets start. Dessutom behövde vi ha utvecklingsmiljöer på samtliga team-medlemmars datorer. Att sätta upp dem under hacket skulle bara ta onödig tid och leda till frustration om (oftare ”när”) något krånglade. Fokuset kunde nu istället ligga på aktiviteterna i backloggen.
Korta och många sprintar för att kunna anpassa planen efter behov
En planering brukar oftast inte kunna följas slaviskt. Det händer att man behöver prioritera om och eventuellt göra avkall på viss funktionalitet till fördel för annan. Dessutom ville vi hela tiden kunna ha en uppdaterad status av hur nära release vi var. Därför bestämde vi att ha många sprintar som avslutades med gemensam genomgång. Vid avslutet planerade vi även nästkommande sprint.
De tio timmarna delades in i fem sprintar á två timmar. Vår backlog innehöll inga aktiviteter som behövde ta längre tid än så. Ofta är en aktivitets scope subjektivt. Här krävdes den minsta insatsen för att nå målet men samtidigt vara hållbar. Varje sprint avslutades med en genomgång om 15 minuter. Vi presenterade vad varje person hade gjort. Som produktägare kunde Anders prioritera aktiviteterna och välja vilka som skulle göras under nästa sprint. Högst prio hade dock alltid aktiviteterna för v1.0.
Skulle en aktivitet vara för kort för en hel sprint var det bara att vända sig till backloggen för att hitta en ny.
Internetuppkopplingen gör att man inte kan dela för stor data
På ett hackathon brukar Internetuppkopplingen inte vara alltför tillförlitlig. Med lokala utvecklingsmiljöer och versionshantering i git behövde vi inte dela stora datamängder med varandra. Det enda som krävde extra mycket bandbredd var databasen med alla näringsvärden. Vi valde att distribuera den via ett USB-minne. När vi skulle deploya till produktionservern fick vi passa på att ta en kopp kaffe när den laddades upp.
Det finns ingen tid för testning – låt andra göra det
Under ett hackathon är man väldigt ivrig att beta av aktivitet för aktivitet och hinner inte testa koden så noga som man skulle önska. Det behöver dock inte vara något problem. Är målsättningen att nå en prototyp gör det inget. I ärlighetens namn var vi också ganska slarviga med testningen. Ingen code review eller unit testing fanns med i planen. Däremot hade vi nytta av att göra en tidig release. Det fanns flera personer ute i cyberrymden som läste vår dokumentation och testade API:t. Redan under minglet hann vi med att träffa Peter Hellberg som hade skrivit ett Ruby-gem för API:t. Han hade mycket konstruktiv feedback om både dokumentationen och funktionerna. Vårt tips är alltså att förbereda vänner och bekanta på att vara standby under dagen och beredda att testa.
Nu har nästa version av WordPress gått in i beta-stadiet. Häromdagen släpptes beta 2 och enligt planeringen ska det finnas en färdig version av WordPress 3.6 den 20:e maj.
Mycket av nyheterna i version 3.6 är relaterade till en bättre användarvänlighet. Bland annat kan du nu lägga till ljud och film utan att behöva gå via tredjeparts-tillägg, låsa upp inlägg som någon annan håller på att skriva och lättare använda Post Formats.
Jag tänkte dock ta upp två andra nyheter i det här inlägget. Dessa nyheter är mer relaterade till de typer av sajter som vi skapar. Våra sajter utnyttjar nämligen WordPress som ett CMS mer än ett bloggverktyg.
Ny hantering av menyer
Nu har det blivit lättare att hantera menyerna. I nuvarande versionen (v3.5) skapar man menyerna och anger deras placering i temat i samma vy. Det här har vi märkt varit ganska förvirrande för en ny användare. När inställningen för placeringen dessutom ligger till vänster om själva meny-redigeraren, är ordningsföljden inte helt logisk – ”Ska man välja var menyn ska finnas innan den skapas?”.
Hädanefter kommer istället varje individuell menys struktur hanteras via fliken ”Edit menu”. Utseendet är nästan identiskt med tidigare versionen. Det nya är att du inte kan ange placeringen. Du kan endast skapa menyn, välja vilka föremål som ska finnas i den och ange strukturen.
För att bestämma var på sajten den ska finnas hänvisas du till fliken ”Manage Locations”. Den här vyn har en enkel tabell där du kan koppla alla registrerade ”Theme locations” med respektive skapad meny (för du registrerar väl menyerna i ditt tema?).
Ordningsföljden blir mer logisk – skapa meny och sen bestämma var den ska finnas. Jag räknar med att nya användare tycker det här är en lättare procedur.
Revisioner
Något annat nytt är hur du hämtar tillbaka gamla versioner av ett inlägg. Jag vet inte i vilken version av WordPress som versioner introducerades, men det har hängt med ett bra tag nu hursom. Det fina är att varje gång ett inlägg uppdateras sparas det som en ny version. Det gör det lättare att hämta tillbaka gamla versioner av texter och eventuellt återskapa dem ifall något skulle gå snett.
Nu har gränssnittet för hur du hanterar versionerna uppdaterats. Nu går det att stega mellan versionerna. Varje version du granskar visar information om vad det är som har ändrats sedan förra versionen. Jag tycker det är ett betydligt lättare sätt att följa utvecklingen av ett inlägg. Tidigare har du behövt välja vilka två versioner som ska jämföras, annars har bara den aktuella visats.
Dessutom har det införts en slider med två handtag. Dessa handtag har representerat en varsin version. Det är bara att placera handtagen vid versionerna som du vill jämföra och vips – så har du ändringarna framför dig. Inget mer behov att kryssa för och skicka en begäran med sidomladdning för att se ändringarna. Snabbare och mer intuitiv interaktion i mitt tycke.
Slutord
Det här är endast två av alla uppdateringar som kommer i WordPress 3.6. Är du nyfiken på alla ändringar som görs, stora som små, kan du se alla tickets i WordPress Trac.
På Webbgaraget ser vi fram emot den här uppdateringen och räknar med att våra kunder kommer vara nöjda med den nya användarvänligheten. Behöver du hjälp att uppgradera? Hör av dig så ser vi hur vi kan hjälpa dig.
Nu i dagarna har det uppdagats att hackare försöker bygga ett, så kallat, botnät som ska ta sig in i WordPress-sajter. Deras princip är enkel: försök hitta lösenordet hos de WordPress-sajter som har en användare med namnet ”admin”. Anledningen till att de valt det användarnamnet beror helt enkelt på att det är standard i WordPress.
Det har inte kommit rapporter på hur många sajter det är som har blivit hackade. Jag tänkte ge dig några tips på hur din sajt inte kommer med på den listan. Tipsen är riktade till dig som inte är programmerare, utan vanlig användare. Därför är det väldigt lite kod inblandad.
Gå runt botnätets principer
Eftersom den här attacken har en enkel princip tycker jag att vi kan gå runt den. Om du ska installera en WordPress-sajt ska du välja ett annat användarnamn än ”admin” för administratörs-kontot. Det här kontot bör du, av andra anledningar, inte använda i ditt redaktionella arbete. Därför bör det vara något i stil med ”webbadmin”, ”admin-user”, eller liknande. Det viktiga är att det skiljer sig något från frasen ”admin”.
Dessutom måste botnätet testa alla typer av lösenord det kan komma på. Jag skulle anta att det antingen gör en dictionary attack eller testar alla tänkbara kombinationer av tecken. Därför föreslår jag att du väljer ett lösenord som är ovanligt och långt. Det avgörande är snarare längden på texten och inte att det finns många konstiga tecken. En mening på fyra ord, som innehåller ”å”, ”ä” eller ”ö” anser jag räcka långt.
Lås administrationspanelen
Det tar ett tag att komma på vad som är rätt lösenord. Därför skulle jag rekommendera att du installerar ett tillägg som gör att besökaren låses ute efter ett visst antal försök. Tillägget Limit Login Attempts gör precis detta. Det erbjuder dig att ange hur många försök som får göras, om du ska få ett mail när någon har blivit utelåst och har en massa fler funktioner. Det är inte uppdaterat på ett tag, men verkar enligt forumet fungera för den senaste versionen av WordPress.
Håll WordPress uppdaterat
En del attacker kan bero på att man har hittat säkerhetshål i WordPress. Nu var det ett tag sedan WordPress senast råkade ut för en sådan attack, men man ska alltid vara på tårna. Därför är det viktigt att du håller WordPress och alla tillägg uppdaterade till de senaste versionerna.
Berätta inte att du använder WordPress
WordPress kan vara ganska skvallrigt om sitt versionsnummer. Vi vill undvika att meddela detta till illasinnade besökare. Dels finns filerna readme.html och license.txt och dels skrivs versionsnumret ut i källkoden.
Om du har tillgång till att redigera din .htaccess-fil på webbhotellet, föreslår jag att du lägger in nedanstående kodsnutt. Den förbjuder dina besökare att läsa ovanstående filer. Man kan tycka att det vore lämpligare att ta bort dem, men WordPress lägger till dem vid varje uppgradering. Det här är en permanentare lösning.
Versionsnumret skrivs ut i en meta-tagg. Vi kan faktiskt ta bort den väldigt enkelt. Installera tillägget Hide Generator Meta Tag och aktivera det.
Det var några tips på hur du säkrar i WordPress och sover bättre om nätterna. Vi har själva inte varit med om några attacker på våra sajter, men man kan aldrig vara nog så säker.
Websockets i all ära, men var är implementationer av realtidsapplikationer i WebRTC? Jag tror att vi inom en snar framtid kommer se fler och fler spel i webbläsaren, som styrs med din smartphone.
WebRTC ger möjligheter till realtidskommunikation
Som vanligt har Google varit aktiva i utvecklingen av webben. Under 2011 släppte de en draft av en specifikation av WebRTC. Denna draft specade ett API för realtidsöverföring av video och ljud mellan webbläsare. Nu är API:t hos W3C, som håller på att ta fram en fullständig specifikation. Det intressanta med detta API är att data förs över direkt mellan klienterna, via så kallad peer-to-peer-anslutning. Därmed behöver man ingen server som datan sänds via. Tiden minskar eftersom datan förs över direkt till mottagaren. Bandbredden påverkas också positivt, eftersom den enda som krävs är den mellan klienterna.
Det är inte bara ljud och bild som kan föras över, utan även godtycklig data. Vi kan upprätta ett kommunikationsprotokoll mellan klienterna för att skicka vilken information som helst.
Interaktion mellan mobiltelefon och dator finns
Idag kommer det exempel på tjänster som skapar en interaktion mellan dator och smartphones. Mer specifikt handlar det om möjligheten att i realtid med sin smartphone skicka instruktioner till datorn. Jag har tidigare varit hos Accedo Broadband och utrett hur man kan möjliggöra interaktionen mellan smartphones och IPTV-applikationer. Tekniken har varit mogen länge, men det verkar inte som att man inte har kommit på några specifika implementeringar.
SVTPlays Kontroller låter dig styra din SVTPlay-session
Ett Svenskt exempel på hur man kan kontrollera datorn med sin TV är SVTPlays webbtjänst Kontroll. Genom att scanna en QR-kod på SVTPlays webbplats med din smartphone, får du upp en webbvy med en fjärrkontroll. Denna kan du använda för att styra uppspelningen på datorn. Här skickas datan via WebSockets och använder tjänsten PubNub. Instruktionerna går från din smartphone, via en server, till din dator.
Tävla i friidrott mot vännerna med Google Supersync
I slutet av februari berättade Google att de hade byggt ett multiplayerspel med enbart HTML5-teknik. Tillsammans kan upp till fyra personer tävla i tre olika friidrottsgrenar. Spelet är väldigt snyggt och med något simpla grenar. Det intressanta dock är att varje spelare ansluter till spelsessionen via sin smartphones webbläsare. Spelandet går till på samma skärm, som ett traditionellt TV-spel med andra ord. Även här sker kommunikationen via WebSockets.
Nya tillämpningar för WebRTC
Nästa steg i utvecklingen som jag vill se är spel som utnyttjar WebRTCs PeerConnection. Varför skapar vi inte ett multiplayerspel där datorn är värd och våra smartphone skickar instruktioner direkt till datorn för dataöverföringen? Tekniken finns där i form av HTML5. Vi kan rendera 3D-shooters med WebGL. Våra smartphones är kanske inte de mest ergonomiska som spelkontroller, men fungerar tillräckligt bra.
Meddelanden behöver inte skickas via någon mellanhand, som för WebSockets, utan kan skickas direkt till datorn. Det enda som krävs är en extern tjänst för att upprätta anslutningen. Här sparar vi bandbredd och även latency. Det gör inget att platsen som spelet sker på har dålig mottagning i mobildatanätet. Så länge en WiFi-anslutning mot servern är tillgänglig är det möjligt.
En smartphone har samtliga typer av inmatningar som en spelkontroll. Vi kan simulera styrkors, joystick och knappar. Feedback kan ges i form av ljud och vibrationer.
När du som spelare går runt med spelkontrollen i fickan kan du gå med i vilket tillgängligt spel som helst. Tänk dig att du är på en offentlig plats, som flygplats eller kön på ICA. Här finns det en skärm med ett spel i flerspelarläge. Ta fram telefonen, surfa in till spelets specifika URL (eller scanna en QR-kod) och ge dig in i matchen.
Jag tror inte TV-spelen är uträknade, men en dator utrustad med en webbläsare kan vara ett bra komplement och öppna möjligheten för fler utvecklare att sprida sina kreationer. Eller vad säger du?
Det fina med WordPress är att det mesta som du kan skapa via administrationspanelen, även kan skapas via kod. Det här är bra för import-script som automatiskt ska skriva information till ett inlägg. Ibland är det inte bara text och metadata som ska skrivas till inlägget, utan även bilder. Därför tänkte jag här gå igenom två funktioner i WordPress som inbjuder till enkel uppladdning.
Hämta bild via URL
Finns bilden att hämta via en URL? Isåfall är metoden vi ska använda given. Sedan WP v2.6.0 finns metoden media_sideload_image($file, $post_id, $desc = null). Den tar emot adressen till bilden som första parameter. Den andra parametern är ID för inlägget bilden ska höra till. Bilden kommer sparas till mediabiblioteket och får samma status som bilder uppladdade via det grafiska gränssnittet. Returvärdet, om allt går bra, är en HTML-sträng med en IMG-tagg. Skulle något gå fel kastas en exception eller returvärdet är void.
Vill du ange en beskrivning till bilden är detta den tredje parametern. Notera att den inte är obligatorisk.
Ladda upp bild som binär
Skulle du istället ha tillgång till filens binära data och inte en URL, blir det lite knivigare. Då måste vi skriva filen till en tillfällig sökväg och spara den därigenom. Som tur är kom det även en funktion för att hantera detta i WP v2.6.0, nämligen media_handle_sideload($file_array, $post_id, $desc = null, $post_data = array()). Den används faktiskt av tidigare nämnd funktion, media_sideload_image(). Två parametrar är nödvändiga – en array som påminner om PHPs $_FILE-array samt föräldrainläggets ID. Nästan samma som tidigare alltså.
Funktionens returvärde är bildens ID i WordPress. Skulle något gå fel kommer en exception kastas.
Så enkelt är det alltså att ladda upp filer och koppla dem till ett inlägg. Det du måste hålla reda på är vilken mime-typ som filen har. Dessutom kan det vara bra att normalisera filnamnet, det vill säga ta bort specialtecken och mellanslag. Då reducerar du antalet problem som kan uppstå med teckenkodning och vid eventuell serverflytt.
En begränsning i WordPress är att det kan vara svårt att skapa undersidor till Custom Post Types (CPT). Här tänkte jag gå igenom ett alternativ, som automatiskt renderar undersidor baserade på CPTs metadata.
I det här exemplet har vi en CPT som representerar en bil. Bilen har metadata för specifikationer och tillhörande bilder. På sidan single-bil.php ska bara specifikationerna och en utvald bild visas. Vi vill ha en undersida som renderar galleriet (single-bil-galleri.php). Denna sida kommer automatiskt skapas.
Teorin
Vi använder WordPress custom endpoints. De används för att skapa nya ändelser till URLer och fånga dem när template ska renderas. Ett exempel är att skriva ut en CPTs information i JSON-format genom att lägga till enpoint ”json”. I det här fallet vill vi lägga till en endpoint som heter ”galleri”. Skulle vi nu besöka sidan http://xxx.zzz/bil/aston-martin/galleri/ kommer denna endpoint finnas i vår globala query.
Sedan registrerar vi en funktion hos den hook som kallas när templates ska renderas. Där avgör vi om vår endpoint är kallad på och att rätt post type ska renderas (i det här fallet ”bil”).
Registrera endpoints
Vi börjar med att registrera vår endpoint. Notera att vi inte behöver registrera någon query var, utan det räcker med en endpoint.
Rendera template
Sedan går vi vidare till att rendera det template som behövs. Vi registerar en metod hos hooken för att rendera templates och avgör om det är rätt post type som ska renderas, samt att vår endpoint används. Isåfall tilldelar vi variabeln $templates sökvägen till det template som vi vill rendera. Det fina med att göra på det här viset är att vi har tillgång till det globala $post-objektet och kan rendera sidan som vilket CPT-template som helst.
Rendera galleriet
Vår template single-bil-galleri.php kan till exempel se ut på följande vis. Det är ett väldigt exempel och syftet är att illustrera att vi inte behöver hämta vårt inlägg med någon speciell query, utan har tillgång till det globala $post-objektet.
Fullständig kodIstället för att behöva lägg in koden i din functions.php-fil rekommenderar jag dig att göra en klass, som hanterar alla actions och filter, och inkluderar den via functions.php.
Alternativ lösning
Ett annat tillvägagångsätt kan vara att registera en separat CPT för bilars galleri. Sedan använder vi en metabox där vi anger vilken bil respektive galleri hör till. Som användare måste man i det fallet komma ihåg att se till att galleriet är kopplat till rätt bil. I mitt exempel är vi garanterade att varje bil har rätt bilder i sitt galleri (så länge användaren laddar upp rätt bilder).
Det som gör WordPress så bra är dess stora användarbas som tillåts bidra med sitt strå till stacken. Många användare är måna om att ha en bra plattform för sina sajter och utvecklar därför egna plugins eller tillverkar publika teman. Men du behöver inte ens vara en programmerare för att kunna göra världens bästa CMS ännu bättre.
Upptäck och rapportera buggar
Ibland finns det inget roligare än att testa ett system och försöka förstöra det. Därför brukar jag roa mig med att försöka framkalla fel i WordPress. Det kan vara något så enkelt som knappars tillgänglighet i admin-panelen med tabbar. Därför föreslår jag att du, när du känner dig mest skadeglad, försöker göra allt som går emot principerna för ett normalt användarbeteende och upptäcker när WordPress inte beter sig som det ska. Sen rapporterar du felet till WordPress Trac med en rapport. Vägledning till hur du rapporterar buggar hittar du här: http://codex.wordpress.org/Reporting_Bugs.
Skriv plugins för dina favoritfunktioner
Vi hade ett behov av att generera kort-länkar via bitly för våra inlägg. Sagt och gjort skrev vi en lösning (innan vi hittade färdiga tillägg) för det. Eftersom det här inte var någon lösning specifik för vårt tema, utan kunde användas av alla WordPress-sajter, gjorde vi om implementeringen till ett plugin. Vi publicerade tillägget i WordPress publika plugin-databas och nu har det närmare 1000 nedladdningar. Vår egna lösning blev något som andra också hade nytta av. Kika gärna på WG bit.ly shortener här: http://wordpress.org/extend/plugins/wg-bitly-shortener/
Alltså, när du är i farten med att skriva en generell lösning för ett problem i WordPress, identifiera om du kan göra det som ett tillägg och låta andra ta del av din kunskap. Dessutom blir användarna bra bollplank för framtida vidareutveckling. Det finns en del direktiv från WordPress som du kan läsa om här: https://codex.wordpress.org/Writing_a_Plugin.
Fler sätt att hjälpa
WordPress har skrivit en guide för hur du kan hjälpa till. Det behövs alltid hjälp med att testa nya betor inför release, redigera och granska dokumentationen och eventuellt fixa buggar. Du hittar guiden här: http://codex.wordpress.org/Contributing_to_WordPress.
I ett uppdrag åt APW gjorde vi frontend-utvecklingen av Merchiis nya webbsajt. Ett önskemål var att ge lightboxarna nya effekter. I vanliga fall släcks sajten ner med en tonad ruta när lightboxen öppnas. I det är fallet ville de istället att alla element skulle bli suddiga, utan någon nedsläckning. Vårt resultat blev ett script som skötte både bilder och text. Scriptet finns som en gist (https://gist.github.com/4525009) och i följande text går vi igenom teorin för våra lösningar.
Använd två typer av bilder
Vi såg att det finns bildbehandlings-bibliotek i JavaScript för att göra bilder suddiga. Dock upptäckte vi att de kom till korta för bilder som var ikoner, där den suddiga versionen behövde en yta som var större än ursprungsbilden.
Därför bestämde vi att använda två versioner av varje bild – en skarp och en suddig. Varje bild hade sin suddiga version placerad på samma position, men med en opacitet om 0%, vilket gjorde den osynlig. När besökaren sedan öppnade lightboxen aktiverades en animering av bilderna. De skarpa versionerna minskade i opacitet, från ett till noll, och den suddiga ökade i opacitet, från noll till ett. När lightboxen sedan stängdes gick animationen åt det andra hållet.
Det kluriga var positioneringen av bilderna. Eftersom många av bilderna var ikoner och annat än kvadratiska, hade de suddiga versionerna större yta än de skarpa. Därmed behövde versionerna vara något förskjutna i förhållande till varandra. Om de hade samma position för sina högra övre hörn skulle bilden hoppa när den bytte mellan skarpt och suddigt utseende. Vi löste det genom att placera dem manuellt med CSS. Det hade nog gått att lösa med JavaScript också.
Sudda texten med ett jQuery-tillägg
Att göra texten suddig hade kunnat lösas med en skugga som inte hade någon riktning. Dock behövde vi även här göra en mjuk övergång och därmed animera det med JavaScript. Vi hittade jQuery-tillägget JQuery TextBlur Filter som verkade passa. Det erbjöd ett nytt CSS-attribut till jQuery för textskugga. Fördelen med det här var anpassningen till olika webbläsare.
Vid öppning av lightboxen såg vi till att ange en callback-funktion för varje steg i animationen. Funktionen ökade textskuggan procentuellt mellan noll och ett fördefinierat värde. Vid stängning gick det från det fördefinierade värdet till noll.
Demo
Jag har satt ihop ett demo som du kan kika på här. Det kräver att du har JavaScript aktiverat och är endast testat i WebKit-browsers.
