Interaktionsudvikling

Projektopgave 3: Interaktionsudvikling CPH business, klasse: MulA2013 Projektansvarlige undervisere Thomas Hartmann MereteGeldermann lützen: Projekt produkt url: www.amalieardahl.dk/projekt3/index.html Gruppemedlemmer: Amalie Ardahl Skøtt Portfolio url: www.amalieardahl.dk Sofie Rough Jensen Portfolio url: http://mul37.itkn.dk/portfolio/sofiesportfolio.html Gitte Skogstad Portfolio url: http://www.mul12.itkn.dk/eksamensprojekt/html/praesentation.html

Indholdsfortegnelse Problemformulering:....................................................... 3 Hovedspørgsmål:............................................................ 3 Problemstillinger:........................................................... 3 Metode:........................................................................ 3 Analyse af tekniske udfordringer:...................................... 3 PHP og MySQL:............................................................... 3 Javascript:.................................................................... 3 Responsive design:......................................................... 3 HTML-formularer til registrering....................................... 3 Analyse af planlægning af projektet:................................. 4 Test-scenarier:............................................................... 4 Dokumentation af processen............................................ 4 Dokumentation af koden.................................................. 6 Javascript:.................................................................... 6 PHP:............................................................................ 8 Estimeret arbejdspaln, Ganttkort...................................... 9 Redigeret arbejdsplan, Ganttkort..................................... 9 Fejlkilder og refleksion.................................................. 10 Konklusion:..................................................................10

2. Semester Projekt 3 Interaktionsudvikling Problemformulering: Cupcake & Co bloggen mangler elementer, der inddrager brugeren som et aktivt led i en dynamisk og interaktionsvenlig side, da det skal være muligt at registrere sig som bruger og dele sine opskrifter. Der udover skal det være muligt for brugeren at benytte Cupcake & Co websitet på flere forskellige enheder ved hjælp af responsive design. Hovedspørgsmål: Hvordan gør vi sitet mere interaktionsvenligt for brugerne? Problemstillinger: Hvordan gør vi det muligt for brugeren at registrere sig på sitet? Hvordan gør vi det muligt at dele opskrifter mellem brugere? På hvilken måde kan vi tjekke at de oplysninger, vi får fra brugerne ved registrering, at de er valide? Metode: For at løse vores problemstillinger og svare på vores problemformulering, har vi tænkt os at benytte PHP, Javascript samt HTML5 og CSS3. Til at strukturere arbejdsprocessen i dette projekt, har vi valgt at udarbejde Ganttkort, der demonstrerer vores tidsestimat, både før, under og efter projektet. Analyse af tekniske udfordringer: PHP og MySQL: Vores tidsestimat af PHP og MySQL i dette projekt: 12-17 timer. Begrundelse for tidsestimat: Da vi kun har haft ganske få gange til at lære PHP og MySQL, som begge er helt nye syntaxer for os, da vi før kun har beskæftiget os med markup language (HTML), og meget lidt Javascript. Vi synes alle tre i gruppen, at det er svært, så vi forventes at bruge omkring 12-17 timer på udelukkende at få PHP og MySQL til at virke på vores side. Javascript: Vores tidsestimat af Javascript i dette projekt: 20-25 timer. Begrundelse for tidsestimat: Javascript er et programmeringssprog, som forekommer alle i gruppen ret uforståeligt, svært og ikke særligt lige til. Forståelsen af Javascript er noget, som vi har arbejdet mere intenst på under projektet samt i skolen, og det har taget rigtigt meget tid. Vi har ikke før arbejdet med Javascript ved formularvalidering, og det indebærer en hel del nye ting, såsom Regular Expressions (RegEx), funktioner der kalder andre funktioner og ikke mindst.onblur,.onfocus og.onsubmit. Som nævnt tidligere har vi kun kort beskæftiget os med Javascript på 1. semester (hvilket primært var forståelse for if/else statements), ellers har vores fokus ligget på HTML og CSS, hvis syntax vi finder langt nemmere at forstå og bruge. Responsive design: Vores tidsestimat af implementing af responsive design: 10-15 timer. Begrundelse for tidsestimat: Vi har arbejdet ganske lidt med responsive design på første semester, og har siden hen haft en enkel undervisningsdag til at lære det. Det forekommer os stadig lidt kompliceret, og derfor har vi estimeret, at udvikling af to nye stylesheets til tablet og mobil kommer til at tage omkring 10-15 timer. HTML-formularer til registrering Tidsestimat af udvikling af formularer: 3 timer Begrundelse for tidsestimat: Vi har en god 3 Interaktionsudvikling

