Responsivt Design - DMAA0213. Afgangsprojekt DMAA0213

Responsivt Design - DMAA0213 Afgangsprojekt DMAA0213 Jesper Bjørn Andersen 18-06-2015

5. semester, afgangsprojekt - Responsivt Design Vejleder: Gunhild Marie Andersen Afsluttet: 18 Juni 2015 Deltager: Jesper Bjørn Andersen 2

Forord Denne rapport er udarbejdet i forbindelse med afgangsprojektet for 5. semester på UCN og vil som primært formål fortælle og vise hvad der er blevet arbejdet med. Rapporten omhandler et projekt, hvor firmaet Caremaker skal have ny visuel identitet. Ved at gå over til den nye visuelle identitet skal siden opbygges således, at den er responsiv og derved tilpasser layoutet til enheden man ser på siden med (det være computer eller smartphones). I selve rapporten vil jeg fortælle om hvad det vil sige at gøre brug af responsivt design og hvilken fordele og ulemper der kan forekomme. Derudover vil jeg gennemgå hvilken fremgangsmåde jeg har brugt til at løse de forskellige problemstillinger og hvad overvejelser jeg har foretaget mig. 3

Indholdsfortegnelse Forord... 3 Indledning... 6 Motivation... 7 Problemformulering... 7 Afgrænsninger... 7 Funktionelle krav... 9 Kravspecificering... 9 Mockups... 11 Klasse diagram og domæne model... 12 Systemudvikling... 13 Agile arbejdsmetode... 13 XP... 14 Scrum... 14 Kanban... 15 UP... 16 Traditionel mod Agil... 17 Boehm... 18 Arbejdsprocessen... 19 Arkitektur... 20 Responsivt design... 20 Hvorfor Media Queries?... 21 Kode... 22 4

Konklusion... 24 Perspektivering... 25 Kildehenvisninger... 26 5

Indledning Caremaker er en virksomhed, som har skabt en online platform, hvor enhver person kan oprette en indsamling. Disse indsamlinger kan være til sig sig selv eller 3. person og kan være alt fra indsamling mod sygdom, til ny bil, til rejser mv. Caremaker's hjemmeside blev i sin tid bygget op omkring PHP, MySQL og TYPO3. Da en hjemmeside, som indeholder et CMS system kan lukke for noget af friheden for designeren, så ønsker Caremaker at komme helt væk fra TYPO3. Siden har på stående fod meget rod i koden da enkelte elementer af siden er lavet efter MVC arkitektur, men andre er ikke, samt meget kode går gennem TYPO3, så at lave en overgang for at gå væk fra TYPO3 vil simpelthen tage alt for lang tid. Derfor har Caremaker set på at lave en helt ny side fra bunden med nyt visuelt design og MVC arkitektur. Udover det, har Caremaker set via google analytics, at største delen af deres besøgende faktisk er via smart phones og ikke PC. Derfor skal siden også være responsiv og derved kunne have et rigtig fint layout på smart phone også. Det er derfor min opgave at lave en prototype, som kan demonstrere det nye design så vel som den responsive del. 6

Motivation Da jeg før start på afgangsprojekt var i praktik hos Caremaker og så hvilken forskel en virksomhed som denne kan gøre i folks liv, følte jeg en stor motivation til selve arbejdet jeg lavede. Da jeg selv har arbejdet med deres backend kode og jeg også kunne mærke hvor stressende det kan være at arbejde med deres side, da koden er så roden som den er. Jeg arbejdede med at optimere deres nuværende side til at være responsiv, men der var utrolig mange komplikationer, da meget var styret gennem deres CMS. Jeg syntes derfor at genopbygge deres hjemmeside i nyt layout, uden CMS og som er responsiv ville ikke blot kunne give brugeren en bedre oplevelse, men også spare Caremaker for en masse mandetimers arbejde. Problemformulering Hvordan kan Caremaker spare tid på at vedligeholde deres hjemmeside og hvordan kan de give brugere på en hver enhed den bedst mulige brugeroplevelse? For at besvare disse spørgsmål vil jeg: Udarbejde en prototype, som er opbygget over MVC. Denne prototype vil gøre brug af media queries til at gøre siden responsiv. Afgrænsninger Da Caremaker allerede har udarbejdet mockups for hvorledes designet skal se ud, må jeg holde mig inden for visse rammer og er derfor ikke i stand til at ændre store dele af selve designet. 7

