E_5 Fullstack-app

Ett preliminärt namn på appen

Veckans mat

En beskrivning av appen

Bygg ett arkiv av maträtter som du brukar eller vill äta. Du kan tagga maträtterna med sökord såsom vegetariskt, soppa, italienskt. Du kan också lägga till var du hittar receptet, t.ex. en webblänk eller bara en anteckning såsom ”Vår kokbok, s. 52.” Du kan sedan slumpa fram en veckomatsedel. Du kan välja specifika sökord för de olika veckodagarna, t.ex. soppa på torsdag. Du kan även gå tillbaka i arkivet och se veckomatsedlar från tidigare veckor.

Målgrupp - vem är användaren?

Alla som på ett enkelt sätt vill skapa en veckomatsedel av rätter som man redan äter och gillar. Bra för den som gillar att laga mat, samt att organisera och planera. Detta kan tilltala småbarnsföräldrar eller andra som har mycket att göra men ändå vill laga goda middagar.

Syfte - vad ska appen göra?

Appen ska göra det enklare att planera sin vecka och hjälpa en att komma ihåg maträtter som man gillar.

Designförslag - vilka vyer finns, vad gör de och hur ser de ut?

Startsida

Inloggad sida

Fyra milstolpar/delmoment som ska uppfyllas under utvecklingens gång

- Komma fram till hur databasen ska byggas upp, vilka kollektioner och dokument som ska finnas - Bygga funktionalitet för att skapa, läsa, uppdatera och radera data (CRUD) - Fixa autentisering av användare - Bygga frontend samt funktionalitet för att kommunicera data mellan frontend och backend

Länk till GitHub där projektet kommer versionshanteras

Veckans mat - repository

API – att arbeta med data

Photo Search (C3)

Repository för C3

Jag har valt att använda Flickrs API för att göra en fotosök-sida. Det går att göra en sökning baserad på sökord eller plats, alternativt se dagens mest intressanta bilder.

Spel

Font Game

Repository för Font Game

Mitt spel är en frågespel som går ut på att testa om man kan se skillnad på olika typsnitt. Målgruppen är alla som har ett intresse för typsnitt. Tanken är att man ska kunna spela spelet flera gånger och på så sätt öva upp sin förmåga att känna igen typsnitt.

Spelet är uppdelat i tre nivåer med olika svårighetsgrader och man måste klara varje nivå för att gå vidare till nästa. Varje fråga består av två alternativ och det gäller att välja det alternativ som visar typsnittet i rubriken. En poängräknare håller koll på poängen.

Det var en utmaning att få ihop spelet. Även om principen är enkel, så gäller det att utforma koden på ett bra och logiskt sätt. Jag gjorde ett flow-chart som grund för min kod, men jag tror att jag hade behövt göra den mer detaljerad för att underlätta arbetet mer. Jag fick tänka om många gånger innan jag fick ihop spelet. Uppgiften var en bra övning och gjorde att jag fick testa på sådant vi gått igenom på föreläsningar, såsom objekt och closures.

Det finns en del utvecklingsmöjligheter för spelet såsom att göra det svårare att fuska genom att döpa om bilderna som används i spelet, göra så att ordningen på frågorna slumpas fram, samt göra så att ordningen på svarsalternativen slumpas fram.

Att göra-lista

Att göra-lista

Den här uppgiften var intressant och utmanande. Att använda Javascript för att manipulera domen helt utan jQuery var väldigt lärorikt. Local storage var något jag inte kände till sedan tidigare så det var intressant att sätta sig in i hur det fungerade.

Sandra testade min app och den feedback jag fick från henne var att det inte var så intuitivt hur man skulle spara sina ändringar. Jag hade gjort så att man skulle klicka utanför textrutan för att spara ändringarna. Efter hennes feedback gjorde jag istället så att ändra-knappen ändras till en spara-knapp i redigeringsläge.

Infografik

Infografik – Skogen

Repository för infografik – Skogen

Mina skisser

Jag har byggt upp min infografik ungefär som den dramaturgiska modellen, så som vi lärde oss i föreläsningen om design.

Först kommer anslaget som presenterar vad det ska handla om, nämligen skogen.

Sedan följer presentationen där jag presenterar vilka positiva effekter skogen har och ger flera anledningar till varför det är viktigt att bry sig om den.

Sedan kommer upptrappningen där jag presenterar hotet mot skogen – avskogningen.

Efter detta kommer lösningen där jag visar vad man som individ kan göra för att rädda träd. Jag länkar även till organisationer så att besökaren kan klicka sig vidare, läsa mer och kanske stödja någon av dem.