basisviden om HTML5 som gør, at vi er ret skarpe til at kunne lave formularer. Det er ikke en post, vi regner med at bruge lang tid på, da vi allerede har styr på, hvordan man koder og styler dem. Analyse af planlægning af projektet: Vi har estimeret tidsforbrug af de største tekniske udfordringer, og derved har vi en ide af, hvordan vi skal strukturere vores projekt. Vi har valgt at lave Ganttkort til at demonstrere vores projektplanlægning, da fordelen ved Test-scenarier: 1. En bruger skal kunne registrere sig korrekt. 2. En bruger skal forsøge at registrere sig som bruger men få en fejlmeddelelse, som skyldes forkert indtastning 3. En bruger skal kunne registrere og oprette en opskrift korrekt og få en opskrift med brugernavn på som afsender. 4. En person skal forsøge at registrere en opskrift uden at være bruger, og få en fyldestgørende fejlmeddelelse. 5. En bruger åbner en opskrift ved at trykke på en titel i modulet for visning af opskrifterne og skal kunne læse en hel opskrift hentet fra databasen. Ganttkort er, at det viser hvor mange dage, man regner med, at en given opgave vil forløbe sig over. Vi har stadig været meget usikre på, hvor lang tid, hver teknisk del vil tage, så derfor er Ganttkort den bedste måde for os, at illustrere vores projektplanlægning på så vi ikke hænger os i timeantal, men antal af dage i stedet for. Vores endelige produkt er færdigt når følgende test-scenarier er testet og dokumenteret med positive resultater. og registrerer, at email string ikke indeholder de betingelser vi har stillet den. Testperson synes det er let at registrere sig men bemærker ved samme lejlighed at han ikke kan skrive to navne i navnefeltet, fordi vores string ikke indeholder mellemrum. Derfor kan han ikke registrere sig som bruger da den vil blive ved med at give fejlmeddelelse medmindre han sletter et af navnene. Dette er herefter blevet rettet ved at sætte mellemrum ind i string. Da dette var rettet, var der ingen problemer med at oprette sig som bruger og dette lykkedes fint. Dokumentation af processen Registreringsmodulerne og visningsmodulet er bakket op af test foretaget af en udefrakommende som ikke har haft tidligere kendskab til projektet og hjemmesiden. Her fik personen til opgave at løse opgaver i tråd med test scenarierne, forklaret tidligere oppe i rapporten, på sitet for at teste hvordan modulerne fungerer i praksis. Billede 1: Her får testpersonen til opgave at skrive en forkert email sådan, at fejlmeddelelsen dukker op når han forlader feltet. Dette fungerer fint og upåklageligt. Han klikker ud af feltet, hvilket resulterer i at javascriptvalideringen tager over 4 Interaktionsudvikling

Testpersonen bed mærke i at det indtastede password ikke var censureret. Dette ville vi gerne imødekomme hvilket vil resultere i en lettere forståelse af platformen, da det bliver mere genkendeligt. Vi har efterfølgende ændret registreringen så denne funktion nu gælder. Dette ses på nedenstående billede. Testpersonen synes at felterne er stillet op i en fornuftig rækkefølge der virker genkendeligt og overskueligt at udfylde. Han afslutter registreringen ved at trykke registrer mig nu!. har vi sat en betingelse i vores string så brugeren minimum skal skrive 20 tegn i dette felt. I ovenstående billede ses det at vi oplyser brugeren på forhånd om denne betingelse, således at en fejlmeddelelse i de fleste gange vil være unødvendig og derfor godt for brugeren. Registreringen er nu gennemført og denne lille tekst dukker op på blank side: du er nu registreret. Kort og præcis tekst der lader brugeren vide at han/hun nu har en bruger. Ved nedenstående billede har vi bedt testpersonen om at klikke ud af et tomt fremgangsmådefelt for at teste om fejlmeddelelsen kommer frem. Det kan vi konkludere at den gør og dette sker fordi vi har sat en betingelse ind i den string der gælder for dette felt. Der skal være minimum 20 tegn hvilket betyder at hvis der er skrevet 19 eller mindre tegn vil denne fejlmeddelelse dukke op fremhævet med rød skrift for at fremhæve det for brugeren. Billede: opskrift undladt fremgangsmåde.png I opskriftregistreringsmodulet har vi fokuseret på at brugeren blev opmærksom hvis han/hun glemmer at udfylde nogle af felterne eller vil springe over. For at få så ensrettede opskrifter er det vigtigt at alle felter er udfyldt og at der er skrevet rigeligt i fremgangsmådefeltet. Derfor 5 Interaktionsudvikling