Jeg har valgt at arbejde med egen database og webhotel, da jeg følte det ville blive for indvirket, at arbejde på deres servers. Dette var mest grundet, at jeg ville skulle have åbnet for IP hver gang jeg skulle arbejde et andet sted fra. Grundet mit valg om at arbejde på egen server har jeg måtte opbygge egen database struktur og klasser. Derfor har jeg måtte begrænse visse features, dog stadig holdt mig til hoved opgaven, som var design delen og det responsive. 8

Funktionelle krav Jeg vil under dette emne beskrive hvilken funktionelle krav Caremaker stiller til deres hjemmeside. Derudover vil jeg skrive hvilken begrænsninger jeg har gjort mig og hvad jeg vil arbejde med. Kravspecificering Man skulle kunne oprette en bruger og logge på eller logge på via Facebook. En bruger skal kunne oprette en indsamling. Som bruge skal have en oversigt under sin profil, hvor de kan følge indsamlinger som de har doneret til. Man skal kunne donere med kreditkort. Man behøver ikke bruger for at kunne afgive en donation. Hjemmesidens layout skal være responsivt og derfor tilpasse sig til enheden man kigger fra. Siden skal have facebook integrering, så man let kan dele indsamlinger på facebook og kommentere på dem. Der skal kunne aflæses statistik på siden. Siden skal oversættes til flere sprog. Man skulle ved oprettelse af indsamlinger kunne optage en kort film via sit webcam og upload, samt upload billeder. Man skal også kunne sætte et indsamlings mål og en slut dato for indsamlingen. Back end koden skal opbygges i MVC for at gøre det lettere at arbejde med. Siden skal anvende HTML og PHP, som primær kode sprog, men må også benytte Jquery og java scripts. Siden skal benytte MySQL som database. Jeg vil ud fra overstående afgrænse mig fra disse emner: 9

Login system og facebook integrering - Da Caremaker allerede har et login system både med eller uden Facebook, som let kan påkobles ser jeg ingen grund til at lave det fra bunden. Oprettelse af indsamlinger, samt at give donationer - Da min primær opgave er at give Caremaker en ny identitet og da de allerede har de nødvendige klasser, mener jeg det let kan på kobles efterfølgende. Statistik - Denne del er sat op i Caremaker's egen google analytics Hvilken opgaver jeg vil arbejde med, samt deres prioritet: Opsætte ny visuel identitet - Jeg må først oprette deres identitet i følge mockups. Oprette prototype klasser, samt database tabeller - Da jeg ikke kan anvende Caremaker's allerede eksisterende klasser, må jeg oprette mine egne, samt opsætte en database. Dette vil være for prototypens demonstrations formål. Lave Media Queries - Opsætte Media Queries i min CSS for at lave siden responsiv til i hvert fald Iphone. 10

Mockups Under selve praktikken har jeg sammen med andre i Caremaker været med til, at fin pudse deres nye layout. Jeg har dog haft en smule frihed til at ændre på noget af layoutet efterfølgende. 11

Klasse diagram og domæne model Ja jeg vidste jeg selv skulle arbejde med alle layers samt database fra bunden af, var det første jeg lavede et klasse diagram og en domæne model. Jeg bruger disse, som "blueprints" til at gøre selve udviklingen lettere. Jeg valgte at oprette dem, således de var i stand til at udføre de opgaver de skulle i selve prototypen og undlod derfor funktioner som bl.a. til at sende e-mails, analytics mv. Ved at opstille modellerne således har jeg nemt kunne se hvad jeg har skulle bruge når jeg har oprettet de forskellige klasser, samt da jeg skulle oprette min database. Man kan se i dette eksempel at en Donation altid vil være tilknyttet en Fundraiser, men at en fundraiser godt kan have 0 eller mange tilknyttet Donationer. 12

