23-27 september anordnades europeiska DrupalCon, för åttonde året, och denna gång med 1840 deltagare från hela världen. Från Sverige var vi ett tappert gäng på lite drygt 40 deltagare, från olika företag och verksamheter, som på olika sätt arbetar med webbpubliceringssystemet Drupal. Från Umeå universitetsbibliotek var vi tre deltagare förutom undertecknad (bibliotekarie) även två av våra utvecklare, Ola Boström och David Södermark. Veckan var fullspäckad med intressanta och givande föreläsningar, workshops och BOF:ar ( Birds of a feather kortare, informella träffar för utbyte med andra verksamma inom liknande intresseområden). Exempel på det senare kunde vara att någon intresserad av Drupal i biblioteksverksamheter kunde bestämma tid och plats dit andra intresserade av liknande frågor kunde ta sig. Jag tänker inte försöka sammanfatta alla föreläsningar och träffar under veckan, istället följer här några nedslag i litet av sådant jag tog intresse av och kunde ta med mig i vidare arbete med webb och med Drupal. TRAINING DAY SASS AND COMPASS FOR RWD Förutom själva konferensen, som spänner över tre dagar, brukar DrupalCon inledas med en training day, där man kan välja på en heldag med olika fokus utifrån intresseområde, och för olika målgrupper beroende på förkunskaper. För min del valde jag Advanced SASS and Compass for RWD. RWD När man pratar om webbutveckling är RWD, Responsive Web Design, ett centralt begrepp. De senaste årens utveckling mot olika typer av enheter surfplattor och datorer i olika format och upplösning gör att webbplatser helst bör anpassas till att se olika ut, och kanske fungera olika, beroende på vilken enhet webbplatsen ses/används på. 1
Exempel på olika enheter, där en webbplats innehåll visas på olika sätt beroende på enhet. Tidigare var det vanligare med det som kallas User agent sniffing ; Olika webbgränssnitt användes beroende på enhetens märke och webbläsare. Med RWD frågar vi istället webbläsaren som öppnar vår webbplats vad den kan göra, inte vad den är. Är du en pekskärm? Vilken skärmstorlek har du? etc. För att effektivt arbeta med RWD kan verktyg som CSS Media Querys och jquery användas. Teknikerna med SASS och Compass är också mycket användbart, och det var detta vi fokuserade på den här dagen. SASS OCH COMPASS SASS står för Syntactlically Awesome Style Sheets, en vidareutveckling av CSS (Cascading Style Sheets). SASS kommer i två syntaxer; Sass och SCSS. Med SCSS används samma syntax som i CSS, medan Sass använder en något minimaliserad syntax, där t.ex. klammerparanteser inte används. En del tycker att Sass-koden ger bättre översikt, medan andra föredrar SCSS. Fördelen med SCSS är att detta är enklare att integrera, och befintliga projekt kan konverteras stegvis från CSS till SASS med SCSS. Compass, kan man säga, är Sass s bästa vän. De hänger ihop. Compass körs i bakgrunden, håller reda på vilka filer som ändrats, och kompilerar kod skriven i SCSS eller Sass till CSS. Compass kommer också med färdiga funktioner; man brukar prata om functions, extensions och mixins. Det handlar om att effektivisera, förenkla och förbättra CSS för webbplatsen. Till exempel kan man välja att i en fil ange olika grundfärger, för fonter, länkar, bakgrund etc. Dessa variabler kan sedan anropas från andra SASS-filer. Om man sedan väljer att byta grafisk profil på webbplatsen behöver man bara byta färgkod på ett ställe, så slår det igenom överallt. På samma sätt kan man på ett ställe ange s.k. brytpunkter för webbplatsen arbetar man med RWD vill man kunna anpassa webbplatsens layout och utseende olika, beroende på om den visas på fullskärm eller mobilskärm. Med SASS kan vi ange dessa brytpunkter på ett ställe, och sedan anropa dem från flera ställen. Om vi sedan vill ändra de här brytpunkterna, från säg max 380px bred för minsta skärmstorleken till max 480px behöver vi bara göra detta på ett ställe. 2
Våra duktiga lärare för dagen visade oss en skiss, för att förklara uppbyggnaden av SASS och Compass i relation till Drupal. För oss som jobbar med Drupal är det en rätt bra sammanställning; Med HTML kan man göra en del med PHP ännu lite till. I Drupal jobbar vi med HTML och PHP och tar hjälp av moduler för funktionalitet. På motsvarande sätt kan man göra en del med CSS ännu mer med Sass. Och med Compass får vi extra funktioner och möjligheter. DRUPAL, ZEN OCH SFIS.NU För egen del har jag haft stor nytta av att fördjupa mig i möjligheterna med SASS och Compass, inte minst i arbetet med webbgruppen i SFIS. År 2011 lanserade vi en, då, ny webbplats byggd i Drupal, version 6. I början på 2014 kunde vi nu lansera ännu en ny version, den här gången i Drupal version 7. Här har vi jobbat med och utgått från ett tema som är förberett för att fungera responsivt, med SASS och Compass. Förhoppningen är att detta bidragit till en bättre och mer lättnavigerad webbplats för SFIS medlemmar. GIT MAKES ME ANGRY INSIDE En annan sak man kan råka ut för i rätt omfattande grad när man arbetar med Drupal är versionshanteringssystemet Git. Enkelt uttryck kan man säga att det är ett program för att kunna spara olika versioner av projekt, ett sätt att undvika att man, om man jobbar flera i ett projekt, kör över varandras ändringar, och ett verktyg för att kunna gå tillbaka och se vad som gjort och av vem. I Git arbetar man med master -versioner, och branches för egna utvecklingsdelar som man sedan mergar till mastern. Jag brukar tänka på det som ett träd med olika grenar. Emma Jane Hogbin höll i föreläsningen Git makes me angry inside, om hur man som icke-utvecklare ändå kan närma sig versionshantering med Git. Hon inledde med att förklara hur Git ursprungligen byggdes av Linux kärnutvecklare för Linux kärnutvecklare. Detta innebär inte att vi vanliga dödliga inte kan använda programmet, men det ger lite bakgrund och förståelse till varför Git ser ut och fungerar som det gör. Bland det första och viktigaste vi bör lära oss för att arbeta med Git är du behöver inte memorera alla kommandon. Du får inte betalt för att memorera kommandon. Om du bara förstår processen kan du googla vilka kommandon som ska användas, och skriva ner de viktigaste i en lathund. Och lita på att den informationen faktiskt finns kvar nedskrivet, så du behöver inte hålla kvar allt i minnet. Eller som Emma Jane uttryckte det: I use Git as a tool, instead of Git treating me like a tool. 3
Hon konstaterade vidare att problemen vi handskas med till 90% är sociala, och att bland det första vi bör göra när vi börjar arbeta med versionshantering är att identifiera teamets sammansättning, roller och uppgifter. Vilka arbetsflöden finns? Hur kan dessa effektiviseras? Var passar du in, och var kan Git komma in? När det finns sammanställning över teamets sammansättning, roller, funktioner och arbetsflöden sinsemellan kan man gå vidare till ett flödesschema. Den här illustrationen är ingen roll syn för många av oss men projektledare kan istället nicka och tycka att ja, det ser rimligt ut. (Tips: vrider man huvudet åt vänster ser man att det också är en tidslinje). Man kan förtydliga detta med att illustrera hur teammedlemmar kan arbeta med samma projekt, fast olika delar, och ibland med samma delar. En sådan här illustration kan sedan kopplas till ett flödesschema, och det kan hjälpa till att förstå flödesschemat och var Git (eller annat versionshanteringsprogram) kan komma in. Men det hon framför allt lyckades förmedla var att möta Git utan rädsla. Utan se det som det verktyg det är, och använda det utifrån den kännedomen. ESSENTIAL TECHNIQUES FOR DESIGNING DELIGHTFUL WEB SITES Det är inte bara webbtekniska tekniker man kan vara hjälpt av när man utvecklar webbsidor. Christina Perfetti gav en föreläsning om hur vi kan jobba med olika andra tekniker för att ta fram en bra webbplats. Perfetti jobbar som UX-designer, och tillbringar mycket tid med att undersöka hur användarna använder webbplatser eller snarare; hur användare misslyckas att använda webbplatser Hon förklarade begreppet Delightful web sites med att det handlar om värde och nytta, att användarna får t.o.m. mer än de förväntar sig och att de utöver det också känner en känslomässig koppling, en känsla av glädje och förnöjsamhet vid användningen. Och det är väl det man önskar som webbdesigner! Ungefär här plockade Perfetti fram en smörgås. Det är nämligen det hon liknar webbdesignprocessen med att göra en smörgås. Och hon berättade om hur hennes mamma brukade göra smörgåsar åt henne, och hur mamman hade en process för detta. Vid en punkt ville Perfetti göra egna smörgåsar, och hon började iaktta hur mamman gjorde hon lärde sig metoden. Så småningom lärde hon sig att salladsbladen blev geggiga om de legat i smörgåsen några timmar. Så hon lärde sig tekniken att lägga salladsbladet i en separat påse, och lägga den på smörgåsen strax innan det var dags att äta 4
smörgåsen. Och när hon flyttade hemifrån lärde hon sig också tricks för att få smörgåsen som hon ville om brödrost saknas, kan man t.ex. använda strykjärn. På motsvarande sätt gick hon ut i yrkesverksamheten som UX-designer med hypotesen att framgångsrika team, som levererar fantastiska jobbar med fokus på metod och processer istället blev hon varse att de framgångsrika teamen istället hade fokus på teknik och tricks, och att de team som inte lyckades kämpade med formella processer. Teamen som jobbade med teknik och tricks, och med förståelse för vad användarna ville ha, och ett gemensamt utbyte mellan designers och utvecklare lyckades. Vi fick med oss några matnyttiga råd om hur man bäst arbetar med teknik och tricks i praktiken: Testa tidigt och ofta Använd traditionella användartester observera användarna i deras naturliga miljö, när de utför de uppgifter de brukar Testa snabbt! Välj ut en sida med specifikt innehåll och syfte, visa den under fem sekunder förstår användarna det du vill förmedla/hur de använder sidan? Man kan också använda sig av first click test som teknik: Ge användarna en specifik uppgift på webbplatsen. Var klickar de först? Deras första klick kan ge en tydlig indikation på hur bra de kan använda sig av och förstår webbplatsen. Och vikten av att observera användarna i deras naturliga miljö kan inte underskattas vilka problem, och vilken typ av frustration möter de? Det är där vi ska börja, med problemen inte med lösningen. WEBBSTYRNING OCH -STRATEGIER ELLER MANAGING CHAOS En av de s.k. Key Note-talarna var Lisa Welchman, som under många år arbetat med och hjälpt företag och organisationer med administration av och strategier för deras digitala infrastruktur. Här har hon varit många behjälplig i att få rätsida på stora webbplatser, eller som hon uttrycker det: Managing chaos. Styrning av digitala organisationer handlar, förklarade hon, till stor del om att fastslå lämplig beslutsfattande nivå för strategier, policys och standarder. Basically, deciding who decides, som hon sammanfattade det. 5
Welchman förklarade att i många projekt diskuteras det mycket kring gränssnittsdesign, informationsarkitektur, redaktörsrättigheter, eller infrastrukturella frågor som val av webbpubliceringsverktyg. Men i många organisationer har man aldrig tagit ett kliv tillbaka och beslut om vilka som egentligen är beslutsfattare, och vem som ansvarar för önskade standarder. Hon kunde också konstatera att i många företag och verksamheter kan det finnas många som tycker att beslutsfattande rätten ligger hos dem, och i många fall har de inte kompetensen för detta men historiskt sett har den rätten legat hos dem, och vill därför fortsättningsvis hävda den. Om vi kan få klarhet i den biten, kan vi också få klarhet i vem som är lämplig att vända sig till när diskussioner uppstår, eller beslut måste fattas. Det handlar om ett ramverk för en fungerande verksamhet. Om resurser saknas för att starta ett fullskaligt styrningssystem för webborganisationen kan man börja med att i alla fall bena ut vem som ansvarar för olika delar. Här brukar man dela upp webborganisationen i fyra delar; Design Redaktionellt Utgivning och utveckling Nätverk och server-infrastruktur Welchman konstaterar också att det tyvärr finns många som tycker sig besitta beslutanderätt i styrningen av webborganisationen, eller tycker sig borde ha det. Denna oklarhet leder tyvärr till många diskussioner inom projekt. Bättre är då att lyfta frågan om ansvarsfördelning utanför projektet. Because if you re in the middle of a project and you try to make these decisions, it s called a fight. If you do it outside the context of a project, it will be a conversation. 6