Testpersonen har let ved at oprette en opskrift og udfylde felterne. Hele processen forløber uden problemer og han registrerer den ved at trykke på knappen med teksten: del min opskrift!. Dokumentation af koden Javascript: Eksempel 1 fra reciperegistration2.js: 1. usernamefield.onblur = function(){ 2. checklogininfo(usernamefield); 3. }; Her er et eksempel på en onblur funktion. Onblur gør, at når man klikker ud af et felt, eksekverer den en funktion. Funktionen i denne er den, der hedder checklogininfo(usernamefield); som I kan se lidt længere nede i koden. Lad mig gøre det enkelt, at vise funktionen lige her: Billede: registrering af opskrift Opskriften er nu registreret hvilket ses tydeligt på ovenstående billede hvor bekræftelsen er kommet frem. Testpersonen er ikke i tvivl om at hans opskrift er registreret og går han tilbage er det nu muligt for ham at se opskriften i visningsmodulet og åbne den. Dette betyder altså at vores moduler virker. Der er enkelte steder hvor testpersonen bemærker småfejl fx ingen censur ved password. Dette er nu opdateret som det også fremgår af billederne. Derfor kan vi konkludere at testene er forløbet planmæssigt og effektivt. 1. checklogininfo = function(element){ 2. var loginstring = /^[A-ZazÆØÅæøå0-9]{1,20}$/; 3. var str = element.value; 4. if(str.match(loginstring)){ 5. return true; 6. } 7. else{ 8. element.value = Skal udfyldes, max 20 tegn ; 9. element.style.color = red ; 10. return false; 11. } 12. }; Parametret er angivet i den øverste funktion, så hver gang der står element, skal det byttes ud med usernamefield. På linje 1 skriver vi, at det er en funktion, så browseren ved, hvordan den skal læse koden. I linje 2 og 3 angiver vi to lokale variabler, vi skal bruge i denne funktion. Den første er loginstring, som vi putter en RegEx ned i, og den anden er for at korte koden lidt ned her sætter vi blot værdien af vores element (parametret, som er lig vores usernamefield), ned i en variabel, der hedder str (forkortelse for string). På linje 4 skriver vi, at hvis vores variabel 6 Interaktionsudvikling