Systemudvikling Når man begynder på et projekt som dette, så findes der forskellige arbejdsmetoder, som man kan arbejde ud fra. Jeg vil først beskrive de forskellige metoder, hvorefter jeg vil beskrive hvordan og hvorfor jeg valgte at arbejde som jeg gjorde. Agile arbejdsmetode Når man arbejder agilt er man åben for ændringer og er derfor ikke så fastlåst i satte rammer for hvordan man skal arbejde og hvornår man skal hvad. Når man arbejder agilt er man "open to change" og man arbejder i sprints, hvor imod den traditionelle programmering, hvor der er meget stramme rammer og alt er delt ind i faser. Når man laver et projekt kan man anvende noget en model som hedder "Project Management Triangle". Denne trekant viser, hvordan man ved at ændre på en ting også skal ændre et andet sted for at få den til at passe. Det vil altså sige, hvis jeg skruer ned for prisen, ja så skal jeg også skrue ned for enten features (som er scope), eller tiden det tager at lave det, for gør man ikke det, så vil center stykket, altså kvaliteten, falde og den vil man jo gerne beholde. Så med denne trekant kan man se hvordan alt følges godt ad. Når der snakkes om sprints, så snakker man om inddelte tider hvor man arbejder og kunden kommer og ser processen af projektet. Det vil altså sige at man har måske et sprint på 2 uger, hvorefter kunden kommer og får et indblik og en idé om hvordan alt skrider frem og kan derfor således komme med feedback til projektet. Dette gør at kunden meget lettere kan få det produkt som netop han/hun vil have. 13

Agil programmering har følgende værdier: Reager på ændringer og følg ikke en plan Funktionel software i stedet for omfattende dokumentation Samarbejde med kunden i stedet for fastlåst kontrakt Individualitet og interaktion Den agile arbejdsmetode har flere udviklingsprocessor og herunder vil jeg beskrive nogle af dem. XP XP, som er kort for extreme Programming, er mest til at forbedre software kvalitet, da der nemt kan ske ændringer for at tilfredsstille en kundes behov. XP har udviklet et sæt regler som man skal overholde og de er som følgende: Par programmering Omfattende kode gennemgang Man SKAL teste! Ingen overflødig kodning (altså ikke lav metode i tilfælde af de kunne blive brugbar senere) Enkelthed og klarhed i koden Vær klar på ændringer hvis behovet skulle opstå Hyppig kommunikation med kunden og programmørerne Scrum Scrum har 3 grundlæggende principper som består af: tydeligt fremskridt, at der bliver tilpasset som projektet skrider frem og at man har kontrollen over projektet hele vejen. Det vil altså sige at man lægger ikke så meget vægt på funktionalitet i forhold til design delen. Det vil altså sige, at skulle man lave en hjemmeside, så vil man ofte se store ændringer på selve 14

layoutet men ikke så meget på selve ting som for eksempel login system eller database. Dette vil komme senere og man vil derfor se flest ændringer i starten af projektet. Når man arbejder med Scrum, så arbejder man i et team hvor man har forskellige roller. Disse roller består af: Scrum master - Denne person virker som en "vagthund" for teamet. Scrum master sørger for at organiserer ting, sørger for der ikke er forstyrrelser for sit team og bestemmer hvornår der skal ændres på ting. Productowner - Dette er en kunde eller en fra kundens firma, som ved hvilken funktioner et produkt skal have og bestemmer derfor også hvilken funktioner man skal vægte højest under programmeringen. Udviklingsteamet - Dette team skal sammen blive enige om hvor lang tid der skal sættes af til hver story. Når man arbejder med et sprint arbejder man med et sat antal stories af gangen. Disse stories udarbejdes i samarbejde og bliver sat i en productbacklog. Når man arbejder med en story så skal den færdiggøres inden man tager hul på en ny. Dette gør at man ikke efterlader noget halvt færdigt og begynder på nye ting. Kanban I forhold til Scrum så giver Kanban mere løse tøjler til udviklerne. I kanban er der 3 regler: Visuelt workflow ved brug af taskboard eller Kanban-board. Gør brug af WIP-grænser for at forhindre flaskehalse. Giv tasks en tid det tager at gennemføre den. Når man laver en WIP er det i starten bare et estimat der skal give idé om hvor længe en task vil tage. Desto mere erfaring man får, desto bedre et estimat vil man kunne lave. Ved at lave disse estimerede tider, ja så sørger man for at man ikke har for mange tasks i gang på samme tid, som man ikke kan nå. 15

