Besøg: Projekt 3 på 2. Semester - MulB

Transkript

1 Besøg: Projekt 3 på 2. Semester - MulB Line K. Brinkmann Rasmus Bundgaard René Andersen Grace Tsatsaris Multimediedesign 2014 på CPH-Business

2 Indholdsfortegnelse Indledning... 3 Problemformulering... 3 Tekniske udfordringer... 4 Projektplan... 5 Testscenarier & User-stories Resultater af tests Design af registreringsmoduler Kodning Piktogrammer Responsive design Konklusion Side: 2

3 Indledning Lige meget hvor vi går hen, og hvad vi foretager os, så er vi omringet af det. Vi spørger det om vej, det hjælper os med at holde kontakten til nær og fjern, og selv vigtige informationer kan det give os. Internettet er kommet for at blive, og vores hverdag er i større og større grad påvirket af det. Vi køber ting via vores pc, læser bøger på ipad en og tjekker verdenssituationen på mobilen. Med andre ord har internettet, og derigennem de digitale medier, erstattet flere af de ting vi før brugte i hverdagen. Vækkeuret er byttet ud med mobiltelefonen og kogebogen med opskrifter på nettet. På en hjemmeside om cupcakes, skal det være muligt at finde opskrifter, og derudover kunne dele ud af egne erfaringer igennem brugerregistrering på hjemmesiden. Både når man sidder og hygger i sofaen med en cupcake i hånden, men også når man i bageprocessen finder på det sidste nye hit. Hensigten med Gracie s hjemmeside er, at inspirere brugeren og sikre sig online aktivitet, ved at brugerne kan inspirere hinanden. Sidstnævnte er udgangspunktet for vores projekt, hvor vi vil forsøge at beskrive hvordan man kan registrere sig på en hjemmeside, og derefter kan dele og finde opskrifter online. Med vores hjemmeside Gracie s i centrum vil vi vise et brugervenligt design, der giver vores brugere en positiv oplevelse, når de benytter hjemmesiden, ligemeget om de sidder med en pc, ipad eller mobiltelefon. Problemformulering: Hvordan gøres cupcake websitet funktionelt og dynamisk i forhold til bruger registrering og bruger interaktion? Og hvorledes sikrer vi at inputtet fra brugerne har den rigtige form? Side: 3

4 Tekniske udfordringer I projektet har vi valgt at fokusere på 3 forskellige bruger interaktioner. Disse er valgt, fordi vi mener, de er oplagte i forhold til hvad en blog om mad(cupcakes) bør kunne. For det første skal besøgende kunne oprettes som unik bruger, og derved logge ind på siden. Brugerne i databasen skal have genereret ID nummer automatisk og et timestamp for registreringstidspunktet. Modulet skal gøre brug af en HTML form, som indeholder forskellige typer af inputs, såsom radiobutton, text og selectbox. Sidst skal det, i tråd med ovenstående, være muligt at vise de oprettede opskrifter. Disse trækkes fra databasen, som skal være formateret, brugervenligt og have en designmæssigt tråd med resten af vores website. Vi stødte på en lille teknisk udfordring da vi fik til opgave at lave en serie piktogrammer, som navigationen til den lille skærmstørrelse. Men da vi allerede i projekt 2 havde lavet vores website responsiv, med en god funktionel navigationen til lille skærmstørrelse, har vi skulle tage nogle beslutninger om, hvad vi nu ville gøre i forhold til det nye website. For det andet skal besøgende kunne oprette/ tilføje opskrifter på siden, således at disse findes i databasen. Igen skal der her gøres brug af forskellige typer inputs fra en HTML form, som kan angive eksempelvis ingredienser og mængder. Hertil skal der også registreres hvilken bruger der opretter opskriften, via deres unikke brugeridentitet. Side: 4