Till sist kommer avtoningen där jag länkar till mina källor. Besökaren kan följa länkarna och få mer information om ämnet. Här har jag samma bakgrundsbild som i anslaget för att återkoppla till början och ”knyta ihop säcken”.

Egen reflektion - B3 & B4

Vi började med att ha ett fysiskt möte då vi gick igenom uppgifterna och bestämde i stora drag hur vi skulle lägga upp vårt arbete. Vi läste in oss på Scrum och bestämde att två av oss skulle testa på rollen som product owner och två skulle vara scrum master. Vi kom fram till att vi skulle ha regelbundna sprint planning-möten. När vi påbörjat arbetet kände vi att en sprint-längd på en vecka skulle vara lagom. Emellan våra veckomöten har vi kommunicerat på Slack och hjälpt varandra om vi stött på problem.

Vi har för det mesta gått efter principen att alla gör allt. Det är inte alltid det mest effektiva, men det gör att alla får lära sig alla steg i processen. Det är bra att alla får får träna på att exempelvis skissa och koda.

En annan fördel med att alla gör allt är att vi har haft flera olika förslag till bland annat företagsnamn, logotyp och designskisser och har utifrån dem kunnat välja det bästa förslaget eller kombinera flera förslag.

Vissa saker har vi delat upp mellan oss, till exempel har vi gjort skisser för olika delar och delat upp kodandet av olika delar på webbsidan. Vi har gjort så att den delen man kodade i B3 har man också fått koda i B4.

Det är svårt att precisera vad jag personligen har gjort i projektet då vi alla har varit inblandade i det mesta. Men jag har bidragit till företagsidé, företagsnamn, logotyp, grafisk manual, wireframes och mock-ups och skrivit en del av koden för både B3 och B4.

Vi har valt att vår webbsida ska bestå av en enda html-sida då vi tycker att detta gör att sidan blir lätt att navigera på alla plattformar. Vi har försökt göra så att användaren får en likvärdig upplevelse oavsett om hen använder mobil, surfplatta eller dator.

Vi har använt oss av de typsnitt och färger vi har specificerat i manualen så att användaren ska känna igen vårt varumärke. Vi använder olika färger för olika avdelningar för att göra det extra tydligt för användaren. Bilden högst upp ska symbolisera vad vårt företag står för och den stora rubriken följt av underrubriken förtydligar budskapet ytterligare. Vi har tänkt på att det ska vara god läsbarhet på texten när vi valt typsnittsstorlek och radavstånd.

En viktig erfarenhet som uppgiften gav mig var att få känna på hur det är att jobba med versionshantering i team. Det har varit bra att få praktisk övning i att göra commits, pull requests och att lösa konflikter.

Det har också varit intressant att se hur det är att arbeta med Scrum i praktiken, även om vi inte har tillämpat det fullt ut så har vi ändå fått en känsla för det. Det tog ett tag att förstå arbetssättet och vad de olika rollerna ska göra, men sedan flöt arbetet på bra. Vi har använt oss av Trello för att få en överblick över vad som ska göras och för att se var vi befinner oss i processen med olika delmoment.

En viktig lärdom jag tar med mig är att när flera personer jobbar i olika grenar av projektet kan det vara bra att först sätta upp generella stilar i css-dokumentet och sedan göra mer specifika stilar. Vi började alla på varsin del av projektet och gjorde egna specifika stilar vilket gör att vi nu har en hel del upprepande css-kod. Den skulle definitivt kunna skrivas mer effektivt och det är något jag tänker ta med mig till nästa projekt.

CSS - Zengarden

Länk till CSS Zengarden.

Länk till repository på Github.

Länk till min skiss.

Vad gäller designval så har jag ett grönt skogstema som går igenom hela sidan. Jag har valt att begränsa antalet typsnitt och färger till några få, för att det ska se enhetligt och stilrent ut. Samtidigt ville jag att designen skulle vara varierad och har därför valt att inkludera dekorationselement och bilder för att göra sidan mer omväxlande.

Yrkesrollen

HiQ är ett IT-företag som arbetar inom en mängd olika branscher såsom telekom, fordon, industri, offentlig sektor och handel. De är specialister inom bland annat, mobilitet, telekom och digital kommunikation. De har kontor på flera platser i landet och kontoret i Norrköping är speciellt inriktat mot frontend.

Carolina jobbar som UX- och frontendutvecklare på HiQ. I ett års tid har hon varit uthyrd som konsult hos SMHI. Den här artikeln kommer därför utgå ifrån hur hon jobbar i sitt utvecklarteam hos SMHI, snarare än HiQ.