Når man arbejder med task-board skal man beslutte sig for hvor mange tasks der må være på de forskellige pladser på boarded. Nedenfor er et eksempel på hvordan sådan et board kunne se ud. Det vil altså sige, at der må være 3 under analysis, 5 under development, 3 under test og 5 under deploy. UP I UP, som står for Unified Process, arbejdes der i faser og meget lineært. Disse faser er meget faste og kan derfor ikke ændres. Det vil også sige at der ikke kan komme ændringer i noget hvis fasen allerede er slut. Faserne tages i en bestemt rækkefølge som er følgende: Inception Elaboration Construction Transition Deployment 16

Inception - Dette er fasen man først finder ud af hvad et system kræver. Man laver mockups samt cost/benefit analyse og featureliste. Man for sig altså her en idé om hvordan projektet skal se ud. Elaboration - I denne fase laves der use case og man bestemmer hvilken arkitektur systemet skal have. Construction - Man udarbejder i denne fase systemet ud fra hvad man fastlagde i fase 2, altså Elaboration fasen. Man benytter her iterationer for alle use cases, som man færdiggøre inden en sat tid. Transition - Dette er fasen hvor man tester om systemet opfylder sine krav. Man laver to forskellige tests, den ene er systemtest og den anden accepttest. Systemtest tester om selve systemet er stabilt og accepttest er som det lyder, om den acceptabelt lever op til alle krav som er stillet af kunden. Deployment - Systemet bliver udgivet for kunden. Traditionel mod Agil Efter at have gennemgået nogle af de forskellige arbejdsmetoder, hvad er forskellen så? Når du arbejder Agilt er du meget mere fleksibel i forhold til den Traditionelle arbejdsmetode. Det er let for kunden at komme med ændringer da der nemt og ofte er kontakt mellem kunde og udviklingsteamet. Når der arbejdes Traditionelt, så kan kunden ikke komme med ændringer efter fase 2 er afsluttet. Et godt eksempel på hvornår den Agile arbejdsmetode er bedst ville være som at lave en hjemmeside, som jeg bl.a prøvede hos Caremaker, hvor der RIGTIG ofte skulle foretages ændringer, om så det var en farve eller noget som skulle være 10 pixels mindre. Der var ofte ændringer her og der. 17

Boehm For bedre at kunne forstå hvordan man vælger en metode som passer til sit projekt og team, så er der lavet et diagram ved navn Boehm. Boehms Diagram tager 5 ting i betragtning når man skal finde sin arbejdsmetode og de er som følgende: Størrelse på sit team Hvor kritisk en fejl ville være skulle den opstå og hvad tabet er Dynamik i omgivelser Udviklererfaring Kultur, altså om man arbejder i et kaotisk eller regelsat miljø På dette billede kan man se hvordan dette diagram er opbygget. 18

For at beskrive hvordan jeg udfylder dette for min opgave så vil jeg sige at: Size - Meget tæt midten da jeg er alene om mit projekt Criticality - Tæt på midten da jeg ikke har med login systemet at gøre og jeg arbejder med egen server. Culture - Jeg er alene og arbejder derfor meget frit, så igen tæt midten. Personnel - Der jeg stadig ikke har den store erfaring vil jeg sætte denne ude mod kanten Dynamism - Næsten helt inde i midten da jeg uploader ofte og ændre ofte under programmeringen for at få siden til at se ud som jeg vil. Ved at se på Boehm's diagram kan man derfor se at den bedste arbejdsmetode for mig er Agil, da jeg hovedsageligt ligger inde ved midten. Arbejdsprocessen Da jeg valgte at arbejde Agilt har jeg også valgt at tage brug af Kanban's task-board. Jeg har her brugt gule post it, som jeg har sat op på min væg. Grunden til mit valg af task-board er, at jeg syntes det giver mig et mere overskueligt billede over hvad jeg er i gang med, hvad jeg skal have lavet, hvad jeg har lavet og ikke mindst holde orden så jeg ikke springer for meget rundt i min programmering. For mig har det klart været en fordel at bruge task-boarded så jeg har kunne holde fokus på hvad der skulle laves. For at stille fordele op mod ulemper kan man sige at: Fordele Nemt at holde styr og overblik over hvad man laver. Man kommer ikke til at tage hul på for meget på en gang. Der er ingen deadline som sådan og man føler derfor ikke tids press. 19

