2. semester - 3. projekt Interaktionsudvikling - en fortsættelse af projekt 2 - CUPCAKES Mul B - Cphbusiness - 2014 Link til website: www.rikkecarlsen.com/ cupcakes/index.html Gruppe 7 Camilla Mia Poulsen Mads Emil Lindegaard Henriksen Sebastian Tramp Rikke Carlsen Portfolio: www.camillapoulsen.dk www.melh.dk www.sebastiantramp.dk www.rikkecarlsen.com
Indholdsfortegnelse Problemformulering...3 Proces...4 Dokumentation af koden...5 Dokumentation af test...7 JavaScript-validering - kode og designvalg...9 JavaScript-validering - test scenarie...10 Designvalg...12 Responsivt design...14 Ikoner til mobil løsning...15 Konklusion...16
Problemformulering Udgangspunkt: Kristine Bech har en blog om cupcakes, som vi har hjulpet hende med at gøre kommerciel med henblik på, at hun kan tjene penge på sin blog. Projekt: Kristine Bech vil nu gerne lade brugerne af sin blog kunne logge ind på siden og uploade og søge i opskrifterne. Som led i markedsføringen vil dette behjælpe, at brugerne føler sig inddraget og har en slags ejerskab/interesse på siden. flere platforme. Dette gøres ved hjælp af responsivt design, hvor især den mobile løsning er tilpasset brugerens behov fx ved hjælp af ikoner og mobilvenlig opsætning. En reel log-in-funktion er endnu ikke integreret på sitet. (Læs mere ) Men brugeren skal kunne registrere sig med henblik på at kunne uploade nye opskrifter til siden. Dette skal gøres ved hjælp af en database, så brugerne får et unikt id, som de kan bruge, når de uploader opskrifter, så de senere kan finde deres egne og andre brugeres opskrifter fx ved søgning på brugernavn. Derudover skal der opsættes en side til upload af opskrifter som taler direkte med databasen, hvorfra opskrifterne igen kan trækkes ud og vises for brugeren. Ydermere skal sitet have et brugervenligheds løft, som gør det muligt for brugeren at tilgå sitet fra Side 3 af 16
Proces For at skabe et overblik over vores arbejde har vi brudt projektet ned i mindre dele. Vi har benyttet Gantt-chart til at skabe overblik over processen, og for at sikre, at vi når alt inden deadline. Vi valgte at begynde det mest udfordrende sted i projektet: PHP og SQL, da database- området er et helt nyt felt for os, og dermed ville kræve mest arbejde. Vi har i så vid udstrækning, som muligt, siddet sammen og arbejdet med udformning af formularer, kodning og databaseopsætning. Gantt chart Vi har lagt tid ind i tidsplanen til test af vores løsninger, så vi er sikre på at vores site vil fungere så optimalt som muligt. Det gik løbende op for os at PHP- og databasearbejdet spillede en større rolle end vi havde påregnet. Det var væsentligt mere udfordrende for os end vi havde regnet med, idet der hele tiden kom komplikationer med f.eks. at få databaserne til at snakke sammen korrekt, og hente de rigtige data ned til brugeren. Der var mange funktioner, som vi ville have med, men som viste sig at være en del sværere at få implementeret - såsom at få en fejlmeddelelse hvis man manglede at udfylde et felt. Løsningen på dette var at få et JavaScript til at give en alert-meddelelse, hvis brugeren tastede forkert. Alt i alt er vi nået frem til en løsning, der med vores nuværende niveau og kvalifikationer lever op til problemformuleringen/kontrakten. Side 4 af 16
Dokumentation af koden Undervejs i kodningen af sitets interaktive dele har vi både lært en del og mødt et par udfordringer. I to af vores PHP dokumenter har vi gjort brug af POST funktionen, som opbevarer data som er blevet indtastet i en form der bruger en post metode. De førnævnte forme har derfor også en action der siger at informationen skal videresendes til et andet dokument. Altså bruges post funktionen til at passerer data fra en side til en anden her fra en HTML side til en PHP side. Herunder ses et eksempel på hvor vi har brugt post funktionen i vores brugerregistreringsform. Når data der er blevet indtastet i formen er blevet videresendt til PHP dokumentet, bruger vi SQL insert funktionen til at oprette en ny række i databasen. Herunder ses et eksempel på hvordan det data indsættes i tabellen ved navn registration, der har de navne på rækker man ser i første parentes. Derefter bestemmer values hvilke værdier der skal indsættes hvor i tabellen, der her kæder den information vi har fået fra førnævnte post funktion sammen med matchende value. To WHERE-krav i én En af de udfordringer, vi for eksempel stødte på, var, da vi ville have vist opskrifterne enkeltvis på en side sammen med brugernavnet på den person, som havde uploadet den. Først prøvede vi at lave to $sql select-sætninger, hvor vi i den ene ville hente al data på opskriften fra den ene tabel, og i den anden sætning ville vi hente brugernavnet fra den anden tabel i databasen. Dette virkede dog ikke, da vi sagtens kunne trække alle opskriftdata ud, men ikke brugernavnet - hvilket var vigtigt. Vi endte med at omskrive $sql select-sætningerne til én og samme sætning, ved at samle alle navnene på alle rækkerne fra opskrifttabellen og brugernavnet fra registreringstabellen. Disse data skulle vælges fra både registration - og recipeupload - tabellerne, som de hedder i databasen. Det viste sig at være den efterfølgende del af sætningen hvor WHERE træder i kraft at problemet lå, da vi oprindeligt ikke havde fået de to tabeller til at snakke sammen, men kun havde skrevet SELECT [ ] WHERE recipeid =.$recipeid. Det krævede altså to WHERE- krav for at vi kunne få vist brugernavnet sammen med opskriften, fordi vi skulle matche bruger-id et fra de to tabeller. Vi gjorde det ved at definere, at brugerid et fra registration-tabellen skulle være lig brugerid et fra recipeupload-tabellen, som kan ses herunder: Side 5 af 16
Printf Når man opretter sig som bruger får man id-nummer, som man skal bruge når man uploader opskrifter på siden. Dette nummer bliver automatisk genereret i databasen, da det er sat til auto increment, der betyder at den selv tæller og genererer et unikt id til brugerne. På den måde sikre vi os at to brugere ikke deler id, så deres opskrifter ikke bliver vist forkert. For at få vist dette id nummer for brugeren, har vi brugt printf ( %d, variabel) kommando, som kan ses herunder: Da vi har en timestamp række i begge tabeller i databasen, som fortæller henholdsvis hvornår brugeren er oprettet og hvornår opskriften er oprettet, har vi også defineret timestampet i første del af $sql sætningen fra recipeupload-tabellen på følgende måde: recipeupload.time, for at være sikre på, at det rigtige data trækkes ud. Vores userid er en INT i databasen, hvilket er vigtigt ved brug af denne kommando, da id et ellers ikke ville blive udskrevet korrekt. Når dokumentet vises i browseren vil %d\n blive erstattet af variablen, som her er id et, der er blevet genereret i databasen. Side 6 af 16
Dokumentation af test Oprette bruger, uploade opskrift og vise opskrift pr. bruger: For at sikre at vores kunde får en funktionel løsning til sit website, har vi gennemført test af sitets interaktive funktioner med bagrund i en userstory. Nu får brugeren sit brugernavn og sit brugerid oplyst, og kan nu gå videre til at uploade personlige opskrifter. Vores bruger vil gerne oprette sig som bruger for at uploade en opskrift og dernæst få vist denne. Brugeren klikker på Opret Bruger. Dernæst udfylder brugeren alle sine personlige data i formularen og klikker på Opret bruger : Brugeren kan nu uploade sin egen opskrift til sitet ved brug af sit personlige brugerid og brugernavn. Brugeren kan enten klikke på linket med det samme, eller benytte Upload opskift i højre menuen senere. Som løsningen fremstår nu, kan enhver bruger blot oprette en opskrift på et tilfældigt brugerid. Det er naturligvis meningen at der skal integreres en login-funktion på sitet, så brugerne udelukkende kan uploade opskrifter, når de er logget in. - Brugerid et skal dernæst generes automatisk på opskriften, så brugeren ikke behøver at huske dette. Side 7 af 16
Ved klik på Upload opskrift gemmes opskriften i databasen, og brugeren kan klikke videre for at se alle opskrifter. På Brugernes opskrifter kan brugeren finde opskrifter specifikt for de forskellige brugere registreret i databasen. Alle opskrifterne er desuden listet op i bunden, hvis brugeren blot vil se på overskrifterne selv. Lignende søge - eller sorterings -funktioner kan også tilføjes på denne side, så brugerne fx kan søge i opskrifter pr. kategori eller ingredienser. Vores bruger klikker på nu sit eget brugernavn i dropdown-menuen og klikker vælg : Nu kan brugeren se sine opskrifter og få dem vist på websitet. Side 8 af 16
JavaScript-validering - kode og designvalg Vores brugerregistreringsmodul og opskriftregistreringsmodul valideres vha. JavaScript. Fælles for alle input felter, undtagen nyhedsbrevs checkboxen i brugerregistrering, er at de alle sammen skal udfyldes for at de kan valideres, samt kun må indeholde et bestemt antal karakterer eller bestemt tegn. Herunder er et eksempel på koden fra fornavns feltet i brugerregistreringen. På linje 2 står der hvis det input med navnet firstname i formen med navnet myforms værdi er lig 0, valideres formen ikke og skal return false, som ses på linje 5. Da kommer en alert box, som ses på linje 3, med teksten Skriv venligst dit fornavn., hvorfra der bliver fokuseret på det felt der mangler information, som sker i koden på linje 4. både store og små samt bindestreg. Derudover må navnet ikke være kortere end to karaktere og ikke længere end 20 karaktere, som er defineret mellem de krøllede parenteser. Denne variabel har vi derefter brugt i den nedenstående kode, som siger på linje 2 at hvis den værdi der er indtastet i feltet ikke (!) matcher variablen reg_letters, valideres indholdet ikke og den skal retrun false. Herefter popper en alert box op der fortæller at navnet skal indeholde mellem 2-20 karakterer, og fokuserer efterfølgende på feltet der ikke er blevet valideret. Vi valgte ikke at bruge denne løsning, da beskeden ville overskrive den information man havde udfyldt og ikke give bruger mulighed for kun at rette der hvor der var fejl i stedet for at skulle skrive det hele igen. Derudover skulle input felterne være lige så lange som fejlbeskederne, for at man kan læse hele beskeden, hvilket ville blive endnu mere problematisk når man registrer sig som bruger eller uploader opskrifter på mindre skærme. Altså valgte vi at vise fejlbeskederne via alert box e, da det for det gør at bruger skal foretage en handling før bruger kan få lov til at gå videre på siden. På den måde bliver man i større grad gjort opmærksom på at der er noget der forhindre én i at indsende de indtastet informationer med fejl til databasen, og den focus funktion vi har tilføjet efterfølgende gør det nemmere at rette fejlen. Derudover må for- og efternavns feltet kun indeholde bogstaver. Her har vi defineret en variabel vi har kaldt reg_letters, som kan ses herunder. Denne variabel må indeholde bogstaverne a-å i Alternativt til alert box kunne vi have skrevet en fejlbesked i selve feltet hvor information ikke er udfyldt korrekt, enten hvis der er for mange eller få karaktere eller hvis der er brugt forkerte tegn. Ved at bruge onblur, ville beskeden komme frem i feltet, når man når man klikker væk fra det. Side 9 af 16
JavaScript-validering - test scenarie For at hjælpe brugere af sitet og sikre at vores databases tabeller bliver udfyldt korrekt har benyttet JavaScript-validering til vores formularer. Vi har to fomularer 1) registrering og 2) upload opskrift. I det følgende vil vi beskrive og eksmeplificere, hvordan valideringen fungerer for de to formularer vha. userscenarier. 1) Registrering Navn Sebastian forsøgte at skrive sit fornavn med tal, men oplysningerne sendes ikke videre til databasen, eftersom inputtet Fornavn og Efternavn kun acceptere bogstaver og mellemrum af 2-60 tegn (bl.a. pga. mellemnavne). mellemrum. Som alternativ kunne han skrive Sebastian-Tramp eller Sebastian_Tramp, og den ville dermed blive godkendt. Køn (& Region) Sebastian glemte at angive sit køn og derfor poppede en alertboks op, som fortalte, at han venligst skal vælge et køn. Samme koncept gælder ved valg af region. typiske format som emails har. Sucess! Efter at Sebastian har rettet de fejl han fik fortalt, lykkedes det for ham at oprette en bruger. Brugernavn Brugernavnet Sebastian Tramp blev ikke godkendt, eftersom brugernavnet ikke må indeholde Mail Sebastian var lidt for hurtigt på tasterne, og kom til at skrive 2 i stedet for et @. Heldigvis tjekker formen om det indtastede input følger det Side 10 af 16
Sebastian har nu oprettet sig som bruger, og er klar til at uploade sin første opskrift: 2) Upload opskrift BrugerID Sebastian har forvekslet brugerid med brugernavn, og skrev derfor Sebastian_Tramp. Han fik derfor en fejlboks, eftersom brugerid kun må bestå af 1-6 tal. Sucess! Efter at Sebastian har rettet de fejl han fik fortalt, lykkedes det for ham at uploade hans første opskrift. Fremgangsmåde Efter at Sebastian har indtastet ingredienserne, skal han nu til fremgangsmåden. Sebastian er meget sjusket med instruktionerne og vælger bare at skrive Bland. Det får han dog ikke lov til at uploade, eftersom at der mindst skal skrives 10 tegn. På den anden side kan han heller ikke skrive en roman, eftersom der max må indtastes 3000 tegn. Side 11 af 16
Designvalg I vores projektløsning har vi foretaget en række tilog fravalg i opsætningen af databaser, formularer og output. Skal vores kunde fx til Aarhus og afholde kursus, kan hun promovere sig pr. e-mail til sine brugere i Midtjylland. regions-dropdown funktionen er placeret for sig selv. Formularer Når brugeren skal registrere sig sker dette ved at opgive fornavn, efternavn, e-mail, køn og hvilken region brugeren kommer fra. Derudover skal bruger opgive et brugernavn, som skal bruges når der skal uploades og vises opskrifter, og til sidst skal de vælge om de har lyst til at modtage nyhedsbrev eller ej. Input types I registreringsmodulet har vi gjort brug af forskellige form-elementer: text input til registrering af navn og e-mail, radiobutton input til valg af køn, selectbox input til valg af region og checkbox input til valg eller fravalg af nyhedsbrev. Når brugeren klikker på Opret bruger gemmes oplysningerne i databasen og de får udskrevet et automatisk genereret ID-nummer efterfølgende. I formularen til at registrere sig som bruger har vi valgt at tilføje en dropdown-funktion hvor brugeren kan vælge, hvor i landet han/hun bor. Det er valgt med henblik på at kunne benytte denne viden i markedsføring - særligt i forhold til det nyhedsbrev, brugeren også kan tilmelde sig. I samme tråd kunne vores kunde vælge at spørge ind til brugernes alder eller hvor mange hjemmeboende børn de har. Gestalt Ved design af vores to formularer (brugerregistrering og opskriftsupload) har vi taget udgangspunkt i gestalts lov om nærhed, der siger at to eller flere elementer der er anbragt nær hinanden, opfattes som hørende sammen: For eksempel har vi i registreringsformularen anbragt for- og efternavns-felterne tættere på hinanden, brugernavn-feltet står for sig selv, e-mail-felt og tilvalg af nyhedsbrev er anbragt sammen og Side 12 af 16
Autofocus Vi har valgt at tilføje autofocus på vores formularer, som en ekstra brugervenlighedsdetalje. Når et felt er aktivt lyser det således op i den udvalgte gule farve fra vores basisdesignelementer. Det er naturligvis ikke en holdbar løsning i længden, da alle og enhver på nuværende tidspunkt kan gå ind på Upload opskrift og tilføje (næsten) hvad som helst i vores database på et tilfældigt ID-nummer - også ID-numre som endnu ikke er genereret til en bruger. Dette skal selvfølgelig rettes op på i fremtiden, så brugerne SKAL være logget ind for at kunne uploade en opskrift, der så automatisk gemmes på brugerens id og brugernavn. Alternativer Alternativet til JavaScript-validering af vores forms ville være HTML5-validering, der på samme måde som JS checker brugerens input. Login vs. registrering Websitet har endnu ikke en funktionel login-funktion. Brugerne kan registrere sig og blive gemt i sitets database med et unikt id-nummer, men brugerne er indtil videre nødt selv at huske og benytte sit id-nummer, når han/hun vil uploade opskrifter. Forskellen ligger dog i at browseren selv selv udfører valideringen istedet for at hente et script ned. HTML5-valideringen udfører valideringen via de respektive input-elementer, dvs. at man giver de forskellige inputs en passende attribut som f.eks. email eller måned/år. Ulempen ved brugen af HTML5-validering er, at den stort set ikke er understøttet i ældre versioner af Safari, overhovedet ikke i ios- og Android-browsersystemer, hvorimod at metoden fungerer på alle de seneste browsere, bortset fra ovenstående. Dette ville vise sig at være et stort problem, især da vi har tilmelding som et menu-punkt i vores mobile løsning af websitet. Her er det væsentligt mere brugervenligt og effektivt at bruge JavaScript. Side 13 af 16
Responsivt design Ifølge problemformuleringen/kontrakten var det et krav at det færdige website skulle fungere responsivt. Altså på flere skærmstørrelser: desktop, tablet og mobil. Eftersom det største element i vores kundes markedsføringsplan omfatter salg (af cupcakes og opskrifter), har vi ud fra vores 12 menu- og undermenupunkter valgt at opprioritere dette. Heldigvis havde vi allerede før projektstart tilpasset og udformet størstedelen af websitet med responsiv CSS i tre seperate stylesheets. Forspringet gav os større frihed til at få en bedre forståelse for PHP-delen af projektet, så det fungerer korrekt uden fejl. I vores Gantt-kort fremgår der Kodning af CSS, og dette omfatter tilretning af og tilføjelser til oprindeligt responsivt design, design af piktogrammer til mobilløsning og inkorporering af disse på websitet. Vi har prioriteret følgende menupunkter i den mobile løsning, hvor det hverken var muligt rent funktionelt eller æstetisk at have alle menu- og undermenupunkter med: Blog (herunder alle blog-kategorierne) Brugernes opskrifter Butik Registering af brugere Side 14 af 16
Ikoner til mobil løsning Vi har valgt at udvikle fire ikoner til de fire menupunkter ( Blog/hjem, Brugernes opskrifter, Butik og Registrering ) til den mobile størrelse i det responsive design. Piktogrammerne på websitet er til for at skabe et bedre overblik over menuen når det responsive træder i kraft. Ved nedjustering af skærmstørrelse, forsvinder menupunkterne og ikonerne kommer til at fungere som en erstatning for disse. Blog-elementerne Opskrifter, Tips & Tricks, Galleri, Vlogs og Diverse kommer automatisk til at blive opdateret under selve bloggen, så funktionen bag menupunkterne forsvinder ikke når man går ned på mobil - man kan blot ikke vælge kategorierne aktivt (i den lokale menu). Ikonerne følger det samme overordnede design, så alle linjer og kurver har samme størrelse. Vi har besluttet at designet af ikonerne skulle være så forståeligt og simpelt som muligt, så de kunne stå alene uden tekst og fungere monotone, så vi kunne skifte farve på websitet ift. dets overordnede design. Altså skulle ikonerne være kendte og aflæselige for brugeren. Blog-knappen tegnet som et hus - for at signalere hjem. Opskrifterne er symboliseret ved et piskeris, som er en del af den action ikonet indekserer. Butikken/salgs-funktionen er har en indkøbsvogn som ikon. Registreringens ikon forestiller en person med et plus, der skal symbolisere, at man kan tilmelde sig/ addere sig selv til sitet. Den eneste farve, udover hvid, vi har brugt i designet af ikonerne er den lyserøde i tilmeldings-ikonet (som i øvrigt er den samme, som på registreringsknappen i desktop og tablet-løsningen). Årsagen til dette er at skille netop dette ikon ud fra de tre andre, da vores kunde jf. projekt 2 skulle have fokus på salg og på at tiltrække nye brugere af sitet. Side 15 af 16
Konklusion Som en ny del af Kristine Bechs blog om cupcakes er det blevet gjort muligt for brugerne at registrere sig og uploade opskrifter til siden. Når man registrerer sig som bruger får man et automatisk genereret bruger-id, man skal bruge når man uploader en opskrift, sådan at man selv og andre brugere kan finde sine opskrifter ved at søge på det brugernavn man selv har valgt. For at informationerne ikke bliver indtastet forkert når opskrifter skal uploades og gemmes i databasen, er der gjort brug af JavaScript-validering, som via en alert box fortæller brugeren, hvor der mangler information eller hvor der er opstået en fejl og hjælper brugeren med at komme videre derfra. For endnu bedre brugeroplevelse er bloggens responsive design blevet opdateret, og der er nu kommet en fast menu i bunden af siden med ikoner for lettere navigation, når siden vises på mobilenheder. Dette gør det endnu lettere at hurtigt finde frem til den information man leder efter. Alt i alt er Kristine Bechs blog blevet både en del mere brugervenlig og interaktiv. Side 16 af 16