Hovedprosjekt - student.cs.hioa.nostudent.cs.hioa.no/hovedprosjekter/data/2014/46/filer/sluttrapport.pdf · ER-Modell for databasen brukt med PHP-løsning ..... 95 ER-Modell for databasen

HOVEDPROSJEKT

HOVEDPROSJEKTETS TITTEL

Innloggingsløsning for Fontenehuset DATO

21.05.14 ANTALL SIDER / BILAG

PROSJEKTDELTAKERE

Erlend S. Westgaard s155474, Anders Isaksen s122445 INTERN VEILEDER

Simen Hasselknippe

OPPDRAGSGIVER

Fontenehuset i Oslo KONTAKTPERSON

Kåre Grüner

SAMMENDRAG

Fontenehuset i Oslo ønsker seg en innloggingsløsning som kan erstatte det papirbaserte systemet de bruker i dag. Løsningen skal kunne betjenes fra en iPad som skal stå i resepsjonen. Det er laget to løsninger. Den ene er en webapplikasjon som bruker PHP og Filemakers PHP-API for å koble til databasen. Den andre løsningen bruker Filemaker Go til å vise databasen direkte på iPaden. Fontenehuset får presentert begge løsningene og kan velge det som passer best for dem.

3 STIKKORD

Database

Innlogging

iPad

Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

2014 - 46

TILGJENGELIGHET

ÅPEN

Telefon: 22 45 32 00

Telefaks: 22 45 32 05

1

Gruppe 46

2014

Hovedprosjekt Innloggingsløsning for Fontenehuset Erlend Syljuåsen Westgaard og Anders Isaksen

2

Innholdsfortegnelse HOVEDPROSJEKT ........................................................................................................................................... 0

Innholdsfortegnelse ...................................................................................................................................... 2

Sammendrag ................................................................................................................................................. 5

Produktdokumentasjon ................................................................................................................................ 6

1. Rammekrav ........................................................................................................................................... 6

2. Om prosjektet ....................................................................................................................................... 6

Fontenehuset i Oslo .............................................................................................................................. 6

3. Teknologi ............................................................................................................................................... 7

3.1 Filemaker Go løsning ....................................................................................................................... 7

3.2 Webbasert PHP løsning ................................................................................................................... 7

4. Økonomi ................................................................................................................................................ 8

5. Teknisk implementasjon ....................................................................................................................... 8

5.1 Webbasert PHP løsning ................................................................................................................... 8

5.2 Filemaker Go løsning ..................................................................................................................... 26

6. Testing ................................................................................................................................................. 41

7. Metode og planlegging ....................................................................................................................... 42

Prosessdokumentasjon ............................................................................................................................... 43

8. Innledning ........................................................................................................................................... 43

8.1 Fontenehuset i Oslo ...................................................................................................................... 43

8.2 Begrensninger ............................................................................................................................... 43

8.3 Prosjektdeltakere .......................................................................................................................... 43

9. Mål ...................................................................................................................................................... 44

10. Kravspesifikasjon ............................................................................................................................... 44

11. Planlegging og metode...................................................................................................................... 45

11.1 Planlegging .................................................................................................................................. 45

11.2 Utviklingsmetode ........................................................................................................................ 46

11.3 Oversikt over sprinter ................................................................................................................. 47

11.4 Burndown charts ......................................................................................................................... 48

12. Om utviklingsprosessen .................................................................................................................... 50

12.1 Utviklingsfaser ............................................................................................................................. 50

13. Konklusjon ......................................................................................................................................... 58

3

Vedlegg ....................................................................................................................................................... 60

Vedlegg A: Kravspesifikasjon .................................................................................................................. 60

Systembeskrivelse ............................................................................................................................... 60

Funksjonelle krav ................................................................................................................................ 60

Ikke funksjonelle krav ......................................................................................................................... 60

Rammekrav ......................................................................................................................................... 60

Krav til dokumentasjon ....................................................................................................................... 60

Vedlegg B: Brukertest ............................................................................................................................. 61

Brukertest Web ................................................................................................................................... 62

Brukertest Filemaker Go ..................................................................................................................... 63

Brukertest sammenligning .................................................................................................................. 64

Kommentarer fra spørreskjema .......................................................................................................... 65

Vedlegg C: Test av php kode ................................................................................................................... 68

Feilsituasjoner som testes: ................................................................................................................. 68

Vedlegg D: Skisser av brukergrensesnitt ................................................................................................. 70

Forslag 1 .............................................................................................................................................. 70

Forslag 2 .............................................................................................................................................. 71

Vedlegg E: Brukermanual for den webbaserte php-løsningen ............................................................... 72

Forord .................................................................................................................................................. 73

Notasjoner .......................................................................................................................................... 73

Innledning ........................................................................................................................................... 73

Brukerveiledning ................................................................................................................................. 74

Innlogging ................................................................................................................................................ 74

Vedlegg F: Brukermanual for Registeringssystem Filemaker ................................................................. 81

Innhold ................................................................................................................................................ 82

Forord .................................................................................................................................................. 82

Notasjoner .......................................................................................................................................... 82

Innledning ........................................................................................................................................... 82

Vanlige brukere ....................................................................................................................................... 83

Registreringsbeskjeder ........................................................................................................................ 84

Administrasjon ........................................................................................................................................ 85

Innstillingsmeny .................................................................................................................................. 85

4

Inneliste ............................................................................................................................................... 86

Personreg ............................................................................................................................................ 87

Vedlegg G: Use Case ............................................................................................................................... 88

Vedlegg H: Sekvensdiagram .................................................................................................................... 89

Vedlegg I: Virkningsanalyse .................................................................................................................... 91

Vedlegg J: Fremdriftsplan ....................................................................................................................... 92

Vedlegg K: Begrep ................................................................................................................................... 93

Vedlegg L: Akseptansetest ...................................................................................................................... 94

Akseptantsetest 1 ............................................................................................................................... 94

Akseptantsetest 2 ............................................................................................................................... 94

Vedlegg J: ER-Modeller ........................................................................................................................... 95

ER-Modell for databasen brukt med PHP-løsning .............................................................................. 95

ER-Modell for databasen som inneholder Filemaker Go- løsning ...................................................... 95

Vedlegg K: Risikoanalyse ......................................................................................................................... 96

5

Sammendrag Fontenehuset i Oslo ønsker seg en innloggingsløsning som kan erstatte det papirbaserte systemet de bruker i dag. Løsningen skal kunne betjenes fra en iPad som skal stå i resepsjonen. Fontenehuset bruker i dag en Filemaker database. Det er derfor nødvendig at løsningen kan knyttes opp mot Filemaker. Etter å ha lest dokumentasjonen til Filemaker, fant prosjektgruppa ut at det var to aktuelle måter å lage en løsning på. Den ene måten er ved å lage en webapplikasjon som bruker PHP og Filemakers PHP-API for å koble til databasen. Den andre måten er ved å bruke Filemaker Go til å vise databasen direkte på iPaden. Begge metodene har sine fordeler og ulemper. Prosjektgruppa valgte å utvikle begge løsningene. Grunnen til dette var at vi var usikre på hvilket system som best dekket Fontenehusets behov. Vi ville også avdekke begrensninger med teknologiene, som kun ville bli synlig etter hvert som løsningene utvikles. Begge løsningene ble utviklet for å løse samme oppgave, men utvilklingsmetodene gjør at opplevelsen for brukerne blir litt forskjellig. Måten systemene kan vedlikeholdes og videreutvikles er også forskjellig. Begge løsningene er utviklet for å fylle kravene satt av Fontenehuset. Prosessmetoden som ble benyttet var scrum-metoden. Den passet best for oss, siden den var fleksibel nok til å takle eventuelle problemer og begrensinger vi ville møte. Framgangen og tidsbruken ble organisert i Visual Studios Online. Fontenhuset ville vite hvilken av løsningene som er mest brukervennlig, og hvilken av dem som er lettest å vedlikeholde. På grunn av økonomien er det Fontenehuset selv som vil ta seg av det regelmessige vedlikeholdet av systemet. Etter at to fungerende systemer var utviklet, testet vi disse på et utvalg frivillige på Fontenehuset. Testpersonene foretrakk PHP-systemet. Den endelige avgjøreslsen om hvilket av systemene som vil bli tatt i bruk, er ikke tatt av Fontenehuset enda. Ansvar for vedlikehold av løsningen er fortsatt ikke fastsatt.

6

Produktdokumentasjon

1. Rammekrav Fontenehuset i Oslo har skaffet seg en ny databaseløsning for medlemsdata. Denne løsningen benytter seg av Filemaker Server. I den anledningen har de tenkt å modernisere innsjekkingen av medlemmer. Fram til nå har dette foregått manuelt. På grunn av at medlemmene har begrenset med dataerfaring, ønsker Fontenehuset at systemet skal være så enkelt og brukervennlig som mulig. Det er også viktig at vedlikehold av løsningen er enkel. Prosjektgruppa har i samarbeid med Fontenehuset satt opp en kravspesifikasjon (Vedlegg A). Nedenfor er de viktigste punktene i denne:

● Enkelt og brukervennlig grensesnitt ● Løsningen skal koble til Filemaker Server ● Enheten som skal benyttes for inn og utregistrering er en iPad, og løsningen skal

fungere på den ● Medlemmer skal søke opp seg selv via medlemmsnummer eller navn ● Søkeresultater vises mens man skriver i søket ● Ved inn- og utlogging skal det gis tilbakemelding til bruker om at man blir inn- eller

utlogget ● Potensielle nye medlemmer (mulige medlemmer) skal også kunne benytte

innloggingssystemet ● Løsningen skal skille mellom det de kaller “arbeidsorientert dag” og “fritidsprogram”. ● Enkelt vedlikehold av løsningen

2. Om prosjektet

Fontenehuset i Oslo Fontenehuset er er et arbeidsfellesskap for mennesker som har eller har hatt psykiske helseutfordinger.

Den første fontenehuset ble startet i New York i 1948, av en gruppe mennesker som etter endt behandling på psykiatrisk sykehus, følte at de trengte et sted som kunne være en overgang før de skulle tilbake til arbeidslivet. I dag er det ca 400 fontenehus over hele verden…. Fontenehuset i Oslo drives av medlemmer med psykiske helseproblemer og en gruppe fast ansatte. Arbeidet på huset er frivillig og medlemmene velger selv hvor ofte og hvor mye de vil delta. Hvert enkelt medlem får mulighet til å jobbe ut fra individuelle behov. Målet vårt er å bidra til at den enkelte får en strukturert, givende og sosialt liv.

--Infohelte Velkommen til Fontenehuset i Oslo

Fontenehuset i Oslo er det første av åtte Fontenehus i Norge. De andre Fontenehusene er i Drammen, Stavanger, Tromsø, Bergen, Hønefoss, Kongsberg og et til i Oslo Øst.

7

Fontenehuset har en ganske åpen informasjonsflyt innad. Unntaket er sensitive opplysninger som begrenses i henhold til brukernes ønsker og Personvernloven. Innholdet i persondatabasen “Klubblogg” drives av ansatte og frivillige. Den inneholder blandt annet systematisert personinformasjon for medlemmer og mulige medlemmer. Filer med informasjon knyttet til den enkelte personen lagres på lokalnettet. Personvern blir ivaretatt ved at databasen og lokalnettet er sikret med brukernavn og passord. De tekniske aspektene ved databasen kalt “Klubblogg”, er laget og vedlikeholdes av en person utenifra som er i slekt med en ansatt i Oslo Øst. IT-kunnskapen på Fontenehuset varierer fra ganske kompentente og erfarne til nybegynnere og uerfarne. Denne variasjonen i kunnskap og erfaring gjør at hver eneste løsning må være enkel å bruke. Ethvert system må enten sikre eller ikke bruke sensestive opplysninger. Samtidig må løsningene være enkle å administrere og vedlikeholde, siden Fontenehuset er en frivillig organisasjon og ikke har økonomi til å betale konsulenter utenifra for velikehold. I stedet utfører medarbeidere og medlemmer vedlikeholdet ut i fra de de har kunnskaper til.

3. Teknologi De to separate løsningene som er utviklet er basert på ulik teknologi. Begge løsningene var akseptable for Fontenehuset, men prosjektgruppa ønsket å teste ut funksjonalitet og brukergrensesnitt og hvordan det oppleves av brukerne. Siden bruk av Filemaker er at krav, er begge løsningene knyttet opp mot Filemaker Server.

3.1 Filemaker Go løsning Filemaker har et eget program for iPad: Filemaker Go. Dette programmet kan kjøre Filemaker databaser, eller knytte seg opp mot Filemaker Server. Filemaker databaser har mulighet for å inneholde layout med knapper, menyer og skript. Dette gjør at løsningen for inn- og utlogging kan lages i Filemaker Pro, lastes opp til Filemaker Server, og vises i Filemaker Go.

3.2 Webbasert PHP løsning En PHP-basert løsning må kunne kjøre på iPad. Bortsett fra dette er det ingen begrensinger på bruk av teknologi i PHP-løsningen. Filemaker har et API for PHP. Dette APIet gjør at PHP applikasjoner kan knytte seg opp mot databaser som kjører på Filemaker Server. Apples iPad har en nettleser, og kan kjøre webapplikasjoner som bruker PHP. PHP, HTML5, CSS3 og JavaScript har blitt brukt for å oppfylle de funksjonelle kravene til løsningen.

8

4. Økonomi Løsningene bruker eller knytter seg opp mot Filemaker Pro og Server. Siden Fontenehuset har en lisens på Filemaker Pro og Server fra før av, vil ikke en ny løsning medføre en økning av kostnadene. Løsningene er designet for bruk på iPad etter ønske fra Fontenehuset. Fontenehuset har ikke en iPad fra før, og vil måtte gå til anskaffelse av dette. Gruppen tar ikke hensyn til kostnader knyttet til dette.

5. Teknisk implementasjon For å lage løsningene er det brukt forskjellige teknologier. De tekniske detaljene for hvordan de er implementert er beskrevet i detalj i punktene nedenfor.

5.1 Webbasert PHP løsning Den Webbaserte PHP løsningen er bygget opp ved å bruke programmeringsspråkene PHP, HTML 5, CSS 3.1 og JavaScript. Filemaker tilbyr et PHP API. Det inkluderer filen Filemaker.php og mappen Filemaker, som inneholder mange flere PHP-filer. Disse filene muliggjør kommunikasjon med databasene på Filemaker Server. Siden det er en Web-applikasjon, er det brukt HTML. CSS er brukt for å definere layout. JavaScript-biblioteket jQuery er brukt for å implementere noen av funksjonene i løsningen. JQuery har ferdige løsninger for avanserte funksjoner, og gjør det enkelt å implementere disse uten å skrive mye kode.

Oppbygging

Løsningen består av flere filer som sammen skaper web-applikasjonen:

9

Beskrivelse av filer i løsningen: favicon.ico - Dette ikonet vises ved siden av sidenavnet når man åpner opp websiden, eller i bokmerkelista, hvis man har laget et bokmerke. apple-touch-icon.png - Dette er et ikon som er spesielt for iPad og iPhone, og vises når man lager et bokmerke som et eget ikon på hjemmeskjermen. Dette gjør det mulig å få web-applikasjonen til å skille seg ut, og være lett gjenkjennlig. stil.css - Et stilsett som definerer utseendet for sidene i web-applikasjonen. stay_standalone.js - Sørger for at web-applikasjonen ikke hopper ut av fullskjermsmodus når man klikker på linker. liste.txt - Oppdateres automatisk av autooffline.php når noen logger ut eller inn. autologgut.php - Logger ut medlemmer som har glemt å logge seg ut på slutten av dagen. autooffline.php - Genererer filen liste.txt med liste over de som har logget inn og ikke ut. stay_standalone.js - Sørger for at iPaden ikke hopper ut av fullskjermsmodus. meny.php - En meny som er inkludert på alle sidene. Siden menyen er lik for alle sidene, var det logisk å ha det som en egen fil.

10

index.php - Hovedsiden med knapper for inn- og utlogging. logginn.php - Logginnside. logginn2.php - Utfører innloggingen og viser om det var vellykket. loggut.php - Loggutside. loggut2.php - Utfører utloggingen og viser om det var vellykket. admin.php - Innlogging for administrator. admin_meny.php - En meny som vises hvis man har logget seg inn som administrator. liste.php - En liste som viser de som har logget inn og ikke logget ut. liste.php - Henter informasjonen om hvem som er innlogget og ikke utlogget fra databasen. offlineliste.php - Lik som liste.php, men henter informasjonen i liste.txt. Dette gjør det mulig å få ut siste versjon av listen når databasen er nede. velg_liste.php - Viser inn- og utlogginger for en angitt dato.

Felles kode for php-filene

<style>* { -webkit-user-select: none; }</style>

Sørger for at man ikke kan velge elementer på siden. Det er brukt for at ikke teksten på skal bli valgt når noen trykker litt for lenge på menyelementer. Denne er ikke brukt på sider som har input-felter, så de kan bli trykket på. Hvis det er inputfelter blir det brukt #meny i stedet for *, slik at teksten i menyelementene fortsatt ikke kan bli merket.

<script>$(document).bind('touchmove', false);</script> Skript for å slå av “dra og slipp” funksjonen på iPad.

<?php $page = $_SERVER['PHP_SELF']; $sec = "1800"; header("Refresh: $sec; url=$page"); ?>

PHP kode for å laste inn siden på nytt, hvert 30 minutt. Det er nødvendig for å kjøre autologgut.php skriptet hvis ingen bruker iPaden.

require_once 'FileMaker.php'; $fm = new FileMaker(); $fm->setProperty('database', 'fontenehus'); $fm->setProperty('username', 'Admin'); $fm->setProperty('password', '');

Tilkobling til Filemaker for databasen fontenehus, brukernavn Admin og blankt passord. Denne funksjonen krever Filemaker.php.

