Kopi: Jesse James Garrett: ”The Elements of User Experience” , AIGA. Kapitel 4
Powers kap.5
En kravspecifikation er et dokument der mere konkret/specifikt beskriver hvad det er for en (multimedie) produktion, der skal udvikles. Kravspecifikationen ses derfor i det traditionelle vandfaldsparadigme som et dokument eller ligefrem en kontrakt mellem kunden og projektlederen, der afslutter undersøgelsestrinnet. I den efterfølgende udviklingen af produktet kan udviklerne teste om produktet lever op til de stillede krav i kravspecifikationen. Kunden kan også ansætte eksterne folk til at teste om kontrakten, kravspacifikationen er overholdt. Arbejder man med en mere iterativ (gentagende) udviklingsmetode så som prototyping, vil kravspecifikationen blive justeret efter hver iteration. Kravspecifikationen som kvalitetssikringsdokument har sin oprindelse i en mere teknisk, ingeniørorienteret tradition.
Hvordan finder man krav til kravspecifikationen?
Man kan samle krav (eng. gathering requirements) på flere måder som f.eks.:
- Konkretisering af Kundens (The Client) og andre interessenters behov.
- F.eks. resultat af kundemøder, gennemlæsning af projektbeskrivelsen.
- Konkretisering af de strategiske mål for webproduktionen (eng. objectives).
- F.eks. kampagnesitet skal få mindst 500 brugerne til at tilmelde sig et nyhedsbrev inden 2011.
- Konkretisering udfra brugerprofilens/modelbrugerens (persona) behov og adfærd (behavior).
- F.eks. Poul bruger en PC med en IE v6.0 og en skærmopløsning på 1024x768, Poul vil gerne se hvem der står bag firmaet samt have et telefonnummer han evt kan ringe til.
- Ved at se på hvordan diverse brugerscenarier beskriver interaktionen/dialogen(adfærd) mellem modelbrugeren og det tænkte produkt.
- F.eks. Poul klikker på videoen på forsiden, og ser en 1 min. præsentation af produktet.
- Konkretisering af krav via feedback på diverse prototyper.
- F.eks. Brugertesten vidste kun 50% af testpersonerne ikke har den nyeste flashplayer 10 installeret => Flashelementer skal virker i minimum Flashplayer 8.
Kravene kan derfor ofte udledes af det analyse arbejdet man har lavet i undersøgelsestrinnet i HOME.
En kravspecifikation struktureres ofte i forhold til kategorierne indhold, funktionalitet/features og tekniske krav. Ved traditionelle statiske websites (som projekt1_1 på 1.semester) er der mest fokus på, hvilket indhold der er på sitet, samt hvordan det bliver præsenteret.
Ved webapplikationer og spil hvor brugeren er mere fokuseret på at udfører nogle bestemte opgave (eng. task) som f.eks. at købe en vare, bestille et nyhedsbrev, blive en registreret bruger, vil funktionelle og tekniske krav typisk fylde mere.
Hvordan laver man en god kravspecifikation?
- Kravspecifikation som følger ovenstående regler
- Status i forhold til kravspecifikation (verificering). Angiv de krav som er implementeret dvs. er lavet og de som mangler på i den pågældende version af produktet.
- Modeller som giver overblik over produktionen.(sitemap, flowchart og wireframes m.m. )
- Kodebeskrivelser af væsentlige elementer af koden.
- Overskuelig kode, fornuftig navngivning, fornuftig anvendelse af kommentar i koden.
Det er en af PHP's afgørende styrker, at det som serverside sprog er i stand til at opsamle og registrere input fra brugerne. Når brugeren i rollen som klient via en browser afsender en formular (dvs. aktiverer formens submit-knap), er det muligt, med PHP installeret på serveren at opsamle denne information.
Eksempel fra Powers contact2.php fra kapitel 5, hvor der via en form opsamles input fra brugeren til en email.
Ut enim ad minim veniam, quis nostrud exercitation consectetur adipisicing elit. Velit esse cillum dolore ullamco laboris nisi in reprehenderit in voluptate. Mollit anim id est laborum. Sunt in culpa duis aute irure dolor excepteur sint occaecat.
Når man trykker på 'send message' vil de indtastede data blive gemt et array som har variabel navnet $_POST.
Centrale kode fra contact2.php
<div id="maincontent">
<h1>Contact us </h1>
<p>Ut enim ad minim veniam, quis nostrud exercitation consectetur adipisicing elit. Velit esse cillum dolore ullamco laboris nisi in reprehenderit in voluptate. Mollit anim id est laborum. Sunt in culpa duis aute irure dolor excepteur sint occaecat.</p>
<form id="feedback" method="post" action="">
<p>
<label for="name">Name:</label>
<input name="name" id="name" type="text" class="formbox" />
</p>
<p>
<label for="email">Email:</label>
<input name="email" id="email" type="text" class="formbox" />
</p>
<p>
<label for="comments">Comments:</label>
<textarea name="comments" id="comments" cols="60" rows="8"></textarea>
</p>
<p>
<input name="send" id="send" type="submit" value="Send message" />
</p>
</form>
<pre>
<?php if ($_POST) {print_r($_POST);} ?>
</pre>
</div>
PHP kommandoen <?php if ($_POST) {print_r($_POST);} ?> gør at, hvis der er indhold i $_POST arrayet, vil det blive skrevet ud på clienten via print_r( ) funktionen ( en funktionen der er beregnet til at udskrive arrays).
I nogle tilfælde vil man gerne have at dataerne i formularen sendes til et specifikt PHP dokument, der så efterfølgende behandler disse. Dette gøres ved at sætte action attributten = navnet på PHP dokument, hvis det
ligger i samme mappen eller at angive en URL til PHP dokumentet..
<form name="myForm" method="post" action="http://www.slipsager.net/mdu/f2010/2sem/PHP/form_feedback.php" onsubmit="return validateForm()">
Se også det PHP script som er brugt til at give en form feedback til brugeren.
Arrayet $_POST er opbygget som et såkaldt associativt array, og vi kan derfor få fat i, hvad der er indtastet i de enkelte input elementer, ved at associere/referere til inputfelternes name attribut.
<input name="name" id="name" type="text" class="formbox" />
<input name="email" id="email" type="text" class="formbox" />
<textarea name="comments" id="comments" cols="60" rows="8"></textarea>
Eksempel på et Associativt array.
| key/index | $_POST[key] |
| "name" | "Kim" |
| "email" | "kim@gmail.com" |
| "comments" | "Dette er en test" |
$_POST["name"], $_POST["email"],$_POST["comments"]
Dette kan så f.eks. bruges sådan.
echo("<h1>Hej med dig ". $_POST["name"]."</h1>");
I FORM-elementet angiver attributten method, at indholdet skal videresendes med metoden post. Der findes en alternativ metode get.
Prøv at ændre ovenstående kode så der i form elementet i stedetfor står :
<form id="feedback" method="get" action="">
<?php if ($_GET) {print_r($_GET);} ?>
Forskellen på de to metoder er, at mens indholdet med metoden post sendes til serveren som en message, bliver indholdet med metoden get sendt via URL'en , og dermed bliver formindholdet synligt i browserens adresselinje.
Dette kaldes også for en Query string.
Generelt anbefales det at begrænse anvendelsen af get til forespørgsler, f.eks. i forbindelse med søgninger eller fremvisning af oplysninger fra database.
Drejer det sig derimod om afsendelse af data mhp. lagring eller opdatering af eksisterende data, bør metoden post anvendes. Da vi netop her afsender data til til serveren mhp. registrering, er metoden post det korrekte valg.
Se http://www.phpartikler.dk/artikler/formular.php
Læs følgende artikel om mail forms:
http://www.phpartikler.dk/artikler/mail.php#formmailer
Det kan være problemer med at sende mail fra WAMP serveren så for at teste formmaileren skal den gerne være uploadet til en remote webserver.
Denne type form mailer er meget åben og kan med fordel gøres mere sikkert og robust via:
Herved kommer man frem til Powers contact09.php (gemt som tekst fil !!)
Opg.0 Kravspecifikation
Prøv at testet/undersøge websitet Kokken. i forhold til nedenstående teknisk og funktionelle krav:
Opg. 1
Prøv at få dette eksempel til at kører på din lokale WAMP eller MAMP server. Dvs. ved at gemme form_validation_id.html på testserveren og så lave en formfeedback.php side som bliver aktiveret når brugeren trykker på submit.
<form name="myForm" method="post" action="form_feedback.php" onsubmit="return validateForm()">
form_feedback.php kan se således ud:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Feedback from ordering form</title>
</head>
<body>
<h1> The server side script form_feedback.php has received your submission </h1>
<p>Welcome <?php echo $_POST["name"]; ?>!<br />
Your email is <?php echo $_POST["email"]; ?> .</br />
Telephone number is <?php echo $_POST["telefon"]; ?>
</p>
<p> </p>
<hr />
<p>form_feedback.php looks like this:</p>
<p> </p>
</body>
</html>
Opg. 2
Lav en formfeedback side på bestillingsformularen som evt. kan bruges i forbindelse projekt 2_1.
Extra opgaver:
Opg. 3 Serverside validering
Lav via PHP en serverside validering af opg. 1. som kan bruges i stedet for client side valideringen som sker via javascript.
Tip: Du kan her benytte funktionerne strlen og is_numeric (se nærmere på www.php.net, hvor du finder samtlige php-funktioner dokumenteret).
Overvej fordele og ulemper ved at benytte henholdsvis klientside og serverside validering. Hvilken valideringsform bør foretrækkes? Begrund dit svar.