Ulemper Man kan ikke rigtig vurdere hvornår man er færdig med projektet. Man ved ikke helt hvor længe hver opgave vil tage. Jeg valgte at arbejde med Kanban's task-board og ikke backlog fra Scrum, da jeg følte det uoverskueligt at gøre alene. Jeg følte ikke jeg ville være god nok til at arbejde i sprints alene og kan godt lide at have lidt mere fri hænder. Jeg følte jeg hvis jeg brugte backlog, så ville jeg blive stresset og sikkert ofte tids presset eller også ville det være omvendt og at jeg satte for meget tid af til hvert sprint fordi jeg ikke ville tro at jeg kunne nå det før. Arkitektur I dette projekt har jeg skulle arbejde med MVC (Model-View-Controller). MVC kan sammenlignes med 3 lags arkitekturen, som jeg benyttede i java programmeringen i løbet af første semester, dog er den ikke helt så lineær. I 3 lags arkitekturen går kommunikationen lige ned og op gennem lagene, men i MVC må et view layer gerne trække informationer direkte fra data layeret. Responsivt design Et responsivt design (RWD), er en måde hvorpå et webudvikler kan give brugeren den mest optimale oplevelse når man ser på et website. Det skal være nemt at læse og navigere rundt på siden og siden skal passe til den enhed man ser på den fra. Det vil altså sige ikke noget resizing og scrolling. Når der tales responsivt design mener man de 3 følgende ting: Flydende layout, som kalder og resizer elementer. Det vil altså sige procent baseret i stedet for absolutte værdier. Fleksible billeder som også tilpasser sig enhedens størelse. 20

Brug af media queries til at definere hvilken CSS der skal bruges ved givende enheds størrelse. Hvorfor Media Queries? Man ser ofte hvis man går ind på en hjemmeside på sin mobil, at den begynder at load og så giver den et blink og ændres fra "http://example.com" til "http://m.example.com". Dette skyldes at i stedet for brug af Media Queries, så begynder telefonen at load deres normale website, som så har en device detection på der opdager at du er på en telefon. Herefter bliver du omdirigeret til en helt anden hjemmeside specielt lavet til mobil enheder. Det er sandt at 2 separate hjemmesider sikre at de er som du vil have dem til både computer og Mobil, men man kan opnå samme effekt via Media Queries og det giver mindre loading tid og man spare en masse plads på sin server. Endnu en ulempe ved at have device detection er, at der kan opstå fejl hvor din mobil ikke sender opgiver at det rent faktisk er en telefon og du modtager derfor den normale website til computere. Her ses en media query for iphone. Den fortæller at hvis websitet ses på en iphone skal den ikke vise elementet med id menu hvis det har data-display="0" dog skal den vises hvis den er sat til 1. Derudover sætter den en listes elementer til at være 100% af skærmens brede og til sidst sættes den til at vise et element med id'et burgermenu. 21

Kode Jeg vil herunder vise lidt af PHP koden som jeg har lavet for at kunne hente nogle af de forskellige informationer fra min database. Jeg vil vise hvordan jeg bruger metoden getalldonations() og hvordan den i samarbejde med Users modellen får strikket et array af alle donationer sammen til et Fundraiser objekt. I min kode bruger jeg PDO som er PHP's Data Objects, som giver metoder og prepared statements og så virker det med objekter. PDO siges også at være mere sikkert og bør bruges når man arbejder med PHP. Jeg passer først min connection med som parameter når jeg kalder getalldonations. Jeg laver så et nyt array, samt en variable med min SQL string. Jeg har herefter lavet et foreach loop som fortsætter så længe der findes noget data i min query som jeg har kørt. Alt data bliver smidt i $row som er et array. Inde i mit foreach loop laver jeg så hver gang en ny User og kalder funktionen selectuserbyid og passer uid med som jeg har fået fra databasen. Et nyt Donation objekt bliver lavet hvor jeg kalder funktionen createdonation og passer her i $donator, som er er det fulde navn på donatoren, samt beløbet, som er blevet doneret. Til slut tilføjer jeg det færdige donation objekt til en array. Når loopet afsluttet returneres donations arrayet. 22