5 Projektplan Gantt-chart Lavet ud fra hele gruppen, set som en helhed, og derfor er de enkelte opgaver ikke uddeligeret på gruppemedlemmer. Dette er gjort for at danne et overordnet overblik over hvilke opgaver vi, som gruppe, skal fokusere på først, og i hvilken rækkefølge vi vil forsøge at opnå vores mål. Work Breakdown Structure Se bilag 1. # Opgave Start Slut Varighed Uge Uge Man Tir Ons Tor Fre Man Tir Ons Tor Fre Projekt 3-2 semester Opgave formulering Planlæg projektet User story test scenarier Indledning Analyse Kodning PHP / DB Piktogrammer Den tekniske del af rapporten Test af koden Test af koden 2 / test scenarier Konklusion Aflevering Side: 5

6 Testscenarier & User-stories Testscenarier For at finde ud af om vores udviklede design af en webform, og samarbejdet mellem hjemmeside og server fungerer i virkeligheden, har vi opsat nogle test scenarier. Test scenarierne er udviklet med henblik på at løse bestemte opgaver, der i vores tilfælde går ud på at registrere sig som bruger af sitet, og efterfølgende kunne oprette en opskrift samt, at skrive kommentarer på egne og andres opskrifter. Det er vigtigt, at få forklaret hvad testen går ud på, så der ikke opstår nogen tvivl om resultatet i sidste ende. Dette kan gøres ved at benytte sig af user stories, der er små historier, som fortæller om en bestemt handling, og hvad der kan opstå af mulige problemer undervejs. Enten lykkes det brugeren at registrere sig, og modtage tilbagemeldingen - og er derved oprettet som bruger. Eller også mislykkes handlingen, hvilket kan skyldes flere forskellige scenarier. Et eller flere af felterne er ikke udfyldt. I dette tilfælde skal brugeren modtage en besked om fejlen, og derefter blive sendt tilbage til formen, så de kan forsøge igen. Der er fejl i adressen. Der skal og punktum med efterfølgende bogstaver. Også her vil brugeren modtage en fejlbesked og få mulighed for at forsøge igen. Test scenarie 1: Registrering af bruger på sitet: Brugeren går ind på siden, og ønsker at oprette sig som bruger, ved at registrere sig på hjemmesiden. Der kunne opstå en serverfejl. I dette tilfælde bør brugeren igen modtage en advarsel/forklaring på problemet, og blive sendt tilbage til formen. Hvis det muligt. Side: 6

7 Testscenarier & User-stories Test scenarie 2: Brugeren ønsker at logge ind på sitet: Brugeren er nu oprettet på sitet og ønsker nu, at logge ind med sit nye brugernavn og password. Igen findes der et positivt og et negativt output. Enten lykkes det brugeren at udfylde brugernavn og password korrekt, og der vises en besked om at du er korrekt logget ind. Eller også kan der opstå en fejl som ikke gør det muligt at udføre den ønskede handling: Brugernavn eller password er ikke korrekt. Brugeren får en forklaring på problemet og sendes derefter tilbage til formen igen. Side: 7

8 Testscenarier & User-stories Test scenarie 3: Brugeren ønsker at oprette en opskrift: Brugeren har nu brugernavn og er logget ind på sitet, og ønsker at oprette en opskrift. Igen forefindes to scenarier. Enten lykkes det brugeren at udfylde felterne i formen korrekt, og oprette de rigtige informationer, de rigtige steder. Eller også opstår der en fejl, som ikke gør det muligt, at udføre den ønskede handling. Dette kan, som i den før nævnte situation, skyldes forskellige scenarier: Et felt er ikke udfyldt. Her skal brugeren have en forklaring på problemet og derefter sendes tilbage til formen, med mulighed for at rette fejlen. Et felt er udfyldt med forkerte data, evt. tegn der ikke må indgå - igen skal brugeren have en forklaring, og sendes tilbage for at rette fejlen. Side: 8