11

Meny

meny.php

<div id="meny"> <a href="index.php" style="<?php if (isset($side)) { if($side=="indexphp"){ echo "color:#0099FF;";}}?>">Hjem</a>

Menyvalget “Hjem” blir sjekket om $side variablen er satt til indexphp. Hvis den er det blir fargen satt til #0099FF. Den samme sjekken er satt på alle menyelementene for å få en annen farge, hvis det menyelementet er valgt.

<script> function updateClock ( ) { var currentTime = new Date ( ); var currentHours = currentTime.getHours ( ); var currentMinutes = currentTime.getMinutes ( ); var currentSeconds = currentTime.getSeconds ( ); // Legg til ledende nuller for minutter og sekunder, hvis nødvendig currentMinutes = ( currentMinutes < 10 ? "0" : "" ) + currentMinutes; currentSeconds = ( currentSeconds < 10 ? "0" : "" ) + currentSeconds; // Lag tekststrengen som skal vises var currentTimeString = currentHours + ":" + currentMinutes + ":" + currentSeconds; $("#menytid").html(currentTimeString); } $(document).ready(function() { setInterval('updateClock()', 1000); }); </script>

Dette javaskriptet lager en tekststreng med tid, og plasserer det i #menytid. Tekststrengen oppdateres hvert sekund (1000ms).

Innlogging

logginn.php Nedenfor beskrives de viktigste delene av koden i denne filen, samt kommentarer på hvorfor det er kodet slik.

header( 'Content-Type: text/html; charset=UTF-8' ); Header er satt til UTF-8, for at bokstavene æøå skal vises korrekt.

setlocale(LC_TIME, 'Norwegian'); Den lokale tiden er satt til norsk tidssone.

$dag=iconv('ISO-8859-1', 'UTF-8', strftime("%A")); Siden Microsofts IIS er den webserveren som er best støttet av Filemaker Server, er det den som er brukt for å sette opp løsningen. IIS bruker ISO-8859-1 som standard for norsk. Siden UTF-8 er brukt andre steder, brukes php-funksjonen iconv til å konvertere tidsstrengen strftime("%A") til UTF-8. Det gjør at dager med ø vil vises korrekt.

12

foreach ($recordssone as $record) { if ($record->getField('Dato')==strftime("%m.%d.%Y")) { if ($record->getField('Sonenavn') == 'Fritid' && strftime('%H')>16) { $sonenavn = $record->getField('Sonenavn'); $aktivitet = $record->getField('Aktivitet'); }

I eksempelet over innhentes aktivitet for fritidssone på dagens dato, hvis klokken er etter 16.00. Datoformatet er m.d.Y, siden det er det formatet det blir lagret som i Filemaker databasen.

foreach ($records as $record) { $navnliste[]=$record->getField('Navn'); } foreach ($records2 as $record2) { if ($record2->getField('Tid ut')=='' && $record2->getField('Dato')==$date2 && $record2->getField('Tid inn')>0) { if($countrec2==0){$navninne=array();} $countrec2++; $navninne[]=$record2->getField('Navn'); } } if(isset($navninne, $navnliste)){ $navnute = array_diff($navnliste, $navninne); } else { $navninne[]=array(); $navnliste[]=array(); $navnute = array_diff($navnliste, $navninne);}

Koden ovenfor legger navnene fra databasen i $navnliste. De personene som ikke er logget ut for dagens dato legges til i $navninne. Til slutt tar den $navnliste og trekker fra de som er i $navninne. Det skaper en liste med personer som er ute, og de legges da i $navnute.

<script> $(function() { var availableTags = [<?php if(isset($navnute)){ foreach ($navnute as $value) { echo "'" .$value ."',"; } } ?>]; $( '#tags2' ).autocomplete({ source: availableTags }); }); </script>

Skriptet ovenfor putter verdiene fra $navnute i autocompletefunksjonen, som har id #tags2.

if (isset($_POST['navn']) ) { if(!empty($_POST['navn'])) {$verdi=$_POST['navn'];}} if (isset($_POST['medlemsnummer']) ) { if (is_numeric($_POST['medlemsnummer'])) { if(!empty($_POST['medlemsnummer'])) {$verdi=$_POST['medlemsnummer'];}}} if (!isset($verdi) ) { echo "<h1>Logg inn med medlemsnummer eller navn</h1>";

13

?>

Koden ovenfor sjekker om navn og medlemsnummer er satt, og legger verdien til $verdi. Medlemsnummer blir også sjekket for om den er et faktisk nummer, ikke andre tegn eller bokstaver. Den siste delen av koden sjekker om $verdi er satt, og vises kun hvis den ikke er satt. Inputfeltene for navn og medlemsnummer settes også etter denne sjekken. Det betyr at inputfeltene forsvinner når verdien i $verdi er satt. Etter inputfeltene avsluttes ifsetningen med }, slik at resten av koden kan vises selv om $verdi er satt.

if (is_numeric($_POST['medlemsnummer'])) { --- else {echo "<p>Verdien er ikke et tall! Prøv igjen med et nummer eller bytt til navnefeltet.";} }

En sjekk blir utført for å se om verdien i $_POST['medlemsnummer’] er et nummer. Hvis ikke blir det lengre ned i koden vist en feilmelding.

foreach ($records as $record) { if ($record->getField('IDnr')==$_POST['medlemsnummer'] ) { $medlemnr=1; if( !isset($medlemnr) ) { echo "<p>Medlemsnummer ikke funnet!</p>";} }

Hvis det blir funnet et treff i databasen for medlemsnummeret, blir $medlemnr satt til 1. Det gjør det mulig å kjøre en sjekk senere mot $medlemnr for å se om medlemsnummeret ble funnet, og hvis ikke vise en feilmelding.

if( isset($sonenavn, $aktivitet) ) { if ($sonenavn == 'Fritid' && strftime('%H')>16) { echo "<div style='visibility:hidden'><input type='text' name='sonenavn' value='" .$sonenavn ."'></div>"; echo "<div style='visibility:hidden'><input type='text' name='aktivitet' value='" .$aktivitet ."'></div>"; }

Først kjøres en sjekk for om $sonenavn og $aktivitet er satt. Disse blir satt hvis det er funnet et treff for dagen eller datoen i databasen. I eksempelet over vil de skjulte inputfeltene bli satt hvis det er funnet en oppføring for “Fritid” og klokkeslettet er etter kl. 16.

if ($sonenavn == 'Arbeid' && strftime('%H')<16) { Samme sjekk blir utført som i det forrige eksempelet, men for “Arbeid” før kl. 16.

if (isset($helg)) { echo "<div style='visibility:hidden'><input type='text' name='helgsonenavn' value='" .$helgsonenavn ."'></div>"; }

Hvis det er helg, blir det satt inn et skjult felt med verdien i $helgsonenavn. Verdien vil være satt til “Fritid” i helgen. Samme sjekker som er gjort på nummer i kodesnuttene ovenfor, blir også utført på navn. Bortsett fra at sjekken er på navn, er koden er ellers mer eller mindre lik.

14

logginn2.php

$tidinn=$_POST["tidinn"]; $tidpartpost = explode(':', $tidinn); $tidtimepost = $tidpartpost[0]; $tidtime =strftime('%H');

Del hele timen til tidsverdien “tid inn” blir skilt ut og lagret i $tidtimepost. $tidtime blir satt til den nåværende timen med strftime(‘%H’).

foreach ($navnute as $ute) { if ($_POST["navn"]==$ute) { if ($_POST["dato"]==$date) { if ($tidtimepost==$tidtime) {

Navnet blir sjekket om det finnes i $ute, og ikke er innlogget fra før av. Videre blir det sjekket om innloggingsdatoen er dagens dato. Til slutt blir det sjekket at innlogginstimen som skal inn i databasen, er det samme som den nåværende timen

$rec = $fm->createRecord('tidsstemplingTidsrom'); $rec->setField('Navn', $_POST["navn"]); $rec->setField('Dato', $fmdato); $rec->setField('Tid inn', $_POST["tidinn"]); if (isset($_POST["sonenavn"], $_POST["aktivitet"])) { $rec->setField('Tidssone', $_POST["sonenavn"]); $rec->setField('Aktivitet', $_POST["aktivitet"]); } else { if (isset($_POST["helgsonenavn"])) {$rec->setField('Tidssone', $_POST["helgsonenavn"]);} } $result = $rec->commit();

Etter sjekkene blir verdiene fra logginn.php ført inn i databasen. Det blir sjekket for om det er satt en tidssone aller aktivitet før verdiene blir lagret.

else { echo "<p>Tid er feil!. Kan kun logge inn med tidspunkt innenfor samme time</p>"; } } elseif ($_POST["dato"]!=$date && $tidtimepost!=$tidtime) { echo "<p>Dato er feil!. Kan kun logge inn med dagens dato</p><p>Tid er feil!. Kan kun logge inn med tidspunkt innenfor samme time</p>"; } else { echo "<p>Dato er feil!. Kan kun logge inn med dagens dato</p>"; } } else {echo "<p>Du er allerede innlogget!</p>";} }

Hvis sjekkene for innlogging, dato og tid som er i if setningene tidligere ikke går igjennom, vises det separate feilmeldinger. Det blir også kjørt en sjekk for å vise feilmelding hvis både tid og dato er feil samtidig. if (FileMaker::isError($result)) { $error=$result->code; echo "<p>Error $error: " . $result->getMessage() . "</p>"; }

15

else{ echo "<p>Du har blitt logget inn med følgende opplysninger:</p>"; echo "<p>Navn: " .$_POST["navn"] ."</p>"; echo "<p>Dato: " .$_POST["dato"] ."</p>"; echo "<p>Tid Inn: " .$_POST["tidinn"] ."</p>"; } Hvis Filemaker lagrer dataene uten feil, vil det vises en melding som bekrefter at opplysningene har blitt lagret. Hvis ikke vises det en feilmelding.

Utlogging

loggut.php

$date=strftime("%m.%d.%Y"); $findCommand =& $fm->newFindCommand('tidsstemplingTidsrom'); $findCommand->addFindCriterion('Dato', $date); $findCommand->addFindCriterion('Tid inn', "*"); $findCommand->addFindCriterion('Tid ut', "="); $result = $findCommand->execute(); if (FileMaker::isError($result)) { if ($result->getMessage()=="No records match the request") { echo "Ingen har logget inn i dag! exit;} else { echo "Error: " .$result->getMessage(); exit;}} $records = $result->getRecords();

Et søk blir gjort i tabellen “tidsstemplingTidsrom” for dagens dato, der “Tid inn” er fylt ut og “Tid ut” er tom. Hvis ikke noe er funnet, vises en feilmelding. Den fulle koden i vedlegget har HTML i tillegg til feilmeldingene, slik at de får en penere og mer brukervennlig presentasjon av disse.

<script> $(function() { var availableTags = [ <?php foreach ($records as $record) {?> "<?php echo $record->getField('Navn'); ?>", <?php } ?> ]; $( "#tags2" ).autocomplete({ source: availableTags }); }); </script>

Skriptet finner verdiene fra feltet “Navn” og putter det i en liste som autocomplete bruker.

<script> $(function() { var availableTags = [ <?php foreach ($records as $record) {?> "<?php echo $record->getField('IDnr'); ?>", <?php } ?> ]; $( "#nrut" ).autocomplete({

16

source: availableTags }); });

Samme som forrige skript, men denne gangen med verdiene fra IDnr.

<?php if (isset($_POST["navnselect"])) { if(!empty($_POST["navnselect"])){ $navnselect=$_POST["navnselect"]; $select=$_POST["navnselect"]; }} if (isset($_POST["idselect"])) { if(!empty($_POST["idselect"])){ $idselect=$_POST["idselect"]; $select=$_POST["idselect"];}} if (!isset($select)) { echo "<h1>Logg Ut</h1>"; ?>

Koden gjør at selectfeltene ikke vises etter submit. Ifsetningen avsluttes med en } etter selectfeltene.

<?php if( isset($navnselect) ) { $navn=$navnselect; foreach ($records as $record) { if ($record->getField('Dato')==strftime("%m.%d.%Y") && $record->getField('Navn')==$navn) { $navn_ok=1; echo "<form action='loggut2.php' method='post'>"; echo "<input type='submit' id='css3button' class='bekreft' value='Logg ut' autofocus>" ."<br/>"; echo "<input type='text' name='navn' id='nyttfelt' value='" .$record->getField('Navn') ."' readonly>"; echo "<input type='text' name='tidut' id='nyttfelt' value='" .$time ."' readonly>"; echo "<div id='avbryt'><a href='loggut.php'>Avbryt</a></div>"; echo "<div id='recid' style='visibility:hidden'><p>ID:<input type='number' name='id' value='" .$record->getRecordID() ."' class='input'></p></div>"; }}

Sjekker om navnet blir funnet for dagens dato. Om det er tilfellet, kommer det opp en loggutknapp. Man kan se navnet og tidspunktet som blir logget i databasen når man logger ut. Et skjult felt blir lagt til med “Record ID”. Dette er en intern ID for oppføringen som blir brukt av Filemaker Server. Hver oppføring har en slik unik verdi.

if (!isset($navn_ok)) { echo "<p>Navn: " .$navn ." er logget ut / ikke logget inn</p><a href='loggut.php'>Skrev du feil navn kan du prøve å logge ut igjen</a><br/>"; }

Hvis $navn_ok variablen ikke er satt vises en feilmelding om at navnet ikke er funnet.

if( isset($idselect) ) { $nrut=$idselect; foreach ($records as $record) { if ($record->getField('Dato')==strftime("%m.%d.%Y") && $record->getField('IDnr')==$nrut) { $id_ok=1;

Hvis man har fylt ut medlemsnummer, søkes det etter en oppføring på samme måte som for navn. Knappene og feltene som blir vist er like de som vises for navn.

if (!isset($id_ok)) { echo "<p>Medlemsnummer: " .$nrut ." er logget ut / ikke

17

logget inn</p><a href='loggut.php'>Skrev du feil medlemsnummer kan du prøve å logge ut igjen</a><br/>";}

Hvis $id_ok variablen ikke er satt, vises en feilmelding om at navnet ikke er funnet.

loggut2.php

//Sjekk av tid if ($tidtimepost==$heltime) { $tidsjekk=1; } elseif ($tidtimepost!=$heltime && $tidsforskjell==1 && $tidpartpost[1]==59) { $tidsjekk=1; } //Sett tidssjekk til 1 hvis det kun er opptil 1 min siden timeskiftet else {$tidsjekk=0;}

Variablen $tidsjekk blir satt til 1 hvis tidspunktet for utloggingen på forrige side, loggut.php, er innenfor samme hele time.

if ($tidsjekk==1) { $findtidinn =& $fm->newFindCommand('tidsstemplingTidsrom'); $findtidinn->addFindCriterion('Dato', strftime('%m.%d.%Y')); $resulttidinn = $findtidinn->execute(); if (FileMaker::isError($resulttidinn)) { } else { $recordstidinn = $resulttidinn->getRecords(); foreach ($recordstidinn as $record) { if ($record->getField('Navn')==$_POST["navn"] && $record->getField('Dato')==strftime('%m.%d.%Y') && $record->getField('Tid inn')>0) { $tidinn = $record->getField('Tid inn'); }}}

Hvis sjekken på tid er godkjent, blir $tidinn fylt med tidspunktet navnet logget seg inn.

if ($tidtimepost<=16) { $editCommand = $fm->newEditCommand('tidsstemplingTidsrom', $_POST["id"]); $editCommand->setField("Tid ut", $_POST["tidut"]); if ($helg==false) { $editCommand->setField("Tidssone", "Arbeid");} else {$editCommand->setField("Tidssone", "Fritid");} $editCommand->setField("Utlogging", 'Manuelt'); $result = $editCommand->execute(); } else { if ($tidinn<'16:00:00') { $editCommand = $fm->newEditCommand('tidsstemplingTidsrom', $_POST["id"]); if ($helg==false) { $editCommand->setField("Tid ut", "16:00:00"); $editCommand->setField("Tidssone", "Arbeid"); } else { $editCommand->setField("Tid ut", $_POST["tidut"]); $editCommand->setField("Tidssone", "Fritid");} $editCommand->setField("Utlogging", 'Manuelt'); $result = $editCommand->execute();

Hvis klokkeslettet for utloggingen er før kl. 16, blir navnet logget ut med tidssone “Arbeid”, eller “Fritid” hvis det er helg. Er tidspunktet etter kl. 16, og innloggingen før kl. 16 og ikke helg vil tidssonen bli satt til “Arbeid”, og avsluttet med klokkeslettet “16.00.00”, som er siste tidspunkt for “Arbeid”. Er det helg vil tidssonen alltid bli satt til “Fritid” og tiden fra $_POST[“tidut”]..

18

if (!isset($helg)) { $recnew = $fm->createRecord('tidsstemplingTidsrom'); $recnew->setField('Navn', $_POST["navn"]); $recnew->setField('Dato', $fmdato); $recnew->setField('Tid inn', '16:00:00'); $recnew->setField("Tid ut", $_POST["tidut"]); $recnew->setField("Utlogging", 'Manuelt'); if (isset($sonenavn, $aktivitet)) { $recnew->setField('Tidssone', $sonenavn); $recnew->setField('Aktivitet', $aktivitet); } else {$recnew->setField('Tidssone', 'Fritid');} $resnew = $recnew->commit(); }

Koden ovenfor, som kun blir kjørt hvis det er etter kl. 16 og ikke helg, legger til en ny oppføring. Siden forrige oppføring ble logget ut med “Arbeid” kl. 16.00, må en ny oppføring legges til med tiden som har gått fra kl. 16 og til utloggingstidspunktet. Er det en aktivitet og sone oppført i databasen for denne dagen, blir den lagt til.

} else { $editCommand = $fm->newEditCommand('tidsstemplingTidsrom', $_POST["id"]); $editCommand->setField("Tid ut", $_POST["tidut"]); $editCommand->setField("Tidssone", "Fritid"); $editCommand->setField("Utlogging", 'Manuelt'); $result = $editCommand->execute(); }

Hvis innlogging er etter 16:00:00, vil utloggingen bli utført med tidssone “Fritid” og utloggingstidspunktet.

}} else { echo "<p>Tidspunkt feil!</p><a href='loggut.php'>Prøv å logge ut igjen</a>";}

Hvis utloggingstidspunktet i loggut.php ikke er innenfor samme time som det nåværende tidspunktet, vises en feilmelding.

<div id="main"> <h1>Du er logget ut!</h1> <p> <b>Navn: </b> <?php echo $_POST["navn"]; ?><br> <b>Tid Ut: </b> <?php echo $_POST["tidut"]; ?><br> </p> </div> </body> </html> <?php include 'autooffline.php'; ?>

Ved en vellykket utlogging vises en melding med navn og tid ut. Filen autooffline.php er inkludert for å lage en tekstfil med de som nå er innlogget.

19

autologgut.php

$findCommand5 =& $fmauto->newFindCommand('tidsstemplingTidsrom'); $findCommand5->addFindCriterion('Dato', $dateauto); $findCommand5->addFindCriterion('Tid inn', "*"); $findCommand5->addFindCriterion('Tid ut', "="); $result5 = $findCommand5->execute(); if (FileMaker::isError($result5)) { } else { $records5 = $result5->getRecords();

Databasesøket er avgrenset til de som har logget inn, og ikke logget ut, for dagens dato.

$timeauto=strftime("%H:%M:%S"); $dateauto=strftime("%m.%d.%Y"); $tidutauto="16:10:00"; $tidutauto2="23:10:00"; foreach ($records5 as $record) { if ($timeauto>$tidutauto2) { if ($record->getField('Dato')==$dateauto && $record->getField('Tid inn')<"16:00:00" ) { $editCommand = $fmauto->newEditCommand('tidsstemplingTidsrom', $record->getRecordID()); if ($helgauto==false) { $editCommand->setField("Tid ut", "16:00:00"); $editCommand->setField("Tidssone", "Arbeid"); } else { $editCommand->setField("Tid ut", "23:00:00"); $editCommand->setField("Tidssone", "Fritid"); } $editCommand->setField("Utlogging", 'Automatisk'); $result = $editCommand->execute(); }}

Hvis kl. er etter 23:10:00 kjøres et søk på alle for dagens dato som har logget inn før kl. 16. De som blir funnet, blir logget ut med tidspunkt 16:00:00, tidssone “Arbeid”, og utlogging satt til “Automatisk”. Er det helg er tidspunktet 23:00:00, og tidssone “Fritid”.

if ($timeauto>$tidutauto2) { if ($record->getField('Dato')==$dateauto && $record->getField('Tid inn')>"16:00:00" ) { $editCommand = $fmauto->newEditCommand('tidsstemplingTidsrom', $record->getRecordID()); $editCommand->setField("Tid ut", "23:00:00"); $editCommand->setField("Tidssone", "Fritid"); $editCommand->setField("Utlogging", 'Automatisk'); $result = $editCommand->execute(); }}

Hvis kl. er etter 23:10:00 kjøres et søk på alle for dagens dato som har logget inn etter kl 16. De som blir funnet blir logget ut med tidspunkt 23:00:00, tidssone “Fritid”, og utlogging satt til automatisk.

Offline

autooffline.php

$findListe =& $fmautooffline->newFindCommand('tidsstemplingTidsrom');

20

$findListe->addFindCriterion('Dato', $datoliste); $findListe->addFindCriterion('Tid inn', "*"); $findListe->addFindCriterion('Tid ut', "="); $resultListe = $findListe->execute(); if (FileMaker::isError($resultListe)) { } else { $recordsListe = $resultListe->getRecords();

Databasesøket er avgrenset til de som har logget inn, og ikke ut for dagens dato.

foreach ($recordsListe as $record) { $listenavn = $record->getField('Navn'); $parts = explode('.', $record->getField('Dato')); if (isset($parts[0],$parts[1],$parts[1])) { $listedato = $parts[1] . '.' . $parts[0] . '.' . $parts[2];} $listetidinn = $record->getField('Tid inn'); $listetidut = $record->getField('Tid ut'); $liste[]= addslashes($listenavn).' '; $liste[]= addslashes($listedato).' '; $liste[]= addslashes($listetidinn).' '; $liste[]= addslashes($listetidut).' '; if (!empty($liste)) { file_put_contents("liste.txt", implode(PHP_EOL, $liste)); }}} if (!isset($liste)){ file_put_contents("liste.txt", "");} ?>

Datoen som ligger i databasen er d.m.y (dag, måned, år), og blir konvertert til m.d.y (måned, dag, år). Sammen med navn, tid inn og tid ut, blir det lagt til i matrisen $liste. Funksjonen addslashes blir brukt for å legge til skråstrek før tegn som må “escapes”. F.eks ‘ og “. Verdiene i $liste blir puttet i liste.txt.

Admin

admin.php

<?php session_start(); $brukernavn = ""; $passord = ""; $brukerError = ""; $passError = ""; if(isset($_POST['passlogin'])){ $brukernavn = $_POST['brukernavn']; $passord = $_POST['passord']; if($brukernavn === 'admin' && $passord === 'passord'){ $_SESSION['login'] = true; header('LOCATION:admin_meny.php'); die(); } if($brukernavn !== 'admin')$brukerError = 'Ugyldig brukernavn'; if($passord !== 'passord')$passError = 'Ugyldig passord'; } ?>

Hvis brukernavn og passord er lik “admin” og “passord” blir $_SESSION['login'] satt til “true”. Etter det blir man vidresendt til admin_meny.php. Ved feil brukernavn og passord vises en feilmelding.

21

admin_meny.php

<?php session_start(); if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1200)) { // Forrige forespørsel var mer enn 20 minutter siden session_unset(); // Unset $_SESSION variablen session_destroy(); // Ødelegg session data } $_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp

En en sjekk som logger ut etter 20 minutter med inaktivitet. if(isset($_SESSION['login']) && $_SESSION['login'] === true) { ?>

Hvis man er logget ut vises siden.

<div id="main"> <div id="index"> <div id="index1"><a href="liste.php">Liste</a></div> <div id="index2"><a href="offlineliste.php">Offline liste</a></div> <div id="index3"><a href="velg_liste.php">Datobasert liste med tidssone</a></div> <form action="<?php echo $_SERVER['PHP_SELF'];?>" class="oneline" method="post"> <input type="submit" id="css3button" class="oneline" name="adminloggut" value="Logg Ut"> </form> <?php if( isset($_POST["adminloggut"]) ) { $_SESSION['login'] = false; header('LOCATION:admin.php');} ?> </div> </div>

En admin-meny vises hvis man er logget inn. Hvis loggutknappen blir trykket på blir $_SESSION[‘login’] satt til “false” og man blir vidresendt til admin.php.

<?php } else { header('LOCATION:admin.php'); } ?>

Hvis man ikke er logget inn, eller har blitt logget ut p.g.a inaktivitet, blir man sendt til admin.php. liste.php

<?php session_start(); if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1200)) { session_unset(); session_destroy(); }

Automatisk utlogging etter 20 minutter med inaktivitet. if(isset($_SESSION['login']) && $_SESSION['login'] === true) {

Denne siden krever også administrator innlogging, og vises kun hvis man er innlogget. $findCommand =& $fm->newFindCommand('tidsstemplingTidsrom'); $findCommand->addFindCriterion('Dato', $date); $findCommand->addFindCriterion('Tid inn', "*"); $findCommand->addFindCriterion('Tid ut', "="); $result = $findCommand->execute();

22

if (FileMaker::isError($result)) { if ($result->getMessage()=="No records match the request") {} elseif (FileMaker::isError($result)) { if ($result->getMessage()=="Unable to open file") { $page = $_SERVER['PHP_SELF']; $sec = "1800"; header("Refresh: $sec; url=$page"); $side="adminphp"; include 'meny.php'; echo "<div id='main'>"; echo "<p><b>Kunne ikke koble til databasen!</b></p>"; echo "<h1>Navn logget inn (Offline)</h1>"; ---- offlineliste kode her--- else { echo "Error: " . $result->getMessage() . "\n"; exit; }}}

Databasesøket er avgrenset til alle som har logget inn, men ikke ut. Hvis ingen oppføringer er funnet, vises ingen feilmelding. Hvis ingen fil er funnet, vises en offline versjon av listen. For alle andre uvanlige feil vises det kun en feilmelding.

$records = $result->getRecords(); ?> <div id="main"> <h1>Navn logget inn</h1> <table id="liste"> <tr> <th>Navn</th> <th>Dato</th> <th>Tid Inn</th> <th>Tid Ut</th> <th>Opprop</th> </tr> <?php echo "Antall oppføringer: "; $count = count($records); echo $count ."<br/><br/>";?> <?php foreach ($records as $record) { echo "<tr>"; echo "<td>" .$record->getField('Navn') ."</td>"; echo "<td id='liste-dato'>"; $parts = explode('.', $record->getField('Dato')); if (isset($parts[0],$parts[1],$parts[1])) { print_r($parts[1] . '.' . $parts[0] . '.' . $parts[2]);} echo "</td>"; echo "<td id='liste-tidinn'>" .$record->getField('Tid inn') ."</td>"; echo "<td id='liste-tidut'>" .$record->getField('Tid ut') ."</td>"; echo "<td id='liste-checkbox'><input type='checkbox' value='unchecked' /></td>"; echo "</tr>"; } ?> </table> </div>

Oppføringene i databasen blir lagt inn i og presentert i en tabell. <?php } else { header('LOCATION:admin.php'); } ?>

Hvis man ikke er logget inn som administrator, blir man sendt til admin.php.

offlineliste.php

<?php session_start();

23

if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1200)) { session_unset(); session_destroy(); }

Automatisk utlogging etter 20 minutter med inaktivitet.

if(isset($_SESSION['login']) && $_SESSION['login'] === true) { ?> echo "<div id='main'>"; echo "<h1>Navn logget inn (Database offline. Leser fra fil)</h1>"; echo "<br/><table id='listeoffline'>"; echo "<tr>"; echo "<th>Navn</th>"; echo "<th>Dato</th>"; echo "<th>Tid Inn</th>"; echo "<th>Tid Ut</th>"; echo "<th>Opprop</th>"; echo "</tr>"; echo "<tr>"; $i = 0; $i2 = 0; $txtliste = fopen("liste.txt", "r"); if ($txtliste) { while (($line = fgets($txtliste)) !== false) { $i++; if ($i2<4) {$i2++;} else { $i2=1;} echo "<td class='txt" .$i2 ."'>".$line."</td>"; if ( (($i) %4)==0) { echo "<td id='liste-checkbox'><input type='checkbox' value='unchecked' /></td>"."</tr><tr>";} } } else {} echo "</tr>"; echo "</table>"; echo "</div>"; ?>

En sjekk for administratorinnlogging blir kjørt. Etter dette vil liste.txt blir åpnet og presentert i en tabell med en sjekkboks på slutten av hver linje.


Hvis man ikke er logget inn som administrator, blir man sendt til admin.php. velg_liste.php

<?php session_start(); if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1200)) { session_unset(); session_destroy(); }

Automatisk utlogging etter 20 minutter med inaktivitet. if(isset($_SESSION['login']) && $_SESSION['login'] === true) { $findCommand =& $fm->newFindCommand('tidsstemplingTidsrom'); $findCommand->addFindCriterion('Tid inn', "*"); $result = $findCommand->execute();

Databasesøket blir avgrenset til de som har logget inn. if (FileMaker::isError($result)) {

24

if ($result->getMessage()=="No records match the request") { echo "<div id='main'> <h1>Ikke noe resultat!</h1>"; exit;} else { echo "Error: " . $result->getMessage() . "\n"; exit; } } $records = $result->getRecords(); ?>

En egen feilmelding vises hvis det ikke finnes noen oppføringer for det som søkes etter, siden det er en vanlig hendelse. For andre feilmeldinger vises feilmeldingen fra Filemaker direkte.

<script> $(function() { var availableTags = [ <?php foreach ($records as $record) {?> "<?php $datovelg = explode('.', $record->getField('Dato')); $datovelgsamlet = $datovelg[1] . '.' . $datovelg[0] . '.' . $datovelg[2]; if (!isset($datoforrige)) {print_r($datovelg[1] . '.' . $datovelg[0] . '.' . $datovelg[2]);} if (isset($datoforrige)) { if ($datovelgsamlet!=$datoforrige) { print_r($datovelg[1] . '.' . $datovelg[0] . '.' . $datovelg[2]);}} $datoforrige=$datovelg[1] .'.' .$datovelg[0] .'.' .$datovelg[2];?>", <?php }?> ]; $( "#tags" ).autocomplete({ source: availableTags }); }); </script>

Skriptet bruker en blanding av JavaScript og PHP. Dato-oppføringer blir splittet opp og plassert i $datovelg -matrisen. Rekkefølgen blir forandret fra m.d.y til d.m.y, og lagt til i $datovelgsamlet. Fordi det ofte er flere oppføringer for hver dato, kjøres det en sjekk for om datoen er lik den forrige. Hvis den ikke er lik den forrige datoen, blir den skrevet ut og lagt til som en “tag” i JavaScriptet. Verdiene vises så i #tags feltet lengre ned på siden.

<div id="main"> <form action="<?php echo $_SERVER['PHP_SELF'];?>" class="oneline" method="post"> <input id="tags" name="datoliste" class="oneline" autocomplete="off" placeholder="Dato" autofocus> <input type="submit" id="css3button" class="oneline" value="Velg"> </form>

Listen med datoer som er funnet i databasen vises i dette feltet.

<?php if (isset($_POST['datoliste']) ) { if(!empty($_POST['datoliste'])) {$postdatoliste=$_POST['datoliste'];}} ?> <?php if (!isset($postdatoliste)) { echo "<p>Skriv inn full dato, eller delvis dato.</p><p>F.eks 02.2014 for å velge en dato i februar 2014</p>"; } ?> <div id="velgliste"> <?php if (isset($postdatoliste)) { $datovelg2 = explode('.', $postdatoliste); if (isset($datovelg2[0], $datovelg2[1], $datovelg2[2])) {$datoliste= $datovelg2[1] .'.' .$datovelg2[0] .'.' .$datovelg2[2];}

Hvis verdien ikke er tom, blir datoen som er skrevet og postet tidligere på siden plassert i $postdatoliste. Siden datoene fortsatt lagres som m.d.y i databasen må datoen konverteres fra d.m.y som vises for brukeren. Etter konverteringen plasseres datoen i $datoliste variablen.

25

if (isset($datoliste)) { foreach ($records as $record) { if ($record->getField('Dato')==$datoliste) { echo "<tr>"; echo "<td>" .$record->getField('IDnr') ."</td>"; echo "<td>" .$record->getField('Navn') ."</td>"; echo "<td id='liste-dato'>"; $parts = explode('.', $record->getField('Dato')); print_r($parts[1] . '.' . $parts[0] . '.' . $parts[2]); echo "</td>"; echo "<td id='liste-tidinn'>" .$record->getField('Tid inn') ."</td>"; echo "<td id='liste-tidut'>" .$record->getField('Tid ut') ."</td>"; echo "<td id='liste-tidut'>" .$record->getField('Tidssone') ."</td>"; echo "<td id='liste-tidut'>" .$record->getField('Aktivitet') ."</td>"; echo "</tr>"; }} echo "</table>"; }} ?> </div> </div>

Oppføringene for datoen som ble valgt, presenteres i en tabell. Datoen i databases må igjen konverteres fra m.d.y til d.m.y.


Hvis brukeren ikke er innlogget blir den sendt videre til admin.php.

Videreutvikling

Videreutvikling av denne løsningen krever kompetanse om php, css og html. For en som kan disse programmeringsspråkene, er det greit å vidreutvikle løsningen.

26

5.2 Filemaker Go løsning

Oppbygging

Logg inn: Systemet sender tiden inn direkte til databasen. Systemet har oversikt over hvem som er logget inn. Den holder oversikt om det er arbeidsorientert dag eller fritidsprogram på det tidspunktet man logger inn. Logg ut: Systemet sender tiden ut direkte til databasen. Systemet fjerner utloggede personer fra oversikten. Den holder oversikt om det er arbeidsorientert dag eller fritidsprogram på det tidspunktet man logger ut. Om noen har logget seg inn på et arbeidsorientert tidspunkt og logget ut på et tidspunkt med fritidsprogram, logger systemet personen ut når arbeidsorienterte tidspunktet slutter og logger personen inn på tidspunktet fritidsprogrammet starter. Inneliste: Systemet viser en liste av oversikten over innloggede personer. Personer på listen skal kunne markeres etter å ha blitt ropt opp. Innelista skal ikke være tilgjengelig til enhver. Brukervennlighet: Systemet må på grunn av varierende kunnskap og erfaring, være meget brukervennlig. Få knapper og få muligheter til å gjøre noe galt er nødvendig. Flyten skal være rask og all beskjed skal stå i et enkelt, klart og tydelig språk. Brukervinduet skal være tilpasset til et nettbrett

Innlogging

Innloggingssystem laget med Filemaker Pro 12. Filemaker er en programserie for å lage databaser med diverse funsjoner. Filmaker er primært laget for PC-er, men kan brukes på nettbrett med Filemaker Go. Dessverre støtter ikke Filemaker Go alle funsjoner i Pro versjonene. Filmaker lager databaser i tre hoveddeler: tabeller, layout og skript. Tabeller angir hvor dataene lagres, hvordan de lagres, og i hvilket format. Layout er hvordan ting ser ut på skjermen. Den kan påvirke hvordan ting registreres og hvordan skriptene reagerer, så den kan ikke undervurderes. Hver av layoutene har flere skript, noen felles og noen individuelle. Skriptene forteller databasen hva den skal gjøre. Denne delen er det som ligner mest på programeringsspråk. Systemet som ble laget i Filemaker inneholder en testdatabase, inn- og utloggingsystemer og en liste over personer som er inne. Den har også en klokke som viser tiden. Testdatabasen er lagd for å ha en enkel database å teste systemene på. Fontenehusets database er ganske komplisert og er ikke enkel å integrere. Testdatabasen gjør det enklere å teste funksjonene som er nødvendig for at systemet skal fungere. Testdatabasen er bygget opp av tre tabeller. Et for personregister, et for loggregister og et for register for spesielle dager i løpet av året. De er interne tabeller som brukere ikke direkte skal forholde seg til. De har layout for at man skal kunne administrere og teste systemet og sjekke om informasjonen har havnet på rett sted.

27

Personregistertabellen er der infoen om personene som er lagret i databasen står. Testdatabasen har info om fornavn, etternavn, et unikt ID-nummer og medlemsnummer for fullverdige medlemmer. Loggregistertabellen er hvor en persons inn- og uttider blir registrert. Det unike ID-nummeret blir registrert i loggregisteret for å koble personen og tidspunktene sammen. Sammen med ID-nummeret utgjør dato den unike ID-koden i denne tabellen. Tabellen kan registrere fire forskjellige tidspunkter, en inn og en ut for arbeidsorientert dag og en inn og en ut for dager med fritidsprogram. Den har også et tekstfelt for beskrivelse av hva fritidsprogrammet er. Tabellen for registeret av spesielle dager registrerer hva som skjer på dager med fritidsprogram. Den registrerer datoen for dagen, hva som skjer og om det skal registreres som fritidsprogram. Eksempler er påskeaften og julaften. Tabellene inneholder den informasjonen som trengs for å teste om systemet kan registrere ønsket informasjon.

Meny

Menylayouten har tre knapper synlige; logge inn/ut med navn, logge inn/ut med medlemsnummer og innstillinger. Ved å trykke på knappene går man videre til layouten beskrevet av knappene.

Som bildet viser, er knappene til å logge inn/ut med navn og å logge inn/ut med medlemsnummer godt synlig, og knappen til innstillinger er i øverste høyre hjørne. Dette er for å tiltrekke oppmerksomheten til de to førstnevnte knappene. Menylayouten har ingen tabell og ingen skripts.

28

Innstillinger

Innstillinger-layouten har ingen tilhørende tabell, men har fem knapper. Fire av dem går til layout som beskrevet. Knappen, hvor det står "Logg ut glemte registreringer" starter skriptet "AlleInne". Skriptet som blir utført registrerer ut-tider på alle som er registrert inn og som ikke har registrert ut.

Skriptet "AlleInne" skaper en loop som går igjennom hver registrering i loggregistreringen og kjører skriptet “LogGlemte” for hver registrering.

Go to Layout ["Inlogging"(Inlogging)]] Go to Record/Request/Page [First] Loop Perform Script ["LogGlemte"] Go to Record/Request/Page [Next; Exit after last] End Loop

Skriptet går først til innregistreringslayoutet og går til den første registreringen. Deretter utfører den skriptet "LogGlemte" på registreringen for å gå til neste og utføre samme skriptet. Etter at skriptet har utført "LogGlemte" på den siste registreringen, avsluttes skriptet. Skriptet "LogGlemte" registrerer ut innregistrerte som har glemt det. Avhengig av om det enten er arbeidsorientert dag eller dag med fritidsprogram, samt tidspunkt, registreres forskjellige tidspunkter.

29

If [Inlogging::InnReg ≠ "" and Inlogging::UtReg = ""] If [Inlogging:: InnReg < Time ( 12; 0; 0)] Set Field [Inlogging::UtReg; Inlogging::InnReg + Time ( 4; 0; 0)] Else Set Field [Inlogging::UtReg; Time ( 16; 0; 0)] End If Else If [Inlogging::InnRegEks ≠ "" and Inlogging::UtRegEks = ""]] If [Inlogging:: InnReg < Time ( 16; 0; 0)] Set Field [Inlogging::UtRegEks; Inlogging::InnRegEks + Time ( 4; 0; 0)] Else Set Field [Inlogging::UtRegEks; Time ( 20; 0; 0)] End If End If

Skriptet sjekker først med en If-setning om feltet Inlogging::InnReg inneholder noe og om feltet Inlogging::UtReg er tom. Hvis utfallet er sann, sjekker skriptet om tidspunktet som er registrert i Inlogging::InnReg er registrert før 12.00. Hvis setningen er sann, registrerer skriptet i Inlogging::UtReg innregistreringstidspunktet pluss fire timer frem. Hvis setningen er falsk, registreres det kl. 16.00 i Inlogging::UtReg. Hvis en første If-setningen er falsk, går skriptet videre til neste Else If []. Den sjekker Inlogging::InnRegEks inneholder noe og om feltet Inlogging::UtRegEks er tom. Hvis utfallet er sann, sjekker skriptet om tidspunktet som er registrert i Inlogging::InnRegEks er registrert før 16.00. Hvis setningen er sann, registrerer skriptet i Inlogging::UtRegEks innregistreringstidspunktet pluss fire timer frem. Hvis setningen er falsk, registreres det kl. 16.00 i Inlogging::UtRegEks.

Person

Tabellen «Person» er en del av test-databasen og inneholder fem felter. «Fornavn» og «Etternavn» er et reint tekstfelt hvor feltets navn beskriver hva som skal skrives inn. «MedlemsNr» er et reint nummerfelt hvor medlemsnummeret, om man har, skal skrives inn. «Løpenummer» er et nummerfelt hvor et serienummer tildeles automatisk. Dette er også tabellens ID-nummer. «Navn» er et tekstfelt hvor innholdet kalkuleres med formelen «Fornavn + " " + Etternavn».

Layouten «Person» inneholder bare feltene fra sin egen tabell. Den inneholder ingen skript.

30

Inlogging

Tabellen Inlogging er fra test-databasen og inneholder alt som har med ut- og inn-registreringer. Tabellen inneholder åtte felter. Løpenummer er et nummerfelt som er lenket til tabellen «Person» i feltet med samme navn. Det er for å lenke tidspunkene med en person. Feltet «Dato» er et datofelt som automatisk registrerer datoen når registreringen blir skapt. Sammen med feltet «Løpenummer» utgjør feltet Dato ID-en til tabellen. Feltene «InnReg», «UtReg», «InnRegEks» og «UtRegEks» er alle tidsfelter. De utgjør feltene hvor inn og ut tidspunktene blir registrert. Fritidsprogram er et tekstfelt som inneholder hva slags fritidsprogram som er registrert, når det er nødvendig. «Inne» er et tekstfelt som bare brukes i layouten «HvemErInne».

Layouten bruker alle feltene, unntatt Inne. Den har også feltet «Navn» fra tabellen «Person». Den inneholder ingen skript.

31

Fridager

Tabellen «Fridager» registrerer hvilke hele dager har fritidsprogram. Tabellen har tre felter. «Dato» er primernøkkelen. Den er også lenket til feltet «Dato» i tabellen «Inlogging». Fritidsprogram er et tekstfelt hvor det står om det er et fritidsprogram eller ikke. «NavnBegivenhet» gir en kort beskrivelse av fritidsprogrammet.

Layouten har bare felt fra tabellen sin. Den har ingen skript.

32

HvemErInne

Tabellen «HvemErInne» har bare feltet dato. Det er et datofelt som bruker årstall på fire nummere. Feltet er også lenket til felte Dato i tabellen Inlogging. Innholdet i den kan også bli overskrevet.

Layouten bruker feltet fra tabellen sitt øverste venstre hjørne. Hva man ser om hvem som er inne blir laget av en Portal. Portalen tar de registreringene i tabellen Inlogging som har samme dato som feltet Dato, og viser dem som en liste. Feltene som lista viser er «MedlemsNr», «Navn», «InnReg/InnRegEks» og «Inne». «Inne» vises som en sjekkboks som man kan krysse av etter at navnet er ropt opp.

33

Portaler er et felt i en layout som viser innehold fra andre tabeller, enn den som layouten tilhører. Med Portaler kan man velge ut hvilken av feltene som vises, velge ut bestemte registreringer og sortere lista etter flere felter. Skriptet "DagsDato" registrerer dagens dato i feltet «Dato».

Inset Current Date [Select; HvemErInne::Dato]

SøkNr og SøkNavn

Tabellene «SøkNr» og «SøkNavn» utgjør inn- og utloggingssystemet til versjon Filemaker. Siden tabellene gjør samme funksjon, ligner de på hverandre. Forskjellen er at den ene bruker navn og den andre bruker medlemsnummer til å søke opp personen som skal registrere seg. Begge to har fem felter. Felles har de «DagsNavn», «Dato», «TidNå» og «Varsling». Tabellen «SøkNr» har feltet «MedlemsNr» for seg selv og tabellen «SøkNavn» har «Navn». «DagsNavn» er et kalkulasjonsfelt som kalkulerer ved hjelp av datoen navnet på dagen. «Dato» er et datofelt som registrerer datoen når registreringen blir laget. «TidNå» er et tidsfelt som benyttes av visse skript. «Varsling» er et tekstfelt hvor diverse varsler som dukker opp blir skrevet i.

Tabellen til SøkNr

Tabellen til SøkNavn For brukerne ser layoutene til «SøkNr» og «SøkNavn» enkle. For utvikleren er layoutene alt annet enn enkel. Brukeren ser skjermbildene til venstre. Til høyre synes alle feltene som ellers

34

er usynlige. Feltene brukeren ser er Navn, MedlemsNr og Validering. Validering er likt på begge layoutene, den skriver beskjeder om hendelser. På layouten «SøkNr» skriver man inn medlemsnummeret slik at navnet til medlemmet dukker opp i feltet Navn. Dette felte henter dataene fra tabellen Person. På layouten «SøkNavn» er det navnet man skriver inn og medlemsnummeret som blir hentet opp. En liste over mulige navn dukker opp mens man skriver som samsvarer med det man har tastet inn. Den seneste versjonen av Filemaker Go støtter dessverre ikke denne funksjonen. De usynlige feltene brukes av skriptene til å huske og til å bruke informasjon.

Søk med nummer slik brukeren ser det.

Søk med nummer med alle felter synlige

Søk med navn slik brukeren ser det

35

Søk med navn med alle felter synlige

Disse layoutene kjører flere skript, noen felles og noen individuelle. Skriptet "Open" starter automatisk når man åpner layouten. Den sletter tabellens registrering og starter en ny registrering. For å skrive noe, må man starte en registrering. Siden den informasjonen lagres i andre tabeller, er det ønskelig å slette registreringene som lagres. Dette er for å spare plass og å hindre at tidligere registreringer skaper feil og forvirring. Scriptene "ValideringMedlemsNr" og "FeilNavn" validerer det brukeren har skrevet inn i hver sin layout, SøkNavn for "FeilNavn" og SøkNr for "ValideringMedlemsNr".

Delete Record/Request [No dialog] New Record/Request If [Person::Navn = ""] Set Field [SøkNr::Varsling; "Tallet eksisterer ikke, prøv på nytt"] Set Field [SøkNr::MedlamsNr; ""] Else Set Field [SøkNr::Varsling; "Ok"] End If If [Person::Løpenummer = ""] Set Field [SøkNr::Varsling; "Navnet er ikke i databasen. Prøv på nytt"] Set Field [SøkNavn::Navn; ""] Go to Field [SøkNavn::Navn] Else Set Field [SøkNavn::Varsling; "Ok"] End If

Scriptene validerer feltene når registreringen lagrer dataene. Det finnes mulighet til å kjøre skriptene tidligere under valideringstidspunktet, men da får ikke feltene som henter dataene fra andre tabeller tid til å skaffe dem. Hvis valideringen feiler, sender skriptet et varsel til feltet Varsling og tømmer inntastingsfeltet. Hvis valideringen er en suksess, sender den bare en melding om at alt er ok.

36

Knappen Inn/Ut starter skriptene «NavnReg» og «NummerReg» i «SøkNavn» og «SøkNr» respektivt. Disse skriptene starter registreringen av inn- og ut-tiden. Selve skriptet er en ekstra validering av navnet/nummeret som blir søkt etter.

Go to Field [SøkNavn::Validering] Perform Script ["FeilNavn"] If [SøkNavn::Navn = ""] Set Field [SøkNavn::Validering; "Navnet er ikke i databasen. Prøv på nytt"] Exit Script [Result: SøkNavn::Navn = ""] End If Perform Script ["NyDag"] Go to Field [SøkNr::Validering] Pause/Resume Script [Duration (seconds): 2] If [SøkNr::MedlemsNr = ""] Set Field [SøkNr::Varsling; "Trenger et nummer"] Exit Script [Result: SøkNr::MedlemsNr = ""] End If Perform Script ["NyDag"]

Skriptene sjekker om noe er skrevet i inntastingsfeltene. Hvis ingen ting er skrevet i felter eller er feil skrevet, sender den en beskjed til feltet «Validering» og stopper skriptet. Hvis alt er ok, starter skriptet «NyDag». Skriptet «NyDag» er skriptet som sorterer hvilket tidspunkt som blir registrert. Den ser om man tidligere registrert inn og/eller ut sorterer dertil.

Insert Current Time [Select; GlobaleFelt::TidNå] Insert Current Date [Select; Inlogging::Dato] If [Inlogging::InnReg = 0 and Inlogging::InnRegEks = 0] Perform Script ["Inn"] Go to Layout["Validering Nr" (SøkNr)] Set Field [SøkNr::Varsling; "Du er logget inn"] Else If [Inlogging::UtReg = 0 and Inlogging::UtRegEks = 0] Perform Script ["Ut"] Go to Layout["Validering Nr" (SøkNr)] Set Field [SøkNr::Varsling; "Du er logget inn"] Else If [Inlogging::UtReg ≠ "" or Inlogging::UtRegEks ≠ ""] Show Custum Dialog ["Allerede sjekket ut "; "Personen som sjekker inn, er allerede ute. Start på nytt "] Else Show Custum Dialog ["Noe er galt "; "Få panikk, ring forsvaret "] End If Pause/Resume Script [Duration (seconds): 5] Go to Layout ["Innloggingsdatabase" ()]

Skriptet starter med å registrere tiden nå til feltet TidNå i tabellen GlobaleFelt, og dagens dato til feltet Dato som er i den skjulte Portalen til tabellen inlogging. Ved å sette dagens dato i feltet Dato, finner Portalen dagens inn- og ut-tider til personen. Deretter sjekker skriptet om det er noe i innregistreringene. Hvis det er ingen ting der, starter skriptet "Inn" og fortsetter til layouten Validering Nr. Der skriver skriptet inn en beskjed om at man nå er registrert inn. Hvis det er noe i innregistreringene, starter skriptet neste trinn, som er å sjekke om det er noe i utregistreringene. Hvis det er ingen ting der, starter skriptet "Ut" og fortsetter til layouten “Validering Nr”. Der skriver skriptet inn en beskjed om at man nå er registrert ut.

37

Hvis det er noe i utregistreringene, får man en feilmelding om at man er allerede registrert ut. Hvis det dukker opp noe som kommer forbi sorteringen uten å ha blitt sortert korrekt, dukker det opp en feilmelding. Sorteres man korrekt og enten starter skript "Inn" eller skript "Ut", blir skriptet pauset i 5 sekunder før man blir sendt til Menylayouten, slik at man brukeren får med seg beskjeden om at man har registrert seg. Skriptet "Inn" registrerer inn-tiden til riktig tidssone og tar med seg om det er noe spesielt registreringsdagen/tidspunktet.

If [Fridager::Fritidsprogram = "Ja"] Insert Current Time [Select; Inlogging::UtRegEks] Set Field [Inlogging::Fritidsprogram; Fridager::NavnBegivenhet] Else If [SøkNavn::DagsNavn = "lørdag" or SøkNavn::DagsNavn = "søndag" or SøkNr::DagsNavn = "lørdag" or SøkNr::DagsNavn = "søndag"] Insert Current Time [Select; Inlogging::UtRegEks] Set Field [Inlogging::Fritidsprogram; "Helgeprogram"] Else If [Inlogging::InnReg = 0 and Inlogging::InnRegEks = 0 and GlobaltFelt::TidNå > Time ( 16; 0; 0)] Insert Current Time [Select; Inlogging::UtRegEks] Else If [Inlogging::InnRegEks = 0 and Inlogging ::InnReg = "" and and GlobaleFelt::TidNå < Time ( 16; 0; 0)] Insert Current Time [Select; Inlogging::UtRegEks] If[SøkNavn::DagsNavn = "Onsdag" or SøkNr::DagsNavn = "Onsdag"] Ser Field [Inlogging::Fritidsprogram; "Onsdagmiddag"] End If Else Show Custom Dialog ["Inlogging umulig"; "Klarer ikke å logge inn "] End If

Først ser den om feltet «Fritidsprogram» i tabellen «Fridager» er sann. Er den det, registrerer den inn-tiden i «InnRegEks»-feltet. Samtidig kopierer den innholdet til feltet «NavnBegivenhet» i tabellen «Fridager» over til feltet «Fritidsprogram» i tabellen «Inlogging». Deretter ser den om innholdet i feltet «DagsNavn» i tabellene «SøkNr» og «SøkNavn» er enten lørdag eller søndag. Hvis den er det, registrerer den inn-tiden i feltet «InnRegEks», samtidig som «Helgeprogram» blir skrevet i feltet Fritidsprogram. Hvis de tidligere If-setningene er falske, ser den om feltene «InnReg» og «InnRegEks» er tomme og hvilke klokkeslett er registrert i «TidNå». Hvis klokkeslettet i «TidNå» er før klokken 16.00, registreres tiden i «InnReg». Er derimot det registrerte klokkeslettet etter 1600, registreres tiden i «InnRegEks». Hvis innholdet er i feltet «DagsNavn», registreres «Onsdagsmiddag» i feltet Fritidsprogram. Hvis alle If-setningene er falske, dukker det opp en feilmelding.

38

Skriptet "Ut" registrer tiden ut i riktig tidssone og tar med seg overgangen fra en tidssone til en annen.

Set Field [GlobaleFelt::TidNå] If [Inlogging::UtReg = "" and Inlogging::InnRegEks = "" and GlobaleFelt::TidNå ≤ Time ( 16; 10; 0) and Inlogging::InnReg ≠ ""] Insert Current Time [Select; Inlogging::UtReg] Else If [Fridager::Fritidprogram = "Ja"] Insert Current Time [Select; Inlogging::UtRegEks] Else If [Inlogging::InnReg > 0 and Inlogging::InnRegEks = "" and GlobaltFelt::TidNå > Time ( 16; 0; 0) and Inlogging::UtReg = ""] Insert Calculated Result [Select; Inlogging::UtReg; Time ( 16; 0; 0)] Insert Calculated Result [Select; Inlogging::InnRegEks; Time ( 16; 0; 0)] Insert Current Time [Select; Inlogging::UtRegEks] If[SøkNavn::DagsNavn = "Onsdag" or SøkNr::DagsNavn = "Onsdag"] Ser Field [Inlogging::Fritidsprogram; "Onsdagmiddag"] End If Else If [Inlogging ::InnReg = "" and Inlogging::InnRegEks ≠ "" and GlobaleFelt::TidNå >Time ( 16; 0; 0) and Inlogging::UtRegEks = ""] Insert Current Time [Select; Inlogging::UtRegEks] Else Show Custom Dialog ["Noe er galt"; "Skriptet har tatt ferie. Kontakt programmerer for hjelp"] End If

Først sjekker skriptet om det er noe registrert i feltet «InnReg», og om resten av tids-feltene fra tabellen «Inlogging» er tomme, og om klokka er før 16.10. Hvis den er det, registreres tiden i feltet «UtReg». Deretter sjekker den om feltet Fritidsprogram i tabellen Fridager er sann. Er den det, registreres tiden i feltet «UtRegEks». Deretter sjekker den om det er noe registrert i feltet «InnReg», om resten av tids-feltene fra tabellen Inlogging er tomme og om klokka er etter 16.00. Er den det, registrerer skriptet 16.00 i feltet «UtReg» og feltet «InnRegEks», tidspunktet nå blir registrert i feltet «UtRegEks» og er innholdet i «DagsNavn» onsdag, blir «Onsdagsmiddag» skrevet i feltet «Fritidsprogram». Hvis derimot noe registrert i feltet «InnRegEks», om resten av tids-feltene fra tabellen Inlogging er tomme og om klokka er etter 16.00, registreres tidspunktet nå i feltet «UtRegEks». Hvis alle If-setningene falske, dukker det opp en feilmelding.

GlobaleFelt og ZoomControll

39

GlobaleFelt er en tabell hvor feltene er globale, det vil si at innholdet er tilgjengelig for alle tabeller og layouter. De brukes i systemet som lagringsplass for midlertidige data. Den eneste feltet er tidsfeltet TidNå, som brukes i registreingsskriptene til å sjekke tidspunktet. Skriptet "ZoomControll" starter med en gang databasen åpnes. Den er til for å hindre at brukere til iPaden forstørrer/forminsker og lukker vindu ved uhell. If [PatternCount ( Get ( ApplicationVerson ); "GO")] Adjust Window [Resize to Fit] Freeze Window Set Zoom Level [Lock; 100%] End If

Hvis Filemakerprogrammet er Filemaker Go justerer den vinduet til å passe skjermen, fryser vinduet fast og setter zoomen til 100% fast.

Klokke

"data:text/html, <html> <head> <script type='text/javascript'> --Her starter koden å hente frem klokkeslettet. function startTime() { var today=new Date(); var h=today.getHours(); var m=today.getMinutes(); var s=today.getSeconds(); m=checkTime(m); s=checkTime(s); document.getElementById('time').innerHTML=h+':'+m+':'+s; t=setTimeout('startTime()',500) } function checkTime(i) { if ( i < 10 ) { i = '0' + i } return i } --Her ender koden og formateringen til nummerne begynner </script> <style type='text/css'>  </style> </head> <font size='12' face='Arial'> <body style='text-align:center; border:0; margin:0; padding:0; scrolling:auto'onload='startTime()'> <div id='time'></div> --Her slutter formateingen </font> </body> </html>"

If-setningen sjekker om programmet som åpner databasen er Filmaker Go. Er det Go som åpner filen, justeres vinduet til skjermens størrelse og fryses der, samtidig som zoomprosenten justeres og låses til 100 %.

40

Klokken som vises er et webvindu som viser tiden til maskinen. Webvinduet bruker html-kode for å finne klokka til maskinen og hente tiden.

Forklaring av skript

If [], Else If [], Else og End If utgjør If/Else-setningen til Filemaker. If [] utfører alt skript mellom seg og End If hvis parameteren i parentes er sann. Else If [] kan stå etter If [] og utføre alt skript mellom seg og End If så lenge den egen parameter er sann og If [] sin er falsk. Else utfører skript mellom seg og End If så lenge foregående If [] og Else If er falske. End If markerer slutten på denne If/Else-setningen. Set Field [A; B] setter kalkulasjon B til felt A. Go to Layout [“A”(B)] tar deg til layout B som er laget av tabell A. Go to Record/Request/Page [] tar en til en registrering spesifisert i prangetes. First, Last, Previous og Next er fire av fem spesifikasjonene man kan velge. By Calculation tar deg til en registrering bestemt av en kalkulasjon. På noen av spesifikasjonene kan man velge "Exit after last" for å stoppe skriptet når den er på den siste registrering. Loop utfører alt skript mellom den og End Loop i en løkke. For å stoppe løkken må skriptet imellom stoppe hele skriptet eller bare løkken. Perform Script [] kjører skriptet som står i parentes.

41

6. Testing Fokuset i testene var på de indivduelle systemene, og mindre på sammenligningen mellom dem. Testene ble utført i resepsjonen til Fontenehuset for å gi enklel tilgang til testpersonene. Dette gav også muligheter til å rekrutere mer testpersjonell. Til slutt ble antall gyldige deltagere som gjennomførte testene til 12. Deltakerne prøvde begge systemene med en dags mellomrom. Deltakerne ble delt opp i to grupper der de prøvde hvert sitt system, og byttet om dagen etter. Det var derfor viktig at alle deltakerne deltok begge dagene. Etter hver test fikk deltakerne utlevert et spørreskjema (se vedlegg B for svar på brukertest).

Ovenfor er en grafisk oversikt over flervalgspørsmålene. Svarene viser at de fleste testdeltakerne foretrekker den webbaserte php-løsningen. Begge løsningene hadde problemer (se vedlegg B for utdyping av disse).

42

7. Metode og planlegging Før det ble satt igang å utvikle produktet, ble det planlagt nøye. Det ble laget Use Case kravspesifikasjon, fremdriftsplan, risikoanalyse, virkingsanalyse og sekvensdiagram. Disse ligger ved som vedlegg. For å organisere utviklingen ble det brukt scrum metoden benyttet. Verktøyet som valgt til å organisere dette var Visual Studios Online. Oppgavene ble fordelt over to ukers intervaller (sprint).Fremgangen for hele prosjektet ble evaluert etter hver sprint, og dette dannet grunnlaget for neste sprint.

43

Prosessdokumentasjon

8. Innledning

8.1 Fontenehuset i Oslo

Fontenehuset i Oslo er den første av åtte Fontenehus i Norge. De andre Fontenehus er i Drammen, Stavanger, Tromsø, Bergen, Hønefoss, Kongsberg og en til i Oslo, Oslo Øst.

Fontenehuset bruker i dag en papirliste for å logge ut og inn medlemmer, ansatte, og besøkende. Denne lista føres manuelt inn i Filemaker Pro senere, og viser hvem som har kommet og gått. Det hender ofte at både skrevne navn og tidspunkter er vanskelige å tolke, til og med uleselige, noe som gjør vanskelig å registrerte korrekt. Fontenehuset ønsker seg en bedre databasert løsning for innlogging. Innloggingen må kunne brukes på en iPad, som skal stå i resepsjonen. Formålet er å forenkle jobben som er knyttet til dette i dag. I dette prosjektet skal vi lage en løsning for å gjøre dette enklere. Løsningen skal kunne logge inn og ut ansatte og medlemmer. Samtidig skal den være brukervennlig, og kunne koble seg inn mot databaseløsningen Filemaker Server. Løsningen skal brukes på en iPad, og må fungere på denne.

8.2 Begrensninger Ingen av oss hadde brukt Filemaker Pro som databaseverktøy, så vi måtte lære om Filemaker-serien fra bunnen av. Vi leste om Filemaker Pro og Filemaker Sever fra dokumenter fra Filemaker Inc. Tidlig i prosjektet fant vi ut at det ville ta for liten tid hvis løsningen bare ble laget i Filemaker. Denne grunnen, samt at Filemaker kunne ha begrensninger som kunne gjøre det vanskelig å lage et loggingsystem, gjorde at vi valgte å bruke to forskjellige tilnærminger for å løse problemet. Den ene var med Filemaker og den andre var med PHP. Vi tok hovedansvaret for en av tilnærmingene hver, slik at vi kunne synkronisere arbeidsfremgangen lettere og kunne konsentrere oss om arbeidet, slik at løsningene ble så bra som mulig.

8.3 Prosjektdeltakere Erlend S. Westgaard Gjennomfører bachelor i Andvendt datateknologi. Erlend har kjennskap til programmering i PHP fra to fag tidligere, i tillegg til webutvikling. Gjennom studiet har han også bl.a fått kunnskap om databaser, operativsystem og nettverk, som har blitt brukt i dette prosjektet. Anders Isaksen

44

Anders skal fulføre et tidligere avbrudd studie, Programmering. Der lærte han programmeringsspråket Java. Han har de siste årene vært på Fontenehuset og han var en av initiativtakerne til databasen som nå blir brukt.

9. Mål Gjennom samtaler med Fontenehuset fikk vi oversikt over hvilke mål de hadde med prosjektet som de ønsket å implementere i en løsning:

● De ønsker å få et inn- og utloggingssystem som kan erstatte den papirbaserte løsningen

for alle, unntatt gjester

● Systemet skal være kjapt og brukervennlig

● Løsningen skal fungere for medlemmer, mulige medlemmer, og ansatte

Etter vi hadde avtalt hvordan vi skulle utvikle prosjektet, ble vi enige om noen mål. Disse målene er hva vi ønsket å oppnå med prosjektet:

● Vi vil lære om Filemaker Server, Pro og Go

● Vi var interessert i å lære hvordan webteknologier kan brukes til å utvikle en løsning for

iPad

● Siden det var et ønske fra Fontenehuset, hadde vi som mål å lage et ferdig system som

er klar for implementering når Fontenehuset måtte ønske

● Det er et mål å lage et brukervennlig inn-og utloggingssystem som er koblet inn mot

Filemaker Server.

10. Kravspesifikasjon Etter at vi hadde et møte med Fontenehuset og veiledere for å få en oversikt over prosjektet. Der fremmet Fontenehuset hvilken ønsker de hadde til systemet. Senere, etter vi hadde funnet mer informasjon, hadde vi et møte der vi jobbet med kravspesifikasjonen (se vedlegg A). På møtet lagde vi en liste over hvilke funksjoner som skulle være med og hvordan personer skulle registreres. Noen av forslagene ble forkastet da de ble vurdert som upraktiske å bruke. Vi satt deretter opp en ferdig kravspesifikasjon med kravene til løsningen, og fikk den godkjent av Fontenehuset. Vi vurderte inholdet i kravspesifikasjonen og kom frem til to alternative løsninger som kan bli brukt til å oppfylle kravene. En gjennom å bruke Filemaker Pro til utvikling og en annen gjennom en webbasert PHP-løsning som programmeres. Begge løsningene var interessante for Fontenehuset, og vi sto fritt til å velge løsningsalternativ. Vi valgte å utvikle begge løsningene. Vet å gjøre det ønsket vi å utrede hvilke utfordinger og begrensninger som ligger i hver utviklingsmetode og tilhørende teknologi. Fontenehuset vil da få et sammenligningsgrunnlag og vil kunne se hvilken løsning som best dekker deres behov. Vi studerte databasen til Fontenehuset og oppdaget at databasens struktur var ganske innviklet (se avsnitt Utviklingsfase:Utforsking av database. Sprint 1 ). Etter å ha kommunisert med

45

utvikleren av databasen, uten å ha funnet en løsning på problemene vi hadde (se avsnitt: Utforsking av database. Sprint 1), valgte vi ut at vi skulle lage en testdatabase. Dette gjorde at vi kunne begynne å utvikle inn- og ut-loggingssystemene uten å bli forhindret av problemene vi opplevde. Vi bestemte at testdatabasen bare skulle inneholde de feltene som trengtes. Etter at vi diskuterte med Fontenehuset, ble vi enige om å lage systemene med testdatabasene, siden de også syntes at Fontenehusdatabasen struktur var innviklet. Under akseptansetesten mot slutten av prosjektet, dukket det opp et krav om at løsningene måtte støtte flere registreringer inn og ut. Kravet var allerede oppfylt av PHP-systemet, men ikke av Filemaker-systemet på grunn av at det verken ble spesifisert i kravspesifikasjonen eller dukket opp under noen av korrespondansen mellom oss og Fontenehuset. Det ble avtalt at vi skulle gjøre et forsøk i løpet av et par dager, på å justere Filemaker-systemet slik at den kunne behandle flere registreringer inn og ut. Det ble forsøkt, men på grunn av det begrensete tildsløpet var ikke dette mulig å gjennomføre. Under møtene vi hadde med Fontenehuset, dukket det opp et ønske om at innelista skulle fungere offline. Vi forsøkte det på begge systemene. Offlinefunksjonen til PHP-systemet og Filemaker-systemet var delvis vellykket. Filemaker-systemet fungerte fint på Pro, men ikke når vi forsøkte det på Go. Om det var Go sine begrensninger, innstillinger på Server eller programeringsfeil hadde vi ikke tid til å sjekke. PHP-systemet laget en liste som kunne brukes når databasen var offline, men denne blir ikke bufret lokalt på iPaden. PHP-Systemet er derfor avhengig av at webserveren er oppe for å fungere.

11. Planlegging og metode

11.1 Planlegging Planleggingen av prosjektet startet ved å ha et møte med Fontenehuset. På dette møtet fikk vi en oversikt over prosjektet og hva som forventes av en løsning. Prosjektet var noe vi mente vi kunne arbeide videre med, og vi ble enige om å sette i gang prosjektet. Før vi kunne starte å utvikle en løsning, trengte vi å kartlegge detaljene rundt innhold i en løsning som knytter seg opp mot Filemaker. Vi tok derfor et nytt møte med Fontenehuset, og sammen kom vi fram til en kravspesifikasjon. Da denne var ferdig definert, satt vi opp et use case diagram og et sekvensdiagram. For å definere et brukergrensesnitt, lagde vi et par skisser. Vi tok med skissene til Fontenehuset, og fikk tilbakemeldinger på disse. Vi fikk noen tilbakemeldinger som vi benyttet for å forbedre skissen til brukegrensesnitt. Fontenehuset benytter Filemaker som databaseløsning og vi måtte vi sette oss inn i hvordan vi kunne konstruere en løsning integrert mot Filemaker. Ingen av oss hadde erfaring med Filemaker, og vi startet prosjektet med å finne ut så mye vi kunne om Filemaker produktene. Vi leste den offisielle dokumentasjonen Filemaker hadde for Filemaker Server, og Filemaker Pro. På bakgrunn av dette, fant vi to mulige alternativer for utvikling. Vi tok disse alternativene med videre til Fontenehuset, og vi fikk tilbakemelding på at begge alternativene var godkjent for å utvikle en løsning. Vi besuttet å utvikle begge alternativene, for å kunne sammenligne dem. Gjennom utviklingsprosessen ønsket vi å finne ut nærmere hvordan de ulike alternativene passet til Fontenehusets behov. Ved å samle inn informasjon fra utvikling og testing kunne vi gi to fungerende prototyper, samt testresulteter som Fontenehuset kunne ta stilling til.

46

11.2 Utviklingsmetode Vi valgte utviklingsmetoden Scrum. Scrum er et rammeverk for å håndtere prosjekter, eller mer generelt, arbeid. Den er iterativ og inkrementell. Det betyr at prosjektdeltakerne skal jobbe i en kort tidsintervall (sprint, eller en iterasjon) og så jobbe mot et sluttprodukt for hver sprint. Målene til hver etterfølgende sprint blir evaluert, forhandlet, og lagt til, basert på arbeidet som ble gjort ved slutten av forrige sprint. Det er i teorien en uendelig mengde arbeid som skal gjøres, men scrummetoden deler arbeidet inn i håndterbare tidsintervaller, vanligvis to uker.

Scrum er også et verdisystem der lag jobber sammen mot et felles mål. Fokuset er på arbeidsutbyttet til laget, heller enn arbeidsutbyttet til hvert enkelt medlem. Kommunikasjon, åpenhet, gjennomsiktighet, selvorganisering og verdien til deltakerne som individer og professionelle blir verdsatt. Scrum gjør det lett å vise bidragene prosjektdeltakerne gir til laget som helhet. Det gjør det lettere for alle å føle godt om sin deltagelse, siden det vises så tydelig hva man har bidratt med. I arbeidslivet vil evaluering av fremgang og forretningshensyn fortløpende diktere prosjekters retning. Scrummetoden passer godt inn i denne virkligheten. Scrummetoden tilfører et prosjekt en nødvendig struktur uten unødvendig byråkrati. Denne formen for struktur krever kommunikasjon, og lager rom for samtaler som kanskje ikke hadde funnet sted ellers. Dette gjør at det blir mindre feilkommunikasjon. Redusert feilkommunikasjon resulterer ofte i færre feil. Scrum gir både lagmedlemmer og ledelsen en stemme, og øker kontrollen individene har over det daglige arbeidet. I en bedrift øker dette tilfredsheten til de ansatte. Regelmessige møter og samarbeid hjelper å gjør prosessen mer synlig og gjennomsiktig på et tidlig tidspunkt. Microsofts Visual Studio Online, som bruker scrum, ble brukt til å organisere utviklingsdelen av prosjektet. Arbeidet i prosjektet ble organisert i to-ukers sprinter. Vi fastsatte arbeidsmengden til 4 timer daglig per prosjektdeltaker. Dette gav rom for andre arbeidsoppgaver som ikke må

organiseres i scrum, f.eks dokumentasjon. Hver oppgave ble lagt til i arbeidsloggen som et backlog element. Disse oppgavene fikk tildelt et estimert antall timer, og fordelt mellom oss. Oppgavene ble merket som “to do”, “in progress” eller “done”. Timeantallet ble skrevet ned fortløpende etter hvert som vi jobbet med oppgavene.

(Eksempel på backlog elementer)

47

11.3 Oversikt over sprinter - Sprint1 - utforsking (Fase 1) - Utforske filemaker Server - Utforske Filemaker Go - Utforske Filemaker Pro - Utforsk dagens database - Sprint2 - Innregistrering (Fase 2) - Implementere view for innlogging - Registrere innlogging i databasen - Autocomplete funksjon - Sprint3 - Utlogging, validering (Fase 2) - Implementere valideringsregler for inn- og utlogging - Tidssone validering - Implementere view for utlogging - Sprint4 - Logikk inneliste (Fase 2) - Automatisk utlogging - Caching av view - Inneliste - Sprint5 - Test (Fase 3) - Testing av koden - Brukertest - Teste at løsningen fungerer på Fontenehusets server - Akseptansetest

48

11.4 Burndown charts Nedenfor følger en grafisk oversikt over arbeidet. Y-aksen er arbeid som gjenstår, mens X-aksen er tid som gjenstår. Sprint 1:

Den første sprinten brukte vi til å få erfaring med å bruke scrum og Visual Studios Online. Vi lærte oss hvordan Visual Studios Online fungerer. Den første sprinten var ikke sortert ferdig da tidsperioden begynte og, vi feilberegnet hvor mye tid vi trengte å bruke. Sprint 2:

Under den andre sprinten begynte vi å forstod vi hvordan Visual Studios fungerer bedre, men vi hadde i begynnelsen fremdeles problemer med å registrerte tidspunkter korrekt. Vi arbeidet også i helgene, som også kan påvirke den grafiske fremstillingen av tidsbruk.

49

Sprint 3:

Den tredje sprinten gikk som planlagt. Vi mestret det vi trengte i Visual Studios Online og hadde kommet i et godt tempo med scrum. Det gjenstod litt arbeid på slutten av sprinten som ble fullført i helgen. Sprint 4:

Arbeidsflyten i sprint fire gikk som planlagt. Sprint 5:

Den femte sprinten var sprinten hvor vi arbeidet med testene. Under de to dagene med brukertester, arbeidet vi seks timer om dagen, noe som forstyrret den normale arbeidsflyten.

50

12. Om utviklingsprosessen Vi delte prosjektet innn i tre faser: Fase 1 - Planlegging Fase 2 - Utvikling Fase 3 - Testing

12.1 Utviklingsfaser

12.1.1 Fase 1: Planlegging

Kravspesifikasjonen ble utformet sammen med Fontenehuset i Oslo. Fontenehuset ønsket at løsningen skulle være laget for Filemaker.

Et krav som ikke var spesifisert i kravspesifikasjonen, men dukket opp under testing, var at man skulle kunne registrere seg inn og ut flere ganger daglig.

På grunn av at det var mye ukjent med databasen og Filemaker, var det vanskelig å planlegge i lengre tid fremover. Scrum-metoden var den metoden som vi fant passende til arbeidet med prosjektet. Til dette brukte vi Visual Studio Online som er et enkelt verktøy for organisering med scrum.

12.1.1.1 Sprint 1: Utforsking av database

Vi utforsket den nåværende databasen for å bli bedre kjent med den. Vi fant fort ut at databasen er ganske komplisert, og ville være vanskelig å arbeide med uten utvikleren som har laget den. Nedenfor vises databasens arkitektur:

51

Hver eneste av de grå linjene i skjermbildet er en tabell i databasen. Noen av tabellene ligner på hverandre og flere av tabellene har ganske mange felt. Vi undersøkte hva som skulle til for å bruke en løsning for Filemaker på iPad. Vi fant ut at Filemaker hadde et eget program for iPad, Filemaker Go. Programmet kan vise databaser som ligger på Filemaker Server, eller lokalt på iPaden. Filemaker tilbyr også et API for PHP. En webløsning som kjører på iPad fremstod da som et godt alternativ.

Oppgaven er et prototypingsprosjekt med to prototyper, en laget i Filemaker og en laget med PHP. På den måten var tanken at vi fikk kartlagt eventuelle begrensninger eller mangler med en av teknologiene. Det var vanskelig å få oversikt over hva Filemaker Go kunne gjøre, og hvorvidt den eller en løsning som bruker PHP-APIet ville ha begrensinger som vi kun ville merke etter hvert i utviklingen.

Vi forsøkte å koble til den eksisterende databasen med Filemakers PHP-API. Det viste seg å være problematisk, og det gikk ikke å vise innholdet vi forsøkte å hente fra tabellene. Etter å ha lest dokumentasjonen og søkt etter løsninger på nettet, tok vi kontakt med utvikleren av databasen. Etter å ha sendt noen mail frem og tilbake, hadde vi fortsatt ingen løsning på problemet. Vi kom derfor frem til at databasen var for komplisert å benytte. Vi bestemte oss for å lage en enklere database med alle tabeller og felter som systemene kunne trenge. Det ble laget separate databaser for PHP- og Filemaker Go-løsningene. Det ble gjort for å gi mest mulig frihet til å lage tabeller og felter som best passet til løsningene. PHP-løsningen ville heller ikke ha bruk for layoutelementene som Filemaker Go-databasen inneholder. Filemaker Server tilbyr samme database direkte til Filemaker Pro og Filemaker Go. Løsningen ble utviklet i Pro og senere testet i Go. Filemaker Go kan ikke brukes for å lage en database, kun vise det. Den har også begrenset funksjonalitet i forhold til Pro, selv på visning. Disse begrensningene er ikke godt dokumentert.

12.2 Fase 2: Utvikling

12.2.1 Sprint 2: Innlogging

Allerede under utvikling av innloggingsbiten, begynte løsningene å skille seg ut på inndelingen. I innloggingsdelen skulle det, etter kravspesifikasjonen, være mulig å logge inn ved å søke navnet til personen, eller ved å søke medlemsnummeret til personen. For å gjøre det enklest mulig og mest oversiktlig i Filemaker, ble søk på navn og nummer skilt og inn- og utlogging samlet. PHP-løsningen hadde på et tidlig tidspunkt samme inndeling som Filemaker-løsningen. Videre utvikling gjorde det praktisk å slå innlogging for navn og nummer sammen, slik at man kunne logge inn med navn eller nummer på samme side. Logg ut for navn og nummer ble, til forskjell fra Filemaker-løsningen, implementert på en egen side. Valgene vi gjorde var på grunn av begrensningene med hver av utviklingsmetodene, og at systemet som ble laget skulle være enkle i bruk. Vi var også usikker på hva som var mest brukervennlig av kombinert, eller separat innlogging av navn eller nummer. Siden Fontenehuset ikke hadde noen preferanse på dette, valgte å ha hver vår løsning, og se på de tilbakemeldingene vi fikk fra testene.

52

Samtidig med utviklingen av innlogging, ble det arbeidet videre med testdatabasen. Det ble laget to databaser. Den første ble laget med minimalt med kunnskap om Filemaker, og med mange felter. Den viste seg senere å være unødvendig komplisert og problematisk i utviklingen. Den ble derfor lagt til side. Vi vurderte det som enklere og raskere å begynne på nytt med det vi lærte oss fortløpende om Filemaker, enn å fortsette å utvikle på den databasen vi fikk av Fontenehuset. Det var en fordel for utviklingen av PHP-løsningen at oppsettet til databasen forholdt seg mer eller mindre konstant. For Filemaker Go, var det en fordel at det var mulig å forandre oppsettet til databasen etter det som var mest praktisk for utviklingen av den. PHP-løsningen ble koblet opp mot en av testdatabasene vi lagde da vi begynte utviklingen. Denne databasen ble senere forenklet til å kun inneholde de tabellene og feltene som er relevante for PHP, uten grafiske layoutelementer.

12.2.2 Sprint 2-3: Autocomplete

Autocomplete viser treff for oppføringer som matcher de bokstavene som er skrevet fortløpende. Autocomplete var ønsket av Fontenehuset for å gjøre innloggingen enklere og raskere. Undersøkelsene vi gjorde viste oss at det var mulig å implementere på Filemaker Pro og PHP-løsningen. Autocomplete i Filemaker Pro er innebygget. Dette gjorde autocomplete enkelt å utføre i Filemaker. Vi oppdaget at Filemaker Go ikke støtter autocomplete. Det finnes det ingen løsning på, med mindre Filemaker legger til denne funksjonaliteten i en senere utgave av Go. Siden PHP kjøres på serveren før innholdet vises hos brukeren, er det ikke mulig å bruke dette programmeringsspråket til å tilby autocomplete. Det var derfor behov for noe dynamisk som kjører på klientsiden. Valget av JavaScript for å tilby dette ble da opplagt. Ingen av oss har fra før av inngående kjennskap til JavaScript, og dette ble da en utfordring. Utfordringen ble mindre enn først antatt da vi oppdaget at JavaScript-biblioteket jQuery har en autocompletefunksjon. jQuery gjør det mulig å implementere autocomplete med en lite kode, og uten avanserte kunnskaper om JavaScript. Ved å kombinere jQuery med data PHP henter ut av databasen, ble det implementert en funksjonell autocompletefunksjon. En liten utfordring lå i å sortere ut de som allerede var innlogget, for ikke å vise ikke-relevante oppslag i autocomplete. Dette lot seg løse ved å trekke fra navnene som var innlogget fra lista over navn i databasen, og legge de til i en matrise ved bruk av php. Matrisen ble så brukt av autocomplete i stedet for navnelisten i databasen. Det ble ikke implementert autocomplete for ID i innloggingen, siden det vil bli en stor liste med IDer som kan logge inn. Disse vil ha menge felles tall, og autocomplete vil ikke fungere som tiltenkt, siden alle mulige IDer fra navnedatabasen ligger inne. Autocomplete for utlogging fungerer likt som for innloggingen, men med en liste med navn som har logget inn, og ikke ut den dagen. Det ble også implementert autocomplete for ID, siden lista med IDer som kan logge ut er avgrenset til de som kan logge ut.

12.2.3 Sprint 3: Utlogging

Utover å registrere utlogging, har utloggingsdelen samme kriterier som innlogging. I løpet av innloggingsdelen for Filemaker Go løsningen, fant vi ut at man trenger å inkludere de feltene som det skal registreres i, for at de skal registreres korrekt. Å sette inn feltene man trenger direkte i layouten gjør at man får den informasjonen som tidligere er registrert på personen. Portalen viser en oppføring for hvert navn, og er avgrenset til samme dag. Problemet er at når man registrerer en ny oppføring, vil man overskrive informasjonen til tidligere oppføringer hvis de finnes fra før av den dagen. Løsningen er å ha feltene til innlogginginformasjonen i en Portal

53

som enten bare vil viser infoen som er registrert på dagens dato, ellers er tom. Fordi man kan overskrive oppføringer laget tidligere den dagen, bygger løsningen på at man bare trenger å logge inn og ut en gang om dagen. For å logge ut en som har logget seg inn, er det nødvendig å finne den riktige oppføringen i databasen. For å få PHP-løsningen til å gjøre dette måtte vi finne ut hvordan Filemaker skiller oppføringene fra hverandre. Mens en ny oppføring kan opprettes med å kun verdiene, vil en endring av en eksisterende oppføring kreve at man oppgir IDen. Vi fant ut at hver oppføring har en unik oppførings-id, og den er nødvendig for å kunne redigere oppføringen med PHP-APIet. Oppførings-id ble finnet ved å avgrense et søk på navn, dato og om navnet det ble søkt etter har blitt logget ut før. Når oppførings-id så blir funnet, kan nye verdier for det tomme feltet “Logg ut” bli ført inn i riktig oppføring.

12.2.4 Validering. Sprint 3

Fontenehuset har to tidssoner: arbeid og fritid. På vanlige hverdager varer tidssonen arbeid 00-16, og fritid 16-00. I helgen er det alltid tidssonen fritid. I tillegg til tidssoner, finnes det aktiviteter. Dette kan være spesielle, eller vanlige aktiviteter der medlemmer møtes. Et eksempel på dette er fritidsprogrammet onsdagsmiddag som er hver onsdag. Begge løsningene måtte implementere en automatisk måte for å sette tidssone og aktiviteter. Valideringen av inn- og utlogging, og setting av tidssone var ikke en utfordring å implementere i Filemaker. Filemaker har et automatisk valideringssystem, men den er ikke enkelt å bruke. Når den automatiske valideringen validerer det som blir skrevet og som heller ikke eksisterer, dukker et feilmeldingsvindu opp. Dette forstyrrer flyten i loggingen og kan skremme brukere. Å bruke skript for å validere, var derfor den beste løsningen. Det nye problemet som oppsto, var da scriptet skulle aktiveres. Filemaker har en aktivering som kalles OnObjectValidate, som aktiverer skriptet under aktiveringsfasen. Problemet er at skriptet ikke klarer å finne det skrevne feltet som skal valideres. For at validering skal fungere, må skriptet aktiveres under aktivering OnObjectSave, altså når den lagres. Layouten er en registreringslayout, ikke et søklayout, en Find-tilstand. Find finner det som er registrert i tabellen man søker i. Layouten trenger en oppføring før brukere kan skrive noe, og det som blir skrevet lagres automatisk. Dette kan føre til at informasjon som tilhørte den som søkte sist er der når en ny person skal bruke systemet.For å hindre at tidligere informasjon forvirrer brukere, sletter systemet, når layoutet blir åpnet, oppføringen som var sist og starter en ny, tom oppføring. I PHP var validering en stor utfordring. Innholdet i feltene må bli validert for mange krav før verdiene blir sendt videre til databasen. Det ble implementert validering av navn, dato og tid for innlogging og navn og tid for utlogging. Det blir under inn- eller utloggingen sjekket om bruker er inn- eller utlogget fra før av. For å sette tidssone, blir det sjekket tidspunkt i inn- og utlogging, samt automatisk utlogging. Dette tidspunktet blir brukt for å sette riktig tidssone. Det sjekkes også hvilken dag det er, for å sjekke om det er helg. I tillegg til alt dette, sjekkes det også i databasen etter et aktivitetsprogram, som blir lagt til om det blir funnet. Noen deler av PHP-løsningen er kun tilgjenglig for administrator. Innloggingen for administrator sjekker etter riktig brukernavn og passord kombinasjon, og viser en feilmelding om det er feil. Alle sidene som krever administratorinnlogging sjekker om det er logget inn de siste 15 min. Om det har gått for lang tid siden siste innlogging, blir brukeren sendt videre til innlogging. For å skjule felter som har blitt fylt ut og lagret i variabler, ble det også kjørt noen sjekker. Det gjorde det f.eks mulig å kun vise knappen for innlogging etter navn var blitt satt. Med begrenset skjermplass på iPaden, så var dette nødvendig for å unngå å måtte skrolle på siden. Det gjorde også

54

brukergrensesnittet mer oversiktlig og enklere å bruke. Ved å ha sjekker på samme phpside, før informasjonen blir sendt videre til neste side for lagring i databasen, var det mulig å validere tidlig om brukeren hadde gjort noe feil. F.eks skrevet inn navn i nummerfeltet, eller om feltene er tomme. Fordi noen deltar i både arbeid- og fritidsoner samme dag, måtte det sjekkes tid, for å sette tidssone ved utlogging. Det gjør det mulig å lage en oppføring for arbeid og en for fritid, på samme person. Medlemmene trenger ikke å ta hensyn til det, siden det bestemmes av inn- og utloggingstidspunktet. Implementering av alle disse sjekkene og valideringene var komplisert, og krevde mye prøving og feiling. Siden det er mange kombinasjoner av situasjoner det må sjekkes mot, tok dette lang tid å implementere. I phpløsningen ble det jobbet videre med å forbedre dette også i sprint 4, og etter testen av koden i sprint 5.

12.2.5 Automatisk utlogging for innloggede som har glemt det. Sprint 4

At folk glemmer å logge ut noen ganger, er et problem for Fontenehuset. En løsning på dette er f.eks å logge ut personen ved arbeidsdagen er slutt. Vi diskuterte dette med Fontenehuset, og fant ut at det var en god måte å løse det på. Løsningen til Filemaker-løsningen er å bruke et skript som ser på hver registrering og legger til riktig tidspunkt noen ikke har logget ut. Skriptet ble først satt til å starte når databasen starter opp på starten av dagen, men kan nå også aktiveres når man trykker på en knapp i innstillinger. I PHP kjøres kode kun når en side blir lastet. Dette gjorde det nødvendig for PHP-løsningen å laste inn alle sider på nytt automatisk etter en halvtime etter den ble lastet inn sist. I tillegg ble phpkoden for å logge ut automatisk inkludert på alle sider. For å ikke bruke unødvendige ressurser, og forsinke lasting av sidene, blir det kun utført databaseoppslag og utlogging etter 23:10. I databasen blir det sjekket etter når medlemmer har logget inn. Hvis de logget inn før 16, så blir det satt 16:00 som utloggingstidspunkt og arbeid som tidssone. Logget de inn etter 16, så blir utloggingstidspunktet 23:00, og tidssonen fritid. Unntaket er helgen som alltid vil ha fritid som tidssone. Det blir ikke satt aktivitet for de som blir logget ut automatisk. Det er fordi det er umulig å vite når medlemmene dro fra Fontenehuset. I tillegg blir feltet “Utlogging” satt til “Automatisk”, slik at det er lett å se når noen har glemt å logge seg ut.

12.2.6 Inneliste. Sprint 4

For Fontenehuset er det nøsvendig å ha en inneliste. Denne lista gir en kjapp oversikt over hvem som er registrert inn og er til stedet i lokalet, f.eks i tilfelle brann. Metoden vi brukte på Filemaker-løsningen, er å bruke en Portal som viser alle som er logget inn og ikke ut den dagen. Samtidig laget vi en avkryssingsboks for åt man skal ha oversikt over hvem man har ropt opp. Under noen møter med Fontenehuset dukke det opp et forslag om å ha innelista offline i tilfelle nettilkoblingen røk. For Filemaker undersøkte vi om det var overhodet mulig å ha en offlinefunksjon. Svaret vi fant var at det er mulig å lage en funksjon, bruke en eksisterende løsning eller lagre databasen lokalt og synkronisere den med serverdatabasen. På grunn av vår kunskap om Filemaker og tildsnød, valgte vi en synkroniseringsløsning kalt GoZync. GoZync er en funksjon som kobler begge databasene i seg og synkroniserer inneholde mellom dem. Vi fikk det til å synkronisere i Pro-versonen av Filemaker, men ikke i Go-versjonen. PHP-løsningen har den samme funksjonaliteten. Det var enkelt å viser de innregistrerte dataene i en tabell. Et større problem var å lage en versjon av denne lista, som ikke bruker databasen. I tilfelle databasen er nede, er det en fordel om man kan fortsatt få ut en liste av de som er inne. For å få til dette, ble det inkludert en phpfil i sidene som utfører inn- og utlogging. Denne phpfila

55

inneholder kode som henter ut informasjonen om hvem som er inne, og putter den i en tekstfil. Denne tekstfila kan senere brukes av innelista, når databasen er nede. Lista hentes ut av php, og puttes i en tabell. For hver femte linje, puttes det inn en sjekkboks, lik den som finnes i den vanlige lista. Denne funksjonaliteten er i tillegg puttet i en egen side. Det gjør det mulig å hente ut en liste som er uavhengig av databasen hvis det skulle være nødvendig av andre grunner. Vi forsøkte å cache denne siden på iPaden lokalt, men fant ut at HTML5 sin offline funksjonalitet var best egnet for statisk innhold. Siden lista over de som er inne konstant forandres, var ikke denne funksjonen egnet for dette formålet. Vi fant ingen god løsning for denne funksjonen, så php-løsningen kan ikke vise lista over hvem som er inne, hvis webserveren er nede.

12.3 Fase 3: Testing

Det var viktig for oss å få brukerenes perspektiv på hvordan løsningene fungerte. Vi syntes at vi trengte mer informasjon om de individuelle systemene enn kun en teknisk sammenligning av dem. Vi utførte testene over to dager. For å søke etter testdeltakere, satt vi opp en lapp på Fontenehuset hvor vi spurte etter frivillige. På testdagene satt vi i resepsjonen for å være lett tilgjenelig. Det fungerte også som en synlig påminnelse og gjorde at vi kunne rekrutere flere testpersoner. Deltakerne testet et system den ene dagen, og det andre dagen etter. Det var derfor viktig at deltakerne kunne teste begge dagene. Hvis de ikke møtte opp begge dagene ble den første testen diskvalifisert. For å forhindre at deltakerne ble påvirket av testrekkefølgen, delte vi deltakerne opp i to grupper som testet hvert sitt system, og byttet om dagen etter. Testene ble utført på en iPad2. Vi startet opp Filemaker Go før testen av den løsningen. Databasen ble åpnet på forhånd, siden brukere ikke vil trenge å forholde seg til det i en virkelig brukersituasjon. PHP/Webløsningen ble også startet opp på forhånd, så den var klar til bruk. At systemet kjører hele dagen vil bli stanard når Fontenehuset skal bruke det. Under testene observerte vi deltakerne, og vi tok notater av hvordan de utførte oppgavene. Etter at deltakerne gjennomførte testen, fikk de utdelt et spørreskjema der de kunne gi tilbakemeldinger på løsningen de nettopp testet. For den andre systemet de testet, ble det også lagt til tilleggsspørsmål om hvilket system de likte best, og hvorfor. Svarene fra spørreskjemaene ligger i vedlegg B.

12.3.1 Testprosedyre

Vi laget en testprosedyre med noen punkter som testdeltakerne skulle igjennom for å teste løsningene:

● Logg inn m/ID

● Logg inn u/ID

● Logg ut

● Logg ut med feil medlemsnummer

● Logge inn med feilskrevet navn

● Sjekk inneliste (admin)

56

Punktene dekker bruksområdene og forutsette feil som vil oppstå hyppig ved vanlig bruk. Kun administratorer vil ha tilgang til å se hvem som er logget inn, og det siste punktet er kun et ekstra punkt for de testdeltakerne.

12.3.2 Tilbakemeldinger fra testene

Tilbakemeldingene fra de som testet PHP-løsningen for web og hadde problemer var relatert til responsivitet. Knappene reagerte ikke alltid når det ble trykket på dem, og testdeltakerne måtte prøve å trykke igjen. De som testet Filemaker Go hadde problemer med å vite hvordan de skulle utføre handlingene vi ba dem om å gjøre. F.eks inn- og utlogging. De måtte ofte få veileding på hvor de skulle trykke for å gjennomføre handlingene. Dette skyldtes ofte uklar navngiving og felter som vistes, men ikke trengte å fylles ut. Feltene som ikke måtte utfylles ble fylt automatisk når man trykket på inn- eller utloggingsknappen. De er blanke før knappen trykkes på, og det førte til at testdeltakerne trykket på dem og prøvde å fylle dem ut selv. Brukergrensesnittet opplevdes også som litt rotete lagt opp, og viste informasjon som ikke var nødvendig. Det kom ingen tilbakemelding på om man ble inn- eller utlogget, og deltakerne spurte ofte på om det hadde blitt utført. Web: Testdeltakerne synes det var lett å finne frem i løsningen. 4/12 hadde problemer under veis. 11/12 synes løsningen var brukervennlig. FMGo: 3/12 av de som testet synes det var vanskelig å finne frem i løsningen. 7/12 synes det var middels, og kun 2 synes det var lett. 6/12 hadde problemer under veis. 4/12 synes løsningen var brukervennlig. Etter test av begge:

Hvilket system er best?

web File Like gode

10 1 1

12.3.3 Vurdering av testene

Testene viser at 10/12 testpersoner likte den web-baserte løsningen best. Det stemmer også overens med tilbakemeldingene på brukervennlighet.

57

Web-løsningen fremstår som mer intuitivt og brukervennlig av testdeltakerne. Autocomplete blir trukket frem som en fordel med denne løsningen. Et trekk med løsningen er at den ikke alltid er responsiv. Noe av kritikken mot Filemaker Go skyldes navnsetting og rotete oppsett. Testdeltakerne trengte veideding for å kunne utføre testen. Navnsetting og oppsett kan forbedres for å gjøre løsningen mer brukervellig. Autocomplete støttes dessverre ikke i Filemaker Go, og kan derfor ikke brukes. Spørsmålet om systemet var bedre enn det gamle var ikke klart nok. Vi mente det gamle papirbaserte, mens noen trodde det var snakk om systemet de prøvde først. Svarene fra dette spørsmålet er derfor av mindre verdi. Svarene fra spørsmålene ligger i vedlegg B.

12.3.4 Test av kode

PHP-koden ble testet mot en rekke feilsituasjoner. Siden de fleste av disse feilsituasjonene var blitt oppdaget tidligere under koding, validering og testing, var det få endringer i koden etter disse testene ble utført. Det var likevel viktig å lage en liste med vanlige feilsituasjoner, og teste mot disse. En feil kan gjøre at løsningen slutter å fungere, eller lagrer feil opplysninger i databasen. Det vil være vanskelig for Fontenehuset å feilsøke og rette opp slike feil. Det er derfor viktig at løsningen er så stabil som mulig. Det ble under denne testen forbedret brukervennligheten noe, ved å implementere en mer nøyaktig feilmelding om noen skriver inn navn i feltet for medlemsnummer.

12.4 Akseptansetest

Både vi og Fontenehuset var ukjent med akseptansetest. Dette gjorde at testen ble utført kjapt og uten formaliteter. PHP-løsningen ble akseptert som den var, men Filemaker-løsningen hadde noen problemer. Problemene som trengtes å rettes på var:

● Filemaker Go trenger å låse zoom og scroll.

● Valg av datoer dukker opp i alle datofelt som er på layouter.

● Inn/ut knapp i nummer-layout fungerer ikke som den skall.

● Krav om flere inn- og utlogging om dagen.

12.4.1 Løsninger for å få godkjent akseptansetest av Filemaker Go løsningen

Noen dager senere hadde vi et kjapt møte for å sjekke om problemene ble løst, og om løsningen kunne godkjennes. Hvordan problemene ble løst, er beskrevet under.

Filemaker Go trenger å låse zoom og scroll.

Løsningen her ble å lage et script som låser vindu og zoomen når programmet som kjører det er Filemaker Go og å justere layoutstørrelsene til layoutene som skal brukes i Go.

Valg av datoer dukker opp i alle datofelt som er på layouter.

Dette problemet dukket bare opp når man kjørte systemet med Filemaker Go. Brukere kan ikke skrive noe i feltene når det kjøres i Filemaker Pro og flere av dem er usynlige. Noen løsning på

58

problemet ble ikke funnet, noe som kan ha noe med hvilken versjon av Pro systemet ble laget i. Fontenehuset har bestemt seg for å godkjenne løsningen, selv om feilen ikke kan rettes på umiddelbart.

Inn/ut knapp i nummer-layout fungerer ikke som den skall.

Deler av problemet oppsto når vi justerte størrelsen til layoutene. Vi måtte vi flytte på flere felter og noen av de som var i en Portal havnet utenfor. Andre problemer oppsto da vi måtte justere størrelsen på noen knapper. En av knappene fikk et duplikat på feil layout, noe som gjordet at den ikke kunne utføre skriptet sitt.

Krav om flere inn- og utlogging om dagen.

Kravet ble oppdaget under denne testingen. Det ble avtalt om at man skulle se om det kunne enkelt rettes på og godkjenne løsningen selv om feilen ikke ble rettet på. Det ble ikke funnet en løsning etter avtalt tidsrom.

Begge løsningene fikk godkjent at vi hadde brukt våre egenutviklede databaser i stedet for den de bruker fra før av. Databasene kan kjøre side ved side med den eksisterende på Filemaker Server slik det står nå. Siden problemene vi hadde var begrenset til den databasen de bruker fra før av, vil de ha mulighet til å få utvikleren av databasen deres til å løse problemene som var relatert til den.

13. Konklusjon Vi synes arbeidet med prosjektet var lærerikt. Vi lærte mye om Filemaker og om arbeid med en arbeidsgiver som har spesifikke behov. Tilbakemeldinger fra Fontenehuset og frivillige testdeltakere, ga innsikt på hvilke utfordringer det er å utvikle et brukervennlig system som kan brukes av alle, uansett bakgrunn. Fontenehuset aksepterte begge løsningene, og er fornøyde med arbeidet vårt. Vi har fått flere spørsmål fra medlemmer om når systemet skal tas i bruk. Når dette blir er opp til Fontenehuset, men det viser en viss entusiasme rundt innloggingssystemet. Testene viste at testdeltakerne foretrakk PHP-løsningen. Løsningen har også autocomplete, som Filemaker Go ikke støtter. Siden denne løsningen krever kunnskaper om PHP, hvis det skal gjøres forandringer, er det ikke nødvendigvis slik at denne løsningen er best for Fontenehuset. Vi har presentert prototyper, testresultater , fordeler og ulemper med hver løsning for Fontenehuset. Hvilken av løsningene som blir brukt er enda ikke bestemt. Personlig er vi totalt sett fornøyde. Vi er fornøyd med at tilbakemeldingene til løsningene i prosjektet er positive. Erfraringene våre fra arbeidet med prosjektet er generelt positive. Vi hadde begrenset med tid til å lære om Filemaker-databaser, og til å utvikle en løsning som bruker dette i bunnen. Den eksisterende databasen viste seg å være særdeles kompleks. Vi fikk vite at utvikleren har brukt flere måneder på å utvikle den med Filemaker, som han hadde erfaring med fra før. Vi er derfor ikke så skuffet over at vi ikke fikk til å bruke den eksisterende databasen som basis for våre løsninger. Løsningene våre ble laget for å være så lite innviklet som mulig. På den måten

59

vil det være mulig senere å koble dem inn mot den eksisterende databasen av en med mer tid og kunnskap om Filemaker. Det vi ville gjort annerledes er å ha satt av mer tid til å rette på erfaringene fra testene. Dette kunne blitt gjort ved å gjennomføre testingen på et tidligre tidspukt. Slik ville vi sett begrensninger og mangler tidligere, og hatt bedre tid til å rette dem opp.

60

Vedlegg

Vedlegg A: Kravspesifikasjon

Systembeskrivelse Fontenehuset i Oslo har skaffet seg en ny database. I den anledningen har de tenkt å modernisere innsjekkingen av medlemmer. Til dags dato foregår dette manuelt. På grunn av at medlemmene har variabelt med dataerfaringer, vil de at systemet skal være så enkelt og brukervennlig som mulig, også på vedlikeholds siden. De vil også at den skal skille mellom arbeidsorientert dag og fritidsprogram.

Funksjonelle krav

Det skal lages en applikasjon i FileMaker

Det skal være en enkel inn- utloggingsløsning

Det skal være en oversikt over hvem som har logget seg inn

Liste over hvem som er inne skal ikke være synlig for alle

Synlig klokke

Løsningen må være sikker

Skille mellom arbeidsorientert dag (08.00 -16.00 hverdag) og fritidsprogram (16.00 –

hverdag, helg og helligdager)

Ikke funksjonelle krav

Det skal være lett å utvide programmet

Programmet skal ha en god arkitektur

Enkelt å vedlikeholde

Rammekrav

Enheten skal være en iPad, og løsningen skal fungere på den

Søke opp seg selv via medlemmsnummer eller navn

Vise resultater mens man skriver i søket

Tilbakemelding om at man blir innlogget

Innlogging for mulige medlemmer (inget medlemmsnummer)

Hvis en person glemmer å logge ut, registreres 4 timer eller til kl. 16.00, etter som hvem

som er først.

Krav til dokumentasjon

Det skal skrives en bruker dokumentasjon

Det skal lages en produkt dokumentasjon

Alle filer skal leveres som PDF filer.

61

Vedlegg B: Brukertest

62

Brukertest Web

63

Brukertest Filemaker Go

64

Brukertest sammenligning

65

Kommentarer fra spørreskjema Kommentarene under er hentet ut i fra de håndutfylte spørreskjemaene

WEB: Dukket det opp problemer under veis?: Henger litt. Måtte trykke to ganger av og til før systemet reagerte. iPaden reagerte tregt. Er systemet brukervennlig? Hvis nei, kan du utdype hvorfor?: Noe du vil forandre på?: Nr/ kode til medarbeider Kanskje litt bruk av farge på bekreft. Endre navn til “Velg”eller “ok”. Litt tydligre “Bekreft knapp” Timestamp som standard tid inn, men med “annen inntid” som en manuelt kan taste inn når en kan. Trenger vi både gå og bekreft, eller kan dette forenkles? Knappene kan være litt tidligere. 1).Logg inn er dataspråk. Hvis mulig ha skriv deg inn, skriv deg ut i stedet. 2) Symboldene, [du er logget inn], [avbryt] kan stå nederst ved siden av avbryt. (I stedet for “Du er logget inn” står øverst.) 3) Du er logget inn kan stå i 1-2 sek lengre. Evt at det blinker med et smilefjes som beveger seg. Med et lite unntak av en man skal trykke “Gå” eller “navn” etter innskrevet navn, så var det veldig bra. Når man logger inn står det bekreft, når man logger ut står det “logg ut”. Det burde vzre likt. Når du logget deg inn ble tidspunktet litt fort borte. Hva er bra med systemet du nettopp prøvde?: Gir bedre oversikt over ut/inn for medarbeider også. Jeg rett og slett likte webløsning og brukervennlighet. Intuitivt enkelt å finne frem. Det fungerte knirkefritt. Kjapt. Enkelt. Enkelt og oversiktlig. Det går hurtig. Bra! Hvordan er det nye systemet i forhold til det gamle? Gikk raskere å logge inn og ut. Hvis folk skriver utydelig elimineres det problemet med det nye systemet. Bedre, men hvis mulig ha litt blomster, farger som gjør det mer “vennlig”.Noen har diagnoser som gjør at de føler seg overvåket. En fordel å slippe papirmølla. Bedre. Hvorfor er systemet best? Virket enklere/mer brukervennlig Hurtigere

66

Mer oversiktlig. Navn dukket opp mens man skriver. Mer intuitivt. Mer brukervennlig. Mer intuitivt hvor en skulle trykke for å navigere. Slipper scroll-bruker autofullfør. Mye mer brukervennlig! Brukervennlig. Brukervennlighet. Enklere.

FMGo: Dukket det opp problemer under veis?: [Nei] Men det hadde vzrt vanskelig å finne frem hvis dere ikke hadde vært her. For folk som ikke er PC/nettbrett vante/flinke bruker litt tid & finne ut hvor de skal finne tallene for & skrive medlemsnr. Jeg måtte spørre hva jeg skulle gjøre videre da det ikke var gitt at navnet mitt var funnet. Hedde litt problemer uten opplæring. Tydeligre logg inn/logg ut Opplevde det som litt rotete grensesnitt. Er systemet brukervennlig? Hvis nei, kan du utdype hvorfor?: Det var ikke helt logiske navn på knappene. Kunne man hatt et felt der man kunne søke på både navn og nummer? Trengte kanskje litt veiledning og fant det ikke selvforklarende, men systemet er en god start. I startfasen kan resepsjon hjelpe med den nye logg inn/ut metoden. Logg inn kan forandres til “skriv deg inn”. Logg ut kan forandres til “skriv deg ut” Som brukere må systemet føre oss videre automatisk. For mye informasjon. Virker uryddig. Kan f.eks skjule dato/tid (ikke som bokser). Evt med redigeringsknapp. Skjønte ikke helt hva jeg skulle gjøre. Noe du vil forandre på?: Ha knapper med “inn” og “ut” i stedet for “registrering”. Hva er bra med systemet du nettopp prøvde?: Blir nok bra når det vidreutvikles. At det står på knappene at jeg registrerer inn og ut litt tydligere. For de som 1) Tar ut penger til lunsj 2) Tur i lunsjen 3) Torsdags trim 4) De fra kjøkken som handler varer blir det flere turer inn & ut av huset (2-3 gang?). Da er det viktig at systemet klarer & registrere at man får inn & ut av huset flere gang i løpet av en dag. Pga Brann sikkerhet i tilfelle Brann er det svært viktig & hvite hvem som er på huset (& hvem som har skrevet seg ut). Hva tror dere? Nummerisk tastatur ved innregistrering av m.nr. Gjøre “viktige” knapper mer synlig sånn som f.eks -> Meny | Kunne søk navn/nummer vært i samme vindu? Ja. Jeg vil ha nummertastatur. Dropdown på navn. Logg inn/ logg ut Må være nok med noen bokstaver. Hva er bra med systemet du nettopp prøvde?: Bra jobba =). Fremtiden er digital, og det kan bli fint å bli kvitt “papirmølla”.

67

Det gikk raskt. Raskt. I framtiden kan flere farger benyttes? Større skrift for synshemmede. Talemelding “Fingeravtrykk” avleser for blinde Nøyaktig innreg og utreg av tid. Viser klokke- sanntid ganske tydelig. Husker ikke om den gamle gjør det? Jeg vil ikke lenger ha dette på papir. Så ikke helt noe som var bedre, kanskje bra brannliste. Hvordan er det nye systemet i forhold til det gamle? Virker for meg for litt mer “avanserte brukere”? Enklere og bedre Hvorfor er systemet best? (Like bra) Ser ingen forskjell Enklere

68

Vedlegg C: Test av php kode

Feilsituasjoner som testes: Situasjon: Bokstaver i nummerfelt Resultat: Går videre og viser “medlemsnummer ikke funnet” Det ble laget en mer brukervennlig løsning for å gjøre det mer brukervennlig. Det ble løst ved å legge til php funksjonen “is_numeric”. Nytt resultat: OK, "Verdien er ikke et tall! Prøv igjen med et nummer eller bytt til navnefeltet." Situasjon: Nummer i tekstfelt Resultat: OK, "Medlem ikke funnet!" med tall. Situasjon: Feil dato i innlogging Resultat: OK, "Dato er feil. Kan kun logge inn med dagens dato." Situasjon: Feil tid i innlogging Resultat: OK, "Tid er feil! Kan kun logges inn med tidspunkt innenfor samme time." Situasjon: Feil medlem i innlogging Resultat: OK, "Medlem ikke funnet!" Situasjon: Feil medlemsnummer i innlogging Resultat: OK, "Medlemsnummer ikke funnet!" Situasjon: Ingen innlogget ved utlogging Resultat: OK, "Ingen har logget inn i dag!" Situasjon: Utlogge en som allerede er utlogget eller ikke innlogget Resultat: OK, "Navn: XXX er logget ut / ikke logget inn Skrev du feil navn kan du prøve å logge ut igjen" Situasjon: Innlogge en som allerede er innlogget Resultat: OK, "Innlogging i databasen: Du er allerede innlogget!" Situasjon: Tom navnetabell Resultat: OK, Alt fungerer som det skal Situasjon: Tom innloggingstabell Resultat: OK, Alt fungerer som det skal Situasjon: Tom tidssonetabell Resultat: OK, Alt fungerer som det skal Situasjon: Feil verdier i databasen Resultat: Datatype er satt i databasen. Kan ikke skrive inn feil verdier. Dato kan skrives med slash, men vil ikke fungere i webgrensesnittet. Fikset så det ikke skaper feilmeldinger.

69

Admin:

Situasjon: Feil bruker/passord for innlogging Resultat: OK, "Ugyldig brukernavn, Ugyldig passord" Situasjon: Bokstaver i datofelt Resultat: OK, Ingenting vises Situasjon: Ugyldig dato Resultat: OK, Ingenting vises

70

Vedlegg D: Skisser av brukergrensesnitt

Forslag 1

71

Forslag 2

72

Vedlegg E: Brukermanual for den webbaserte php-løsningen

Brukermanual for den webbaserte innloggingsløsningen til Fontenehuset

73

Forord Denne brukermanualen beskriver hvordan man bruker innloggingsløsning for Fontenehuset. Brukermanualen er laget for å gi en oversikt for brukere og administratorer for løsningen. Denne manualen omhandler kun den webbaserte innloggingsløsningen. Oppsett av server er ikke ikke omfattet av denne manualen. Brukermanualen som beskriver innloggingsløsningen for Filemaker Go er skrevet separat.

Notasjoner Webløsning er programmet som beskrives i denne manualen.

Innledning Denne løsningen er utviklet ved bruk av HTML 5, CSS 3 og JavaScript. Programmet kjører på iPad gjennom nettleseren. For å kjøre korrekt i fullskjerm må nettsiden lagres som et bokmerke/ikon på hjemmeskjermen til iPaden. Dette må være gjort på forhånd av den ansvarlige for drift av løsningen. Oppsett av tilhørende database, Filemaker Server og IIS må være gjort på forhånd for at løsningen skal kjøre. Konfigurering, oppsett og annet tilknyttet drift er ikke omfattet av denne manualen. Programmet lar brukere logge seg inn og ut med dato og tid. Tidssonene «Arbeid» og «Fritid» blir lagt til ut i fra inn- og utloggingstid. Aktiviteter legges til i den tilhørende databasen som dag, eller dato. Programmet gir melding om vellykkede eller ikke-vellykkede inn- eller utlogginger. Feil som skyldes feilkonfigurering, eller feil i databasen, gis som en feiltekst direkte fra Filemaker Server.

74

Brukerveiledning

Meny

Menyen er felles for hele løsningen. Teksten blir blå hvis man trykker på en av menyelementene. Dato og tid oppdateres for å alltid være korrekt.

Hjem

Hjem er hovedsiden. Den har har to store knapper for inn- og utlogging. Brukere blir sendt hit når de først starter webløsningen, og automatisk etter en inn- eller utlogging.

Innlogging

Innlogging foregår med nummer eller navn. Nummerfeltet blir valgt automatisk, og nummertastatur vises på iPaden. Man bruker «Nr» eller «Navn» knappen for å føre brukeren videre til innlogging.

75

Hvis brukeren begynner å skrive inn et navn i navnefeltet, kommer det opp treff på teksten som blir skrevet inn fortløpende. Brukeren kan trykke på det riktige navnet for å legge det inn i navnefeltet.

Etter navn eller nummer har blitt valgt, får man en oversikt over dataene som har blitt registrert for innloggingen, og en mulighet for å bekrefte den.

76

Ved en vellykket innlogging får brukeren beskjed om det sammen med informasjonen som ble lagret i databasen. Etter en kort stund åpnes «Hjem», slik at løsningen er klar for neste bruker.

Utlogging

Når ingen er innlogget, f.eks på starten av dagen, får man en melding om at ingen har logget inn. Det gjør det synlig at det ikke finnes noen å logge ut.

Som ved innlogging, får brukere mulighet til å velge mellom medlemsnummer og navn for å logge ut. Nummerfeltet blir valgt automatisk.

77

Når man begynner å søke etter navn, vises det treff på navnet fra en liste over innloggede. Brukeren kan da trykke på navnet for å legge det inn i feltet. Brukere kan så trykke på navn for å gå videre til utlogging.

Etter navn eller nummer har blitt valgt, får man mulighet til å se at navn og tidspunkt stemmer for den man skal logge ut.

Ved vellykket utlogging får brukeren beskjed om dette. Løsningen åpner så «Hjem» for å være klar for neste bruker.

78

Admin

Visse deler av løsningen skal kun være synlig for administratorer. For å sikre dette er det laget en innlogging. Kombinasjonen av brukernavn og passord må være godkjent for å gå videre til administratormenyen. Denne kombinasjonen settes i admin.php av driftsansvarlig før løsningen tas i bruk.

Denne administratormenyen vises kun når administrator er logget inn. Den gir tilgang til listene som kun skal være synlig for administrator. Menyen gjør det også en kelt å logge ut.

79

Menyvalget «Liste» viser en oversikt over alle som har logget inn, og ikke ut den aktuelle dagen.

Menyvalget «Offline liste» viser en liste over de som har logget inn, og ikke ut denne dagen. Denne lista leses fra liste.txt som alltid inneholder denne oversikten.

Menyvalget «Datobasert liste med tidssone» gjør det mulig å søke opp en liste med inn og utlogginger basert på dato.

80

Listen ovenfor viser inn- og utlogginger for 04.05.14. Denne lista viser også hvilken tidssone og aktivitet som har blitt ført inn i databasen.

81

Vedlegg F: Brukermanual for Registeringssystem Filemaker

Brukermanual for Fontenehusets innloggingsløsning som bruker Filemaker Go

82

Innhold Innledning Vanlige brukere Registreringsbeskjeder Administrasjon Innstillingsmeny Inneliste Dager med fritidsprogram Personreg

Forord Dette er manualen for inn- og ut-registreringsløsningen til Fontenehuset. Løsningen er laget i Filemaker Pro. Denne manualen er laget for daglig brukere og administrasjon. For systemet laget i PHP, se egen manual Første del av manualen er for vanlige brukere, som tar for seg skritt for skritt hvordan en bruker systemet, andre del er for administrasjon, som forklarer innholdet under innstillinger.

Notasjoner Filemakerløsning er programmet som beskrives i denne manualen.

Innledning Systemet er laget for å registrere personer inn og ut. I tillegg har den en inneliste for opprop ved brann. Løsningen kan registrere ut personer som selv har glemt det. Brukerne tar seg frem gjennom et grafisk brukergrensesnitt og man manøvrerer seg ved å trykke på knapper. Løsningen melder i fra om du har logget deg inn, om du har logget deg ut, om du har allerede har logget deg ut og om det skrevne navnet eller nummeret eksisterer.

83

Vanlige brukere

Trykk på «Logg inn/ut med nummer» eller «Logg inn/ut med navn» for å logge inn eller ut på beskrevet måte.

Navnet skal skrives i feltet navn hvis feltet er rødt. Hvis MedlemsNr er rødt skal man skrive inn medlemsnummeret . Det gjennomsiktige feltet oppdateres av seg selv. Sjekk så om opplysningene stemmer. For å registrere, trykk på knappen merket med «Inn/ut».

Hvis du har gjort alt rett, dukker dette skjermbildet for å fortelle at du har blitt registrert.

84

Registreringsbeskjeder

Viktige beskjeder dukker opp på området som er sirklet inn: Ok – Det som er skrevet inn eksisterer i databasen Navnet eksisterer ikke i databasen. Prøv på nytt. – Navnet som er skrevet finnes ikke i databasen. Forsøk på nytt og kontakt administrasjon om problemet vedvarer Tallet eksisterer ikke, prøv på nytt. – Medlemsnummeret som er skrevet inn finnes ikke i databasen. Prøv på nytt og kontakt administrasjon om problemet vedvarer. Trenger et nummer. – Det er ikke skrevet et nummer i nummerfeltet.

85

Administrasjon

Innstillingsmeny

Meny – tar deg tilbake til hovedmenyen Fridager – tar deg til registeret over dager med fritidsprogram Inneliste – tar deg til lista over personer som er inne Logg ut glemte registreringer – logger automatisk ut personer som har glemt å logge ut siden i går og tiden bakover. Personreg – registrerer personer i testdatabasen

86

Inneliste

1. Felt med dagens dato

2. Knapp som fører tilbake til hovedmeny

3. Felt med klokkeslettet

4. Felt med en persons medlemsnummer

5. Felt med en persons navn

6. Felt med innregisteringstiden

7. Felt for avkryssing ved opprop

Dager med fritidsprogram

1. Sender tilbake til instillinger

2. En enkel dag med fritidsprogram

1

v

2v

3v

7v

6v

4

5v

1

v

5

4

v

3

v

2

v

87

3. Dato for dagen med fritidsprogram

4. Om dagen er et fritidprogram

5. Navnet på begivenheten den dagen

Personreg

1. Løpenummeret, ID-nummeret til personen

2. Medlemsnummeret til personen hvis medlem

3. Fornavn

4. Etternavn

5. Helet navnet, fylles automatisk fra fornavn og etternavn

6. Knappen fører tilbake til hovedmeny

7. Felt med klokkeslettet

1

v

2

v

6

v

4

v

3

v

5

v

7

v

88

Vedlegg G: Use Case

89

Vedlegg H: Sekvensdiagram

90

91

Vedlegg I: Virkningsanalyse Analyse av virkninger Løsning 1, Filemaker Go: Å lage systemet i FileMaker kan være tidsbesparende i henhold til selve utviklingen. Fontenehuset bruker allerede FileMaker til databasen sin, slik at kompatibiliteten er ingen større hindring. Derfor der det et ønske fra dem om at vi helst bruker FileMaker til å lage systemet og bruker FileMaker Go som visningsplattform. Ulempene er at vi har ingen kontroll over FileMaker. Fremtidige versjoner er kanskje såpass forandret at det ferdige systemet ikke lenger fungerer. Det vi kan gjøre med FileMaker begrenses av hva programmet lar oss gjøre. Siden ingen av oss har større erfaring med FileMaker vet vi ikke om det blir et problem eller ikke. Løsning 2, Web/PHP: Ved å lage systemet for bruk i weblesere, kan den brukes på alle plattformer. Handlefriheten er stor, og kan gjøres uavhengig av databasen og FileMaker. Selve kildekoden vil være tilgjengelig for fremtidige programmerere som kan videreutvikle systemet, selv om FileMaker-serien skulle stoppe. Det kreves mer av programmererne å lage fritt enn å bruke eksisterende systemer. Større kunnskap trengs for å programmere riktig og å gjøre systemet kompatibelt med dagens database. Dessuten krever det mer av systemansvarlig hvis systemet blir adoptert av andre Fontenehus. Der kan det hende at det ikke er noen som kan nok om data til å jevnlig vedlikeholdet systemet.

92

Vedlegg J: Fremdriftsplan

93

Vedlegg K: Begrep I dette vedlegge beskrives det begreper som er brukt i rapporten Portal Oppføringer fra en annen tabell vises ved hjelp av en Filemaker Pro layout objekt kalt en portal. En portal viser data fra relaterte poster i rader der én rad i en portal representerer en relatert oppføring i den relaterte tabellen. En portal kan konfigureres til å vise så mange poster som du vil og kan filtreres og sorteres etter hvert som behovene krever. I tillegg, hvis du tillater det, kan en portal kan brukes til å legge til, slette og redigere poster i den relaterte tabellen. Layout Layout er det grafiske bildet som representerer en tabell. En tabell kan ha flere layouter, men en layout kan bare ha en tabell. Den kan bestå av felter fra andre tabeller som er lenket sammen med tabellen layoutet er laget for. Knapper, portaler og lignende skapes i layoutet.

94

Vedlegg L: Akseptansetest Under er tilbakemeldingene på akseptansetesten. Løsningene ble testet mot kravspesifikasjonen.

Akseptantsetest 1 Web løsning Godkjent Filemaker Go løsning

Trenger å låse zoom og scroll.

Inn/ut knapp i nummer-layout fungerer ikke som den skall.

Krav om flere inn- og utlogging om dagen er ikke i kravspesifikasjon.

Akseptantsetest 2 Filemaker Go løsning

Har nå låst zoom og scroll.

Inn/ut knapp fungerer igjen.

Flere inn- og utloggingsmetoder ikke ferdig, tas med på fremtidige versjoner av systemet.

Godkjent

95

Vedlegg J: ER-Modeller

ER-Modell for databasen brukt med PHP-løsning

ER-Modell for databasen som inneholder Filemaker Go- løsning

96

Vedlegg K: Risikoanalyse

Documents

Hovedprosjekt - student.cs.hioa.nostudent.cs.hioa.no/hovedprosjekter/data/2014/46/filer/sluttrapport.pdf · ER-Modell for databasen brukt med PHP-løsning ..... 95 ER-Modell for databasen