Utvecklarteamet hos SMHI arbetar med olika tjänster som länkas in på hemsidan som moduler. Man kan säga att de levererar ”små paket” med tjänster. Ett annat team jobbar med själva ”skalet” på hemsidan, som är uppbyggt av CMS-systemet Polopoly.

CMS står för content management system och gör det möjligt att redigera och publicera innehåll på en webbsida utan att behöva koda. Användaren loggar in i ett användargränssnitt (user interface, UI) och behöver inte ha några kunskaper i HTML. Polopoly är ett av de större kommersiella CMS-systemen, men det finns även CMS som är ”open source”, det vill säga öppna och fria att använda. Exempel på öppna system är Wordpress och Drupal.

Carolinas roll i teamet är att arbeta med både UX- och frontendutveckling. UX står för ”user experience” och handlar om att utforma exempelvis en webbsida så att det blir en bra upplevelse för användaren. Tanken är att det ska vara enkelt att använda en produkt eller tjänst och fokus ligger på användbarhet (usability) och tillgänglighet.

Förutom Carolina består teamet av en teamledare, flera utvecklare och testare samt en meteorolog som är den verksamhetskunniga inom teamet. De är tolv personer i teamet, varav fem konsulter. Ett par av konsulterna arbetar på distans.

Arbetsprocessen ser lite olika ut beroende på om produkten är prioriterad, om den är det finns mer resurser att tillgå. Exempel på prioriterade produkter är prognoserna och varningssidan. Om resurser finns börjar processen med en marknadsundersökning och det görs intervjuer med kunder. Därefter startar en intern utredning där verksamhetsmålen ses över.

Nästa steg är workshops där de utgår från hypoteser om användarna. Ibland när resurserna inte räcker till marknadsundersökning och intervjuer, får de istället gissa och leva sig in i hur kunden tänker och även utgå från sig själva. De har också en kundportal de kan titta i, som är som en databas där kundernas åsikter har samlats. Workshopen går sedan ut på att göra många väldigt snabba prototyper.

Efter workshopen gör Carolina en sammanställning av allt material. Hon skissar först för hand och sedan i Balsamiq. Balsamiq är ett enkelt skissprogram som används för att göra mockups, det vill säga en modell för hur den färdiga sidan ska se ut. Det är enkelheten i programmet som tilltalar Carolina.

Nästa steg är att göra enkla HTML-prototyper som testas av användare. Till sin hjälp har Carolina ett kodbibliotek som hon kan plocka element ifrån. Elementen består av färdiga kodsnuttar och med hjälp av dessa går det snabbt att bygga upp en prototyp. Elementen har dessutom semantiskt korrekt kod. Carolina tycker att det underlättar när koden är rätt från början, annars är risken att det inte blir rätt i nästa steg när hon lämnar över sitt arbete till utvecklarna.

Efter användartester gör Carolina en mall för hur sidan ska se ut.  Hon använder sig av ramverket Bootstrap för att lägga grunden till layouten. Genom att använda Bootstrap får man ett gridsystem som från början är responsivt och utvecklat enligt principen mobile first (källa: getbootstrap.com). Responsiv innebär att sidan anpassar sig och skalas efter skärmens storlek. Mobile first innebär att den designas med tanke på mobila enheter i första hand.

Carolina är framförallt kunnig inom HTML och CSS, men hon går även in och justerar javascript-kod samt använder sig av javascript-biblioteket jQuery. Hon tycker det är viktigt att ha bra ordning på koden i HTML och CSS, så att allting är semantiskt korrekt. Rätt taggar underlättar användbarheten och tillgängligheten.

När Carolina är klar med designen lämnar hon över till utvecklarna. När produkten är färdigkodad testas den av testarna och justeringar görs. Efter detta släpps produkten. Att en produkt släpps betyder inte att den är felfri, utan det betyder bara att den är tillräckligt bra för att kunna lanseras. Ingenting blir någonsin perfekt, men någon gång måste processen ändå stoppas.

Teamet arbetar agilt med scrum. Agil betyder lättrörlig och ett agilt arbetssätt innebär att snabbt anpassa sig till förändring (källa: webbstrateg.nu). Det finns ett antal agila metoder och de bygger alla på det agila manifestet. Scrum är en av de agila metoderna som används för att utveckla produkter.

I Carolinas team används både fysiska och digitala verktyg för att arbeta agilt. Den fysiska whiteboarden med lappar är bra för att skapa en överblick över hela utvecklingsarbetet, tycker Carolina. Whiteboarden delas in efter olika utvecklingsstadier och under varje del sätts lappar upp som beskriver vad som behöver göras. På lappen sitter en knapp med ett fotografi på den eller de som arbetar med den specifika uppgiften. Teamet använder också digitala verktyg som Trello inom enskilda projekt. Trello är en digital board där man kan göra listor som man lägger i olika kort.