9 Resultater af tests Brugeren registrerer sig på hjemmesiden: Brugeren går ind på siden, opretter sig som bruger, ved at registrere sig. Det lykkes brugeren at registrere sig, og modtager en tilbagemelding. Brugeren logger ind på sitet: Brugeren er allerede oprettet og logger ind med sit brugernavn og password. Det lykkes brugeren at udfylde brugernavn og password korrekt, og der vises en velkomst besked på brugerens egen side. Brugeren opretter en opskrift: Brugeren er logget ind på sitet og opretter en opskrift. Lykkes det brugeren at udfylde felterne i formen korrekt, vises der en meddelelse om at opskriften er oprettet. Handlingen mislykkes, hvilket kan skyldes flere forskellige scenarier: Et af felterne er ikke udfyldt korrekt, eller slet ikke udfyldt. I dette tilfælde modtager brugeren en besked om fejlen og bliver sendt tilbage til formen, for at forsøge igen. Der er fejl i adressen. Der indgår eller punktum med efterfølgende bogstaver. Brugeren modtager en fejlbesked og får mulighed for at forsøge igen. Mislykkes handlingen modtager brugeren en fejllbesked om at Brugernavn eller password ikke er korrekt. Hvis der er er fejl eller mangler i udfyldelsen af felterne får man en fejlbesked tilbage. Side: 9

10 Resultater af tests Mulighed for at kommentere: Ydermere har brugeren nu mulighed for, at kommentere på egne og andres opskrifter. Tanken bag denne funktion er, at gøre hjemmesiden mere levende med mere brugerinteraktion. Udsnit fra opskrift siden: Mulighed for at indtaste en kommentar efter, at brugeren er logget ind: Det kræver, at man er logget ind for, at kunne skrive en kommentar. Udsnit fra blog tabellen: Foreign key constrain mellem bruger og blog indlæg. Foreign key constrain mellem opskrift og blog indlæg. Side: 10

11 Design af registreringsmoduler Til bruger registreringen: Brugernavn: ens id, som udover at virke som login, også vises på brugerens egne opskrifter og kommentarindlæg. At vi har valgt brugernavn her i stedet for fornavn/efternavn, er for at gøre brugeren så anonym som muligt. Password: personlige adgangskode til login. bruges til kommunikation med brugeren, i form af nyhedsmail eller mistet password. Fornavn/Efternavn: bruges kun ved direkte kommunikation med brugeren. Køn/Alder: bruges til evt. statestik og målretning af nyhedsbreve. Bruger Login Brugernavn: det selvvalgte brugernavn, som man oprettede under registreringen. Password: det selvvalgte password, som man oprettede under registreringen. Oprettelse af opskrifter: Cupcake navn: fungerer som overskriften, og til evt. senere søgemulighed. Kort beskrivelse: (max 250 anslag): bruges som en teaser tekst for opskriften. Teksten placeres lige under opskriftens navn. Cupcake type: her bruger vi en selectbox, for at give brugeren faste valgmuligheder for hvilken kategori opskriften skal ligge under. Tilberedningstid: her bruger vi ligeledes en selectbox, da vi her ønsker, at man skal kunne kategorisere under på tidsforbrug. Temperatur: også her er der valgt en selectbox, for at forhindre at brugere skriver skæve tal. Alternativ kunne man lave en validering, som forhindrer brugeren i at skrive mere end 3-cifrede tal. Sværhedsgrad: her har vi opstillet 5 valgmuligheder som radiobuttons. Igen er meningen her, at man skal kunne søge og kategorisere opskrifterne efter sværhedsgrad. Ingredienser/Frosting ingredienser: almindelig tekstbox hvor ingredienser og mængde indskrives. Her er der ingen mulighed for kategorisering og søgning, da det er et fritekst felt. Fremgangsmåde: en almindelig tekstbox, hvor selve fremgangsmåden skrives i brugerens eget sprog. Billede: i dette felt indsættes link til billede i en specifik størrelse. Dette er ikke en optimal løsning, da det stiller for store tekniske krav til brugeren. En bedre løsning ville være at brugeren kan uploade et billede i en hvilken som helst opløsning, hvorefter billede automatisk skalerer til den specifikke størrelse. Timestamp: Databasen tager et timestamp ved oprettelse af bruger, opskrift og kommentar. Timestamp bliver brugt for, at vise hvornår en opskrift er oprettet samt dato for tilhørende kommentarer. Vi har valgt at sætte et timestamp for oprettelse af brugeren, for at senere kunne sende tilbud på årsdagen for medlemskabet etc. Side: 11