str matcher værdien af loginstring, skal den returnere værdien sandt. Hvis der er fejl i den værdi, brugeren har puttet i str (altså værdien af elementet, som er et felt), skal den give element.value en tekststreng som fejlmeddelelse. For at brugeren også kan se, at det er en fejlmeddelelse, giver vi den farven rød, så usabilitien bliver bedre. Sidst men ikke mindst, er det vigtigt at den returnerer værdien falsk, for at sige, at vi ikke ønsker den værdi, brugeren har indtastet. Eksempel 2 fra userregistration2.js: 1. passwordfield.onblur = function (){ 2. checkpasswordinfo(passwordfield); 3. }; Denne funktion er der sådan set ikke noget nyt i, da det er stort set identisk i forhold til eksempel 1. Det, der adskiller sig lidt fra eksempel 1 er, at det er et password felt, så det gør, at den ikke kan skrive en fejlmeddelelse i feltet, da denne blot vil blive sløret, og derfor ulæselig. Det er blevet løst på nedenstående måde: 1. checkpasswordinfo = function(element){ 2. var loginstring = /^[A-ZazÆØÅæøå0-9]{1,20}$/; 3. var str = element.value; 4. if(str.match(loginstring)){ 5. return true; 6. } 7. else{ 8. alert( Password skal udfyldes! ); 9. return false; 10. } 11. }; Igen er der ikke meget nyt i koden i forhold til eksempel 1, men der hvor den adskiller sig, er måden hvorpå den giver brugeren besked om, at feltet ikke er udfyldt korrekt. I stedet for at sætte else statementet til at printe en besked i feltet (for det vil brugeren ikke kunne se, pga passwordsløring), så har vi valgt at give den en pop-up box, som giver fejlmeddelelsen. Eksempel 3 fra reciperegistration2.js: 1. recipeform.onsubmit = function (){ 2. var result1 = checkrecipenamefield( recipenamefield); 3. var result2 = checkingrediensfield(in gredienslistfield); 4. var result3 = checkinstructionsfield(i nstructionsfield); 5. var result4 = checklogininfo(usernamefield); 6. if(result1 && result2 && result3 && result4){ 7. return true; 8. else{ 9. alert( Der er fejl i felterne ); 10. return false; 11. } 12. }; Denne funktion styrer, hvad der sker når man trykker på submit for at sende data fra en formular. Vi har puttet funktionerne ned i variable, og alle variablerne vil vi gerne tjekke for at være sande. På linje 2-5 ser I variablerne, der er tale om. For at tjekke om de er sande, skal de returnere værdien true, så formen submittes. På linje 6 og 7 siger koden, at hvis vores result1-4 returnerer true, skal der ikke ske mere med formen, og så bliver den submittet. Hvis derimod at der er en af variablerne (fordi vores funktioner ligger i variabler) der returnerer værdien falsk (så kan den ikke være lig med true), skal den give en fejlmeddelelse i en pop-up box, og returnere værdien falsk, så formen ikke bliver submittet. Denne måde tjekker den alle felter, og sørger kun for at submitte og sende formen afsted, hvis alle felter er udfyldt korrekt. 7 Interaktionsudvikling

PHP: Eksempel 1 fra insertrecipe.php: 1. <?php 2. $con=mysqli_connect( amalieardahl. dk.mysql, amalieardahl_ dk, JSGgJPFd, amalieardahl_dk ); 3. $sql= INSERT INTO recipes (username, title, level, ingredienslist, instructions, specials) 4. VALUES 5. ( $_POST[username], $_ POST[title], $_POST[level], $_ POST[ingrediensList], $_ POST[instructions], $_POST[specials] ) ; 6. if (!mysqli_query($con,$sql)) 7. { 8. die( Afslutter scriptet. mysqli_ error($con)); 9. } 10. echo Opskriften er nu registreret ; 11. mysqli_close($con); 12.?> Her kan vi se, at vi åbner et PHP dokument i linje 1. I linje 2 laver vi en variabel, vi kalder for $con, som skal tjekke adgangen til databasen og forbinde med den, så vores data fra HTML en kan blive lagt ned i den. På linje 3 kan I se, at den finder ud af, hvor værdierne skal indsættes i vores database. INSERT INTO recipes siger, at den skal indsætte dataen i tabellen recipes, og herefter kommer navnene på vores rækker i databasen, hvor det bliver lagret. VALUES henter værdierne inde fra HTML-formularen, og poster dem i samme rækkefølge, som den hedder oppe i linje 3, først username, så title, level, ingredienslist osv. Hvis der ikke kan oprettes forbindelse til databasen eller hvis værdierne ikke kan postes (linje 6-9), giver den en fejlbesked og siger, at scriptet afsluttes. Hvis opskriften bliver lagt succesfuldt i databasen afsluttes der med en besked, der fortæller, at opskriften er registreret (linje 10). Linje 11 afslutter forbindelsen til databasen, og linje 12 afsluttes php en. 8 Interaktionsudvikling

Estimeret arbejdsplan, Ganttkort Ovenstående billede viser udkastet til vores Ganttkort, inden vi gik i gang med projektet. Det bliver løbende opdateret i løbet af projektperioden, så vi hele tiden er klar over, hvor langt vi er med projektets opgaver samt har styr på vores tidsplan. Nogle af opgaverne vil formentlig tage længere eller kortere tid end forventet. Redigeret arbejdsplan, Ganttkort Ud fra dette redigerede Ganttkort ses det, at vi har foretaget nogle tidsmæssige ændringer. Dette skyldes sygdom, som har resulteret i, at vi har måtte skubbe nogle af opgaverne længere hen i projektforløbet. Dette medfører en mere presset arbejdsproces, men forhåbentlig i en positiv retning, så der bliver arbejdet flere timer af gangen med det resultat, at vi er mere koncentrerede i vores arbejde. 9 Interaktionsudvikling

Fejlkilder og refleksion: I dette projekt har læring af nye kompetencer været topprioritet, da vi har arbejdet enormt meget med Javascript, som vi har haft begrænsede timer af, og med PHP som er et helt nyt programmeringssprog for os. Vi har været ramt rigtigt meget af sygdom og af et enkelt dødsfald, som har trukket processen ud. Hvis vi kunne gøre noget om, skulle vi have struktureret processen bedre, for at finde ud af præcist, hvad der skal laves, samt hvilke opgaver, vores færdigheder ikke er gode nok til at dække. Det kan ret nemt gøres ved hjælp Konklusion: af PWS og WBS, som giver et overblik over omfanget af opgaven. Vi har udarbejdet flere forskellige Javascriptfiler hen ad vejen, for at finde ud af, hvad der virkede bedst, og dermed synes vi, at vi har elimineret eventuelle fejlkilder i vores formularvalidering. Vi har gjort det muligt for brugeren at registrere sig på sitet og dele deres opskrifter ved hjælp af en formularer udarbejdet i HTML og CSS. Formularerne sender data videre til databasen (ved brug af PHP), hvor den bliver lagret. Ved at udvikle et visningsmodul til opskrifter, der ligger i databasen, har vi også skabt en platform for brugere, der gerne vil dele opskrifter med hinanden. På denne måde, har det været muligt for os at gøre sitet mere interaktivt for brugerne ikke nok med at de kan følge med og registrere sig på sitet, men de kan også dele med hinanden og være med til at bidrage. Formularerne er blevet valideret med Javascript, som giver en passende fejlmeddelelse, så risikoen for at få den forkerte eller manglende type data ned i databasen er lig nul. Meget af denne validering er lavet med regular expressions, som tjekker sammensætningen af tegn og tal i felterne. For at sikre, at valideringen af formularerne, har vi kørt en række test, som har været succesfulde i den forstand, at vores moduler virkede efter hensigten. 10 Interaktionsudvikling