Carolina jobbar både med UX och frontend, både med design och kod. Fördelen med detta är att hon själv kan åtgärda saker snabbt, utan att vara beroende av någon annan. Hon tycker att det är en bra kombination av kunskaper och något som behövs i branschen.

När jag träffar Carolina jobbar hon med ett projekt för att göra SMHI:s mobilapp tillgänglig för synskadade genom voice-over. För att visa vad det handlar om öppnar hon appen, slår på voice-over och stänger av sin skärm.

”Det är så här blinda ser vår app”, konstaterar hon. Hon har haft mycket kontakt med en person som är blind, som har hjälpt henne förstå hur det fungerar och att sätta sig in i olika situationer.

Eftersom SMHI är en myndighet har de enligt lagen krav på sig att de måste vara tillgängliga för alla. Carolina tror att det kan vara lättare att få igenom sina förslag om tillgänglighet och användbarhet här än på ett kommersiellt företag som inte har lagkravet.

”Det är vanligt att man som UX-utvecklare måste fightas för användbarheten”, menar hon.

Vad gäller framtiden som frontendutvecklare tror hon att det kommer behövas fler kunniga människor inom UX. Hon menar att kunskaper i UX är en stor fördel på arbetsmarknaden idag, gärna i kombination med teknikkunskaper. Jämfört med när hon började som UX- och frontendutvecklare tycker hon att folk i allmänhet har börjat förstå mer kring användbarhet och tillgänglighet. Hon tror behovet kommer fortsätta att växa inom detta område.

Sammanfattning och reflektion

Det har blivit allt viktigare att alla ska kunna ta del av den digitala världen. Du ska kunna använda webben och mobila appar även om du exempelvis är synskadad. Det ställer högre krav på utvecklarna. Som frontendutvecklare måste vi använda oss av rätt syntax så att vår kod blir tillgänglig. I början av webbens utveckling var det kanske inte lika viktigt att skriva semantiskt korrekt kod. Nu tar det digitala över fler och fler aspekter av vårt liv och alla måste kunna ta del av den här utvecklingen oavsett funktionsnedsättning.

En annan sak som inte fanns i webbens början var alla olika plattformar att förhålla sig till. Nu måste vi utforma responsiva webbsidor som fungerar på alla möjliga slags enheter. På så sätt har arbetet som frontendutvecklare blivit mer komplext jämfört med hur det var innan mobiler och surfplattor fanns med i bilden.

Som Carolina säger så är det en fördel att som frontendutvecklare ha kunskaper inom både teknik, design och UX. Det går inte längre att se design, frontend och backend som separata delar, då allt hänger ihop. Som frontendutvecklare måste vi ha överblick över helheten.

Källor:
http://www.webbstrateg.nu/vad-betyder-egentligen-att-jobba-agilt/
http://getbootstrap.com/css/

Webben om 5 år

Det kommer krävas fler tjänster för att hantera det enorma informationsflödet som sköljer över oss. Det kommer också behövas fler tjänster för att hantera den enorma mängd fotografier vi själva producerar.

Jag tror det kan komma att bli en informationsmättnad som en motreaktion på det enorma flödet som finns. Det kommer bli allt vanligare att vilja ta en paus från flödet och vi kommer använda olika tjänster för att stänga av allt under en begränsad tid.

Vi kommer bli ännu mer kräsna med vad vi läser och tar till oss. Bra och kvalitativt innehåll blir allt viktigare. Ett exempel på denna tendens är att långa och bra skrivna facebook-inlägg får många ”likes”. Kvalitet går före kvantitet och ansträngning ger resultat.

Informationsflödet blir alltmer anpassat efter individen vilket gör att var och en lever mer och mer i sin egen ”informationsbubbla”. Detta kan vara farligt eftersom man missar sådan information som inte stämmer med den egna världsbilden.

Det kan också komma en motreaktion mot att företag som Google bevakar oss och använder information mot oss i reklamsyfte. Det kan komma fler alternativa tjänster som inte sparar information om oss.

Webbsidor blir mer och mer responsiva och fungerar bra på alla möjliga mobila enheter, många ligger efter med detta idag. Jag tror inte att vi kommer vilja fortsätta ladda ner massor av appar för att kunna utföra tjänster, utan webbsidan ska istället vara utformad så att den går att använda på ett bra och smidigt sätt.

Webben ersätter traditionellt TV-tittande i ännu högre grad. Vi använder oss ännu mer av streaming-tjänster och tv-tablåerna blir allt mer förlegade.

Mitt första inlägg

Nu har jag börjat studera!