12 Kodning Udsnit fra opskrift.php hvor vi forbinder til databasen <?php session_start(); $message = ; $db = new mysqli( servername, username, password, databasename ); if ($db->connect_error) { $message = $db->connect_error; else { $sql = SELECT * FROM recipes WHERE recipe_id=. $db->real_escape_string($_get[ id ]);?> $result = $db->query($sql); if ($db->error) { $message = $db->error; else { $row = $result->fetch_assoc(); Tjekker om brugeren er logget ind Forbindelse til databasen Hvis ingen forbindelse udskriv fejl Vælg data fra tabellen recipes Hvis fejl, udskriv meddelelse Hent data fra tabellen Udsnit fra opret_bruger.php, hvor vi validerer de forskellige felter i formen <script> function validateform() { var x = document.forms[ userform ][ f_username ].value; if (x == null x == ) { Vælger form og felt til validering Tjekker om feltet er tomt Validering af brugernavn alert( Brugernavn skal udfyldes ); return false; Udskriver fejlmeddelelse var x = document.forms[ userform ][ f_ ].value; var atpos = ); var dotpos = x.lastindexof(. ); if (atpos < 1 dotpos < atpos + 2 dotpos + 2 >= x.length) { Vælger form og felt til validering Tjekker om der er Tjekker om der er et punktum i slutningen Minimum 2 anslag efter punktum Validering af </script> alert( adressen er forkert ); return false; Udskriver fejlmeddelelse Side: 12

13 Piktogrammer Som tidligere beskrevet, har vi haft lidt vanskeligheder ved at skulle implementere piktogrammer. Dette skyldes at vores design fra det tidligere projekt var lavet responsivt, med en menu på de mindste skærme som er let læselig og brugervenlig. Så at erstatte disse menupunkter med piktogrammer, frem for menuteksten, giver ikke meget mening i forhold til forståelse og brugervenligheden[1], som vi netop har valgt at sætte i højsædet i vores projekt. I vores oprindelige designproces overvejede vi, at bruge piktogrammer for at give designet et mere visuelt udtryk. Vi valgte det i sidste ende fra, for at kunne fokusere mere på andre, på det tidspunkt vigtigere funktioner. For at imødekomme kravene om at piktogrammer skal indgå på websitet, har vi valgt at oprette disse på opskriftsiden. Brugt på denne måde vil de give et hurtigt overblik for brugeren om bagetid, ovntemperatur og sværhedsgrad. Bagetid: Hertil har vi valgt at lave et piktogram om forestiller et stopur. Dette har en universal forståelse af, at man tager tiden på noget. Piktogrammet er enkelt udformet, uden brug af mange detaljer for at gøre det mere forståeligt på mindre skærme. Ovntemperatur: Her har vi valgt at tegne et termometer, da dette har en universel betydning for temperatur. Man kunne også have valgt at vise et piktogram af en ovn. Dette har vi bevidst fravalgt, da det let kan forveksles med bagetid. Sværhedsgrad: Vi bruger her et piktogram af en simpel skala, for at illustrere at man kan niveau inddele. Af de 3 piktogrammer vi har valgt at arbejde med, er dette klart den sværeste illustration, at gøre let genkendelig for brugeren. Umiddelbart er der intet universelt symbol/piktogram for det at niveau inddele, og folk vil let lave deres egen fortolkning af symbolet, og derfor i mange tilfælde misforstå det. Vi er endt på trindelingen da vi mener de fleste vil kunne tolke denne som niveauer. [1] Brugervenlighed og fleksibilitet fra 20 Designprincipper af Ian Wisler Poulsen Side: 13

14 Responsive Design Hvor, hvornår og hvordan vi tilgår internettet har ændret sig markant de seneste år. Efter tilgangen af smartphones og tablets er teknologien og internettet pludselig blevet meget mere bærbart, i forhold til den gang hvor laptoppen var vores eneste bærbare enhed. Med tilgangen af disse nye teknologier har vi også vænnet os til, at bruge skærme i en helt anden størrelse end vi tidligere har gjort. I vores design har vi derfor taget udgangspunkt i 3 størrelser skærme; Store skærme (desktop, laptop), tablets og smartphones. Vi har defineret dem således: <!-- Main CSS Styles--> <link rel= stylesheet type= text/css href= css/main.css /> <!-- CSS Large Screens --> <link rel= stylesheet type= text/css href= css/screen_layout_large.css /> <!-- Screen Size 50px - 500px use this --> <link rel= stylesheet type= text/css media= only screen and (min-width:50px) and (maxwidth:500px) href= css/screen_layout_small.css /> <!-- Screen Size 501px - 880px use this --> <link rel= stylesheet type= text/css media= only screen and (min-width:501px) and (maxwidth:880px) href= css/screen_layout_medium.css /> Store skærme: over 880px i bredden Tablets: mellem 500px og 880px i bredden Smartphones: under 500px i bredden Vi benytter os af et overordnet stylesheet, som vi kalder main.css. Dette styrer mange af de basale ting, såsom farver, skrifttype og størrelser. Desuden har vi lavet 3 separate stylesheets, som gør det muligt at flytte på indholdet alt efter skærmens størrelse og opløsning. For at sikre os at brugeren ser siden korrekt, benytter vi os queries, som henter det stylesheet som matcher enhedens opløsning. Side: 14

15 Konklusion Vi har i projektet lavet en hjemmeside, der fungerer i et responsivt design, hvilket gør det muligt for brugeren, at have siden med overalt i den mest optimale størrelse, med lettest tilgang til alle funktionerne. I stedet for en simpel registrering, hvor det er vigtigt for brugeren selv at huske sit id-nummer, har vi valgt at designe et login. Dette betyder, at når man først er logget ind som bruger, så vil siden huske en, og ens navn vil automatisk blive skrevet på de kommentarer, eller de opskrifter der uploades. Dette øger brugerens tilknytning til sitet, og giver mulighed for at interagere med andre brugere på siden. Vores login er designet i stil med resten af hjemmesiden, og gjort så simpelt og brugervenligt som muligt. at komme videre. Brugeren vil i stedet få en besked, der forklarer problemet på skærmen, og derefter mulighed for at prøve igen. Vi har arbejdet på at tilgodese den moderne bruger, som i dag benytter internettet til at finde opskrifter, og til at dele ud af egne erfaringer. Hensigten med Gracie s hjemmeside er, at inspirere brugeren og sikre sig online aktivitet, ved at brugerne kan inspirere hinanden. Og det mener vi at have opnået med projektet her. Kilder: Designprincipper af Ian Wisler Poulsen Inden man som bruger kan logge ind, skal man dog først oprette en profil. Dette gøres via registreringsformularen, som findes på hjemmesiden. For at sikre at inputtet fra brugeren har den rigtige form i vores registrering og log in, og at det fortsat er brugervenligt, har vi valgt at indsætte (javascript) validerig. Bliver et felt udfyldt forkert, eller mangler der decideret at blive udfyldt et, så er det ikke muligt Side: 15

16 Bilag: 1 Gracie s / Website Database Front-End udvikling Dokumentation Oprettelse Webform Problemformulering PHP Piktogrammer Test scenarier / User stories Test Validering Indledning Kodebeskrivelse Test resultater Konklusion

17 Bilag: 2