På dette billede ses hvordan jeg henter en bruger via id. Denne metode blev kaldt i getalldonations, for at få fat i et bruger objekt og tilknytte det til Donation objektet. Da jeg kun skal bruge en enkelt bruger og en brugers id er unikt er det ingen grund til foreach loopet og jeg bruger der for bare PDO's prepare, execute og fetch. Dernæst kalder jeg metoden $createuser og passer dataen fra databasen. I createuser bliver der skabt et nyt user objekt og alle variablerne bliver sat til deres værdier. Til slut returner jeg så det nye user objekt. 23

Konklusion Under forløbet har jeg arbejdet alene for at skabe en ny visuel identitet til Caremaker. Da jeg følte at dette ikke var nok at vise, var det blot en af grundende til at jeg valgt ikke at arbejde med Caremaker's egne servers og deres egne php klasser, samt connection klasser. Jeg har arbejdet med opsætning af database, fået lavet en connection mellem min side og min database, samt arbejdet med at oprette PHP klasser og controllers. Jeg har også arbejdet med HTML og CSS, hvor jeg har skulle oprette media queries. Jeg har anvendt media queries til at lave hjemmesiden responsiv så den har kunne tilpasse sig alt efter hvilken enhed man kigger fra. Jeg har arbejdet med Kanban's task-board og anvendt en blandet arbejdsmetode ud fra Scrum og XP. Efter forløbet er slut har jeg kunne konstaterer at det er meget udfordrerne at arbejde ensom og at man for det første skal have et rigtig godt overblik, samt selvdisciplin. Som man får mere erfaring vil jeg mene at man kan opnå meget mere af begge ting, da et manglende overblink som regel fører til rod og derved mist af motivation. Det manglende overblik har også fået mig ud på sidespor af og til og jeg har måske brugt alt for meget tid på nogen ting i forhold til andre. Ofte har jeg haft svaret på et problem lige foran næsen og har brugt lang tid hvor jeg har overset det og jeg vil mene at hvis man arbejder som gruppe har man nemmere ved hurtigt at løse disse problemer. jeg kan konkludere at mit praktik forløb lærte mig meget og jeg har gjort rigtig god brug af det jeg lærte der. Udover det kan jeg også konkludere at jeg er i stand til at få en idé i hånden til et design og bringe det til live. Ved hjælp af det nye layout kan brugerne nu få et meget bedre overblik over websitet på andre enheder end computeren, men også få et meget mere clean design på alle enheder, også computer. Vedligeholdelse af siden vil nu blive meget nemmere da der ikke vil være funktioner på over 200 linjer og koden ikke er opbygget i et CMS. 24

Perspektivering Jeg kan konkludere at jeg har lært noget gennem dette projekt, dog har jeg ikke nået alt hvad jeg ville. Jeg har haft mangel på overblik, som måske kunne havde været forhindret ved at bruge mere tid på måske Scrum og uddybe mine modeller mere. Jeg har haft rigtig mange problemer i løbet af mit afgangsprojekt og har på mange måde svigtet mig selv i løbet af dette forløb, da jeg har ladt ting i det private gå mig på og det er gået udover min arbejdsindsats. Jeg har ofte haft ting hvor jeg ikke har kunne beslutte mig for hvordan jeg skulle håndtere et problem og har derfor brugt alt for lang tid på at research de mange forskellige måder man kan opnå samme resultat. Nu da projektet er afsluttet vil jeg sige, at jeg er glad for hvad jeg har nået, dog ville jeg ønske at jeg ikke havde haft de problemer og lavet de fejl som jeg har. 25

Kildehenvisninger http://php.net/manual/en/ http://www.w3schools.com/ http://code.tutsplus.com/tutorials/why-you-should-be-using-phps-pdo-for-database-access-- net-12059 http://stephen.io/mediaqueries/#iphone http://www.sitepoint.com/the-mvc-pattern-and-php-1/ http://stackoverflow.com/ http://dev.mysql.com/doc/refman/5.6/en/ 26