Vi är noggranna när vi arbetar. Det krävs för att det ska bli bra. Vi använder inte paketlösningar eller färdiga mallar. Istället bygger vi webbplatser som från grunden är anpassade för besökarens behov. För oss är det viktigt, och det är därför våra kunder anlitar oss.
Vi är Obviuse. En del uppenbart och en del användbart. Tillsammans något riktigt bra.
Tillsammans med Mindset och Hansson Larsson på teknik har vi jobbat vidare med deras webbsida för sina öppna utbildningar. Bättre, snyggare, lekfullare sammanfattar förändringen. En naturlig fortsättning på ett bra samarbete helt enkelt!
Det vanliga sättet att jobba med responsive design är att kolla skärmen eller webbläsarfönstrets bredd och anpassa innehållet därefter. Vad som är lätt att förbise är att även skärmens höjd spelar en stor roll för upplevelsen.
@media only screen and (min-width:1280px)
{
html { font-size:14px; }
}
Här har vi satt en media query som skalar upp innehållet när skärmens/webbläsarfönstrets bredd överstiger 1280 pixlar. Har besökaren en bredare skärm får den en större upplevelse. Detta tack vare att vi byggt sidan baserat på REM som gör att vi bara behöver ändra ett mått på ett ställe för att skala hela sidan. Läs mer om REM här.
Det är lätt att förbise är att skärmars aspect ratio skiljer sig rätt så mycket. Om besökaren sitter på en låg skärm, exempelvis en Microsoft Surface (i liggande läge) kommer skärmen förvisso vara över 1280 pixlar bred; den är hela 1366 pixlar bred. Men dess låga höjd kommer göra det svårt att få en överblick av sidan:
Lösningen på problemet är en vertikal media query:
@media only screen and (min-width:1280px) and (min-height:800px)
{
html { font-size:14px; }
}
... som gör att vår förändring inte slår in förrän besökaren sitter på en högre skärm än 800 pixlar.
I det här fallet gör vi en enkel förändring på storleken på allt innehåll. Andra mer direkta användningsområden skulle kunna vara att anpassa höjden på listningsidor efter skärmens höjd. Eller göra en huvudmeny mindre eller större. Handlar det om en sida där det är viktigt med att visst innehåll hamnar ovanför The Fold™ går det att anpassa höjden.
Ett exempel är Apples Iphone-sida. Baserat på skärm/webbläsarhöjd ändras höjden på huvudbilden.
Om du sitter på en dator med hög upplösning (och en hyggligt modern webbläsare), testa att ändra webbläsarfönstrets höjd inne på den här sidan så ser du vad vi är ute efter!
Tankesättet har vi fått från den eminenta Trent Walton. Andra bra artiklar är Gognitions Go Vertical och Boagworlds Vertical Media Queries.
Bra innehåll förtjänas att spridas. Facebooks Like-knapp fungerar för ändamålet, men ännu bättre är det om man kan få besökaren att dela sidan på Facebook själv. Då har länken större chans att överleva inläggsbombardemanget på folks flöden. Dela-knappar känns dock lite döda då de saknar räknaren som Like-knappen erbjuder.
Med ett litet anrop till OpenGraph kan man väcka delaknapparna till liv. Genom att ange hur många interaktioner en viss sida har på Facebook (likes, shares, kommentarer) får vi fram en siffra som vi visar i samband med knappen. Genast känns det hela lite mer intressant.
Alla som har byggt webbplatser har hamnat i en fundering och förhoppningsvis en diskussion om vilken enhet man ska använda som mått i sin CSS eller HTML. Det kan till synes vara en trivial fråga, men den är på intet sätt enkel. Inte förrän nu vill säga. För nu finns det en enhet som heter REM, eller Relative to Root Element.
Tidigare så har man haft möjlighet att välja mellan fyra varianter av enheter: Det klassiska pixelmåttet (px) - som baserat på att vi konsumerar webb på skärmar med pixlar känns naturlig; Punkter (pt) som med fördel används till utskriftsvarianter av webbplatser; Procentsatser (%) som ger en relativ storlek till det senaste bestämda måttet i objektmodellen; Och Relative to Element (em) som likt procentsatsen ger en relation till det senast satta.
När man bygger webbplatser med ramverk finns det en enorm fördel att bygga med relativa mått. Det finns däremot ett problem med att det gärna blir ganska komplext, procentsatser ger ingen egentlig uppfattning av hur stort ett element egentligen är (80% av 17px är vad?), och Relative to Element blir gärna abstrakt (0.8em av 1.7em är vad?).
Så, nu finns REM. Det är precis som det heter relativt till root-elementet i XML-strukturen som används. Det vill säga <html>. Kontentan är att vi kan sätta en font-size för just <html> som vi kan utgå från, för alla värden på webbplatsen. Konsekvensen blir att vi alltid kan räkna med enkla siffror. Om vi sätter att 1REM är 10px så är exempelvis 1.4rem alltid 14px. Därtill har vi möjligheten att skala webbplatsen genom att förändra en rad. Om vi ändrar fontstorleken på html från låt säga 10px till 12px så skalar allt upp, hela webbplatsen - inklusive all grafik som är definierade med REM. Att bygga adaptiva och/eller responsiva lösningar har aldrig varit så enkelt. Den senaste webbplatsen vi använde det i är Carnegie Fonder, som skalar mellan exempelvis desktop och stor desktop med just en förändring mellan 10px och 12px font-storleken i <html>.
Värt att nämna är att procentsatser för att definiera 1rem (ex: 62.5% som motsvarar 10px) inte fungerar i Internet Explorer 9. Å andra sidan har vi sen IE6s död inget behov av att sätta procentuella storlekar (IE6 kan inte skala fasta storlekar). Och, självfallet, hänger inte tidigare versioner än 9 av Internet Explorer med alls. Lösningen på det är att man får definera en fallback: "width:100px; width:10rem;".
Summa kardemumma är att vi har en enkel och hanterbar enhet. För alla storlekar som behöver sättas på en webbplats.
Framtiden är här.
Det senaste halvåret har vi jobbat hårt med Carnegies nya webbplats. Det började med Carnegie Fonder, men resten av koncernen gillade vad vi gjorde och använde våra mallar. Det är en total makeover för banken som markerar starten på något nytt i företagets historia – ett mer transparant och öppet kunskapshus. Det yttrar sig på webbplatsen på flera sätt, bland annat i ett samlat kontextuellt nyhetsflöde, bättre och tydligare fondpresentation och fokus på vad besökarna faktiskt eftersöker. Ett responsivt ramverk och fintrimmat datalager gör upplevelsen extra trevlig.
Vi har gjort informationsarkitektur, interaktionsdesign samt front-end och back-end. Nilsson Mace står för den grafiska designen. Slutresultatet är vi riktigt stolta över, ta en titt på www.carnegie.se/fonder. Mer utförlig information om projektet hittar ni i vårt Carnegie-case.
Carnegie Kinafond i bred desktop samt mobilt
Fyra har blivit fem, Roberto Vega har tagit steget och blivit en fullvärdig Obviusemedlem. Det är vi väldigt glada över, Roberto är en riktigt vass utvecklare. Välkommen!
Vi har ett problem. Ett ganska stort problem.
Det handlar varken om svält eller världskrig, men det är illa ändå. Här kommer ett tekniskt utspel om hur man som utvecklare hamnar i kläm när ny teknik inte har implementerats korrekt.
Webkit, och framför allt Chrome, har börjat tillåta positionering i pixlar som inte är heltal. Vi märkte det först när vi försökte lägga saker brevid varandra i en Google Maps-implementation. Det gick helt enkelt inte. Problematiken ligger i att markers, eller intressepunkter, placeras ut på givna pixelvärden som härleds via lattitud och langitud. När konverteringen görs kommer det ut flyttal, eller låt oss för enkelheten kalla dem decimaltal. Dessa decimaltal behöver avrundas för att passas in i rutmönstret som finns på en skärm. Konsekvensen blir att koordinaterna för vart saker ska ligga blir lite godtyckliga, det sker ingen avrundning till närmsta heltal, utan det landar lite här och var (inom ramen av en pixel). Det är med andra ord omöjligt att få html-element att ligga brevid varandra i Google Maps.
En annan intressant, och för den delen irriterande konsekvens är att rendering av canvas blir suddig. Ibland. Det tog ett tag att lista ut varför, och hitta logik i det, men det visar sig att när bredden på webbläsarens viewport för ett HTML-dokument inte är jämnt delbart med två (när det är ett ojämnt pixelvärde i bredd) så får canvas spel.
Det är antagligen ett försvinnande problem, men det belyser problematiken med modern teknik som inte implementeras på rätt sätt. Vi gissar att Google (som levererar både Chrome och Maps) försöker ta höjd för högre pixeldensitet än vad som hitills har varit tillgänglig på webben. Apples Retinaskärmar och en hel del Androidenheter har ju helt fantastiska skärmar med hög upplösning (eller snarare pixeldensitet), Google strävar antagligen efter att inte halka efter.
Google: gör om och gör rätt.
Även facebook har gått på niten. Som ni kanske har märkt så hoppar deras ikoner runt ibland och logotypen är suddig. Det är samma anledning och samma fel.
Så var det äntligen dags. Vårt första stora släpp. Det är för våra vänner på mäklarkedjan ERA vi lanserar en helt ny webbplats. Låt oss förklara vad vi gjort.
Mäklarsajter är lite speciella då de får majoriteten av trafiken från Hemnet. Därmed blir objektsidan inte sällan det första mötet med sajten (och ibland det enda). Utmaningen för ERA ligger därmed i att få till en bra objektsida, som ger besökaren all bostadsinformation och samtidigt puffar fördelarna med ERA och deras tjänster. Besökarna ska ju trots allt ofta sälja sin egen bostad inom kort och ett minnesvärt intryck är mycket värt.
Ni som är bevandrade i Hemnet-surfande vet säkert att att det finns två viktiga länkar från objekten på Hemnet, Läs mer om bostaden och Fler bilder. Den sistnämnda är den populärast av dessa med ca 65% av klicken. Problemet med denna länk är bara att all annan intressant information om bostaden går förlorad när besökaren landar på en ren bildsida, så som det fungerar på dagens mäklarsajter.
Så hur löser man det? Genom att låta båda länkarna gå till samma sida givetvis. ERAs nya objektsida innehåller allt – ingenting är dolt. En sticky-meny följer med besökaren genom sidan och låter denna snabbt ta sig till de olika avdelningarna. Fler bilder-länken från Hemnet scrollar automatiskt ner och visar alla bilder i ett stort format. När bilderna är slut kommer besökaren naturligt vidare till den utökade objektbeskrivningen och får därmed all information om intresset finns. Inget mer klickande vidare till en riktigt objektsida, allt på ett ställe. En rätt självklar lösning egentligen. Sånt som vi gillar på Obviuse.
Sen har vi också gjort allt annat man kan förvänta sig av en bra mäklarsida – bostadssök med auto-complete, en fiffig funktion för att hitta alla ERAs mäklare och en finfint optimerad teknisk lösning för bra prestanda. Och så är den responsive för er i farten. Och retina-anpassad för er med framtidens skärmar. Det bjuder ingen annan mäklarsajt på vad vi vet.
Är du ännu mer intresserad av vad vi gjort hittar du hela historien på vår case-sida. Eller ta en titt direkt på ERAs webbplats.
Det slog oss att vi inte ens nämnt att Umbraco 5 har lagts ner. Det blir ingen fortsatt utveckling. Alls. Det är på intet sätt en nyhet, men värd att notera. Eftersom vi har en av de få webbplatserna som faktiskt är byggd i femman så är det förstås synd, men vi böjer oss för det större goda. Det visade sig att den vägen de hade valt när det kommer till arkitektur inte var tillfredställande bra. Eller bra och bra, den var för bra. Den var för komplex. Vi tycker om Umbraco, och då framför allt communityn kring det. Det var dessvärre just där skon klämde: när femman blev ett monster i komplexitet hängde inte communuityn med. Gemene medlem hade inte möjlighet att sätta sig in i hur de skulle utveckla på/till plattformen. Beslutet att lägga ner var antagligen sunt. I retroperspektiv. När det levererades under keynoten till den årligt återkommande utvecklarkonferensen Codegarden så var det en chock. Nu, ett par månader senare, är det bra. Umbraco har kvar en del egenheter och en uns rena dåligheter, men Communityn har slutit upp och det finns en kämparglöd. Det har släppts ett par nya versioner av fyran sedan i juni - där en del fina saker från femman har lyfts in; och en del egenheter har åtgärdats. Vi tror fortfarande på Umbraco. Det är enkelt och roligt att utvecka i. Det är kul.
En annan kul sak är att vi har ingått ett patnerskap med EPiServer. Vi har jobbat länge med EPi, och kommer inom en väldigt snar framtid kliva in i ett större projekt på den plattformen. Förhoppningsvis i version 7 som kommer inom en snar framtid. Det är i skrivande stund inte bestämt vilken version det blir, men det ombyggda redaktörsgränssnittet ser väldigt lovande ut. Att det finns förhandsgranskning i skärmbredder som motsvarar olika mobila enheter skadar förstås inte heller då webbplatsen kommer att byggas med responsiv layout. Förstås. För att inte nämna de nya rent tekniska smaskigheter som kommer. Vi ser fram emot att gå in i produktion!
Ungefär samtidigt som vi drog igång Obviuse i vintras så startade även några vänner en digital designbyrå vid namn Nilsson Mace. Vi har hjälpt dom bygga en visitkorts-sajt i responsiv tappning. Vårt första släpp, och förmodligen vårt minsta :)
Likt alla andra som bygger responsiva webbplatser ställs vi inför ett problem: hur hanterar vi skalade bilder? Det brukar tas upp på alla seminarier där responsiv eller adaptiv webb diskuteras. Däremot brukar just den sliden försvinna fortare än kvickt. Det verkar inte vara någon som direkt vet – eller snarare har en bra lösning på det.
Det finns ett par saker att tänka på, dels vill man inte skala bilder hos klienten (besökaren), och inte heller prata för mycket med servern. Det försämmrar prestanda och användarupplevelse och bör således undvikas. Egentligen är den största problematiken att servern inte vet hur stort yta besökaren har i sin webbläsare. Allt annat går att komma runt med lite tänk, men just den nöten är klurig.
Det finns en hel del lösningar ute på webben, mer eller mindre innovativa. Under de gångna åren har det diskuterats flitigt i listor och på forum, W3C har skapat en egen communitysida för problematiken och det kommer säkert att komma något bra ur det. Till slut. Som det är nu har vi dessvärre inte hittat någon lösning som vi tycker är tillfredställande bra.
I väntan på att W3C ska bestämma sig väljer vi att bygga en egen lösning som är en kombination av server– och klientsideprogrammering och som bygger på markup och css såväl som javascript. Vi strävar efter att använda rätt teknik på rätt ställe och gärna kombineras. Å andra sidan går det tvärt emot W3Cs strävan efter att ha allt på en plats. Men innan vi har en picture–tagg som definierar olika bilder för olika storlekar får vi göra det bästa av situationen.
Den lösning vi byggt laddar in en liten version av bilden som vi sedan byter ut snarast möjligt. Vi sparar storleken på fönstret som en cookie och levererar sedan bilder som har anpassad storlek under det framtida besök på webbplatsen. Det innebär att vi minimerar extra nerladdning och ger bilder med maximal kvalitet till besökaren. Dessutom tar vi hänsyn till enheter med högupplösta skärmar med högre upplösning än en "vanlig" dator och leverar större bilder till dessa.
Under den tid det krävs för att bilden ska uppdateras ligger den tidigare bilden kvar, men sträckt till rätt mått. Det fina är att besökaren knappt märker att bilden byts, effekten blir enbart att bilderna plötsligt blir skarpare. Och vid nästa sidladdning är allt som det ska vara direkt. Som om servern visste. Magiskt, inte sant?
Titta på lösningen här: Responsive imagery
Vår webb har som ni kanske märkt fått en smärre ansiktslyftning. Mysigare ikoner, större cirklar, en mer genomtänkt meny och viktigast av allt: länkbara inlägg (kolla sökvägen när du scrollar!).
När vi får lite tid över nästa gång ska vi ge oss på dynamisk inladdning av innehåll också. En ständig utmaning att få in allt på en sida.
Diskussionen mellan utvecklare och designers om hur knappar ska implementeras återkommer alltid.
Denna till synes triviala diskussion tar aldrig slut.
Aldrig.
Man kan tro att det är enkelt, men det finns många aspekter till den – en hel del måsten och en del nice-to-haves. Fram tills för något år sedan tog man en bild med text på och så lade man den som knapp på sin webbplats. Och så var man glad. Men så var det någon som – med all rätt – kom på att det inte är vidare tillgängligt att skriva text i bilder. Eller att knåpa ihop det med script som lämnar en ful knapp som med lite tur funkar när javascript är avstängt. Helt enkelt knappast önskvärda lösningar på problemet.
Vi vill också vara med och tycka till.
Därför har vi gjort en variant som kombinerar nytt och ballt med gamla trotjänare.
Kort sagt så handlar det om att knappar som inte har med formulär att göra är tillfixade med CSS3 med stöd av SVG. De har även – i den här implementationen – små ikoner som bygger på den visuella förståelsen.
Formulärknappar å andra sidan är precis som vanligt.
De är formulärknappar. Som ser "så bra ut som möjligt". Det är så de får se ut om man besöker sidan utan javascript påslaget. Om så inte är fallet så görs de om till knapparna som beskrivs i förra stycket. De blir länkar. Precis som de ovan, men de kommer att posta formulären med hjälp av script.
Vi låter knapparna i äldre versioner av allas vår favoritläsare få hårda kanter – vi nedgraderar så fint vi kan utan att lägga otillfredställande mycket tid på det.
Kontentan av knapparna är att vi har moderna knappar för de som kan hantera det. Och lite mindre fina till de andra. Oavsett vad så har vi bra och fungerande knappar till alla.
Se exempel och hitta kod här: Buttons with fallback
Efter lite diskussion kom det fram att man kan använda
<button type="submit"> med andra html-element i för att komma runt scriptandet. Det ska enligt utsago vara knöligt att få till det bra i alla läsare, men väl värt att kolla på. Samtidigt bevisar det att diskussionen lever. Den är viktig. Och nej, den tar aldrig slut.
Idag fick man som page-ägare ett meddelande av Facebook.
Den 30 mars kommer facebook att ändra utformningen på sidorna. Timeline-funktionen som idag används av användare kommer nu användas på sidor.
Utformningen är i princip identiskt från den vanliga timelinen, dock kommer man som administratör få möjlighet att fälla ut ett lager med statistik och meddelande högst upp ovan för den stora bilden. Detta betyder att vänstermenyn som vi är vana vid från våra sidor försvinner. Obviuse på Facebook är ändrad till nya utformningen om ni vill se ett smakprov. Annars går det bra att förhandsgranska hur det kommer se ut efter den 30 mars.
Applikationer som är knutna till sidan hamnar i boxen under den stora bilden. Tab-applikationer verkar också vid första anblick öppnas i en egen canvas och få 779px att använda sig av istället för 520px som tidigare. Valet att sätta en applikation som landningsida verkar också försvinna.
Facebook öppnar härmed upp för nya möjligheter att marknadsföra varumärken. Som exempel på hur företag idag använder sig av nya timeline finns Starbucks och Coca-Cola. Möjligheten att integrera sina applikationer med timelinen via open-graph kommer ge en nya dimension åt pages.
Facebook har även publicerat en sida om förändringarna: Introducing New Facebook Pages.
Vi utvecklar en mobil tjänst för närvaroregistrering.
Inlägget handlar inte om det, utan vill vi slå ett slag för HTML5 och JavaScript-ramverket Sencha som används för att härma en mobilapp. Fast som en webbplats.
Det har funnits ett tag. Vi har tittat lite på det tidigare men tyckt att det inte varit moget nog att använda kommersiellt. Nu när de däremot släppt en version 2.0 och dessutom ändrat sin licensmodell är det andra bullar.
Det fina med det är att vi hyggligt enkelt kan konsumera en webbplats i en smartphone - med i princip samma funktionalitet och look-and-feel som telefons inbyggda funktioner har. Vi kommer dessutom runt problematiken att en app behöver registreras; godkännas; och distribueras av App Store eller Android Market. Det finns funktionalitet i en telefon vi inte kan använda, men i vårt fall behövs inte kameran i telefonen och vår målgrupp är en utvald skara som själva kan lägga till webbsidan på sin Home Screen genom webbläsaren.
Om man ändå vill göra en distibruerad app så finns det verktyg för att bygga skal som i sin tur laddar ner sidan. Med Sencha är det enklare, snabbare och i vårt fall bättre än att bygga en "riktig" app. Och dessutom stödjer den alla smartphones som har en vettig webbläsare - vi behöver inte bygga en för iPhone, och en för Android.
Det är helt enkelt ett bra ramverk!
Kanske med lite märklig markup, men det vägs upp av en vacker (och rolig) scriptstruktur!
Vi vet av erfarenhet att statistik och mätning är viktigt och därför släpper vi aldrig en lösning utan att ha något form av statistikverktyg installerat.
Så när vi nu släppte vår egna sajt ställdes vi inför ett litet problem, hur vet vi vad som läses? Eftersom vår sajt bara är en lång lista av inlägg så kommer all vår statistik bara visa att besökarna varit inne på en sida (vilket i och för sig är sant). Vi behövde en enkel lösning för att kunna diffrentiera innehållet i Google Analytics (GA).
Fösta steget var att välja strategi i GA. Ska vi använda Event Tracking eller Virtual Pageviews?
Vi valde Virtual Pageviews eftesom vi vill öka på räknaren för de totala antalet sidvisningar. Event Tracking påverkar inte denna räknare. För andra ändamål så som utgående länkar eller fillänkar hade vi valt Event Tracking.
Koden för att spåra en virtual pageview i GA är:
_gaq.push( ['_trackPageview', '/virtual/employees'] );
Notera att vi prefixar vår virtual path med just "/virtual/" detta för att vi enkelt skall kunna sortera på detta i Google Analytics för att vå fram alla våra virtual pageviews.
Steg ett i statistikinsamlandet är klart. Steg två innefattar mera Javascript. Det vi måste göra är att hålla reda vår sidas olika innehåll och när dessa kommer in i besökarens viewport. För att hålla koll på detta använder vi oss av ett javascriptbibliotek som heter jquery-waypoints. Sätter vi ihop allt blir koden:
$("#employess").waypoints({
handler: function(event,direction){
_gaq.push( ['_trackPageview', '/virtual/employees'] );
}
});
Något förenklat, vi vill ju inte mäta 100 gånger om något scrollar upp och ner, vi vill kanske inte heller mäta om någon bara snabbt scrollar förbi ;)
Vi behövde registrera ett globalt actionfilter i Umbraco 5. Det mest naturliga stället att göra detta är i Applicaton_Start() i global.asax.
Men tittar man i Umbraco 5 ser man att det finns en Global.asax, men ingen Global.asax.cs – så hur ska vi kunna registrera Actionfiltret då?
Som tur är så är metoderna i MvcApplication virtual så om vi bara ärver av MvcApplication och overridar Application_Start() så kan vi fylla på med vår egen logik:
class ObviuseMvcApplication : MvcApplication {
protected override void Application_Start() {
base.Application_Start();
GlobalFilters.Filters.Add(
new ActionFilters.
Html5FilterAttribute());
}
}
Efter detta behöver man gå in i Global.asax och ändra Inherits till att peka på rätt klass, dvs den som vi precis skapat:
Direkt när vi bestämt designen på vår nya sida så kände vi att vi var tvunga att stacka "menyn". Så efter någon timmes joxande och en del pixelputtande är vi rätt nöjda med resultatet, dock inte med javascripten som ska få sig en genomgång i kväll.
Annars en bra och produktiv dag på kontoret. Vi önskar våra kunder och vänner en trevlig helg så ses vi nästa vecka.
Samma tid och samma lokal ; )
I dag den första februari 2012 slog Obviuse upp sina portar, vilket också är anledningen till att den här webbplatsen har kommit till världen.
Den är byggd på purfärska CMS:et Umbraco 5 och tro det eller ej, men under de 2 dagar vi tog fram sajten lyckades Umbraco släppa ett par nya versioner av produkten. Kul tänkte vi och migrerade sajten två gånger. Alltid spännande med tidiga versioner!
Annan kuriosa är att designen är helt upplösningsoberoende då vi enbart använder vektorbaserade SVG bilder. Aldrig mer taggiga cirklar : )