Prosessrapport. WillWest Smøredatabase GRUPPE 21 FORFATTERE: BREKKLUND, PÅL E. LARSEN, MARTIN WESTGAARD, CHRISTIAN S.

Transkript

1 Prosessrapport WillWest Smøredatabase GRUPPE 21 FORFATTERE: BREKKLUND, PÅL E. LARSEN, MARTIN WESTGAARD, CHRISTIAN S. 1

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Innholdsliste Prosessrapport... 1 Innholdsliste Forord Bakgrunn og forutsetninger for oppgaven Om oss Om oppgaven, fakta og noen valg Noen fakta om skismurning og begreper i oppgaven Planlegging og metode Rammebetingelser Teknologier og språk Andre betingelser Tiden Kunnskap ved oppstart Teknologi tilgjengelig hos oppdragsgiver Arbeidsmetodikk Dokumentasjon Styringsdokumentene Arbeidsprosess Møter med veileder og oppdragsgiver Arbeidsfordeling Prosjektdagbok Arbeidsplass Om utviklingsprosessen

3 4.1 Oppstart Avgrensning og problemstilling Første fase - Databasen Bruker Innlegg Omstendigheter Skiinfo Glid Feste Oppsummeringstabell Andre fase - Layout Betraktninger brukergrensesnitt (GUI) Utvikling av GUI Tredje fase - Sluttresultatet Faglige utfordringer Taus kunnskap Eksempler Erfaringskompetanse Taus kunnskap versus eksplisitt kunnskap Omforming Kunnskapsledelse Universell utforming Om resultatet Dokumenter Kildekode Prosjektets nettside Avsluttende del Samarbeid Læringsutbytte

4 6.2.1 Egne valg Fremtiden Hva kunne vi gjort annerledes?

5 1 Forord Dette er prosessrapporten som er utarbeidet i forbindelse med hovedprosjekt våren 2014 ved Høgskolen i Oslo og Akershus av gruppe 21. Rapporten vil beskrive gangen i utviklingsarbeidet av siden laget for vår oppdragsgiver WillWest Sport. Prosessrapporten er først og fremst rettet mot sensor og veileder. Det forutsettes da at leseren har noe datateknisk innsikt. Prosessrapporten er inndelt i disse hovedkapitlene: Bakgrunn og forutsetninger for oppgaven Bakgrunn for prosjektet og oversikt over forutsetninger og betingelser som har påvirket utviklingsprosessen. Planlegging og metode En gjennomgang av hvordan planlegging og samarbeid har foregått, og hvilke verktøy vi har brukt i dette henseende. Om utviklingsprosessen Komplett guide til faser og gjennomføring av utviklingen. Kravspesifikasjonen og dens rolle Kravspesifikasjonen i sin helhet, og hvordan den henger sammen med det endelige resultatet. Om resultatet Beskrivelse av dokumenter og nettsiden som skal leveres. Avsluttende del Et konklusjonsavsnitt hvor vi reflekterer over arbeidet og produktet. 5

6 2 Bakgrunn og forutsetninger for oppgaven 2.1 Om oss Gruppen består av tre elever fra studiet Anvendt datateknologi på Høgskolen i Oslo og Akershus. Vi har igjennom det treårige løpet stort sett hatt samme fag som hverandre. Oppgaven vi har skrevet og jobbet med under Hovedprosjektet er en naturlig videreføring av de kursene og kunnskapene vi har tilegnet oss under dette bachelorgrad studiet. Vi jobber videre med PHP, databaser, litt JavaScript, grunnleggende datasikkerhet, Visualisering og Informasjonsarkitektur for å nevne noen. Vi har basert oppgaven på den kunnskapen vi besitter og som var realistisk å strekke oss til. 2.2 Om oppgaven, fakta og noen valg Vi har tatt på oss oppgaven med å lage en smøredatabase for oppdragsgiver og smører, Willy Westgaard. Oppgaven går ut på å optimalisere, systematisere og katalogisere innsamlede data under testing av skismurning. Oppdragsgiver har et ønske om å få utviklet en løsning hvor de (han og andre smørere) kan legge inn og søke etter snøtype, vær, sted, og smøreprodukter. De ønsker en database slik at de kan legge inn og hente ut informasjon med eller uten nettilgang. I første omgang må det basere seg på at smører tester på "vanlig" måte, ved å prøve forskjellige type produkter, sliper og strukturer. Etterhvert som databasen vokser vil det ved hjelp av de lagrede resultatene være enklere for en smører å se hva som har fungert og hva sin ikke virket like bra på et bestemt sted, en type snø, en bestemt temperatur og så videre. Dette vil kunne bidra til å gjøre det enklere for smørerne til å finne et optimalt oppsett av ski. Oppdragsgiver skal altså ha muligheten til å filtrere ut resultater fra de aktuelle dataene han ønsker. 6

7 2.3 Noen fakta om skismurning og begreper i oppgaven Oppgaven inneholder endel ord som kan være fremmede for den allmenne delen av befolkningen. Vi skal gi en kjapp innføring i hvilke komponenter man har i hobbyen, faget, vitenskapen; skismurning. Ski Alle ski, enten det er i klassisk stilart eller i friteknikk, har egne egenskaper og kvaliteter som skiller de fra hverandre. Skien, er bygget opp av en trekjerne, med glassfiber rundt, en såle under skiene, og bindinger oppå. Denne sålen er den viktigste delen for en skismører. Skismørerens jobb er å manipulere sålen på en så god måte, at friksjonen blir minst mulig i kontakt med snøen. For å oppnå dette bruker skismøreren en rekke verktøy og midler. Et skipar kan enten komme med en fabrikkslip, eller det kan bli slipt på en ny måte. Et skipar kan slipes om flere ganger. En skislip er en valse som skjærer inn spor i sålen under skiene. Disse sporene ligger permanent til man eventuelt sliper om skiene på nytt. Det finnes mange forskjellige sliper (fra forskjellige leverandører) ut ifra hva slags føre og egenskaper man ser etter. Glider Glider er produkter som legges under sålen på skiene. Det er parafin i videreutviklet form, som virker ved å "mette" sålen. Man legger glideren på ved å smelte den med et smørejern (strykejern lagd for formålet), den størkner så på sålen. Det brukes samme temperatur på smørejernet uansett hvilket glider produkt som benyttes. Siste del av prosessen er å skrape bort den størknede glideren fra skisålen. Etter det er gjort vil skiene ha bedre forutsetninger for å oppnå høyere hastighet på forskjellig føre. Produktene kan blandes seg imellom, eller brukes enkeltvis. Etter at brukeren har lagt på ønskede lag med glider under skiene, kan smøreren legge på pulver. Pulver er fluorprodukter som legges på skiene med varmt smørejern. Det fungerer litt 7

8 på samme måte som en glider, men fluoren klarer å minske friksjonen med snøen enda noen prosent. Her spiller også temperaturen smørejernet er stilt inn på en rolle. Topping er siste finish når det gjelder glid. Den kommer i enten flytende eller såpelignende fastform. Den påføres på skisålen enten ved å spraye på det flytende middelet, eller ved å gni på det såpelignende produktet. Feste Feste er produkter som gir de klassiske skiene feste på snøen, dette legges kun på midten av klassiskskiene. Feste består av en "base", den legges i bunn og virker som et slitesterkt lag som hjelper enten voksen eller klisteret til å holde lenger. Videre legger smørerne voks eller klister i flere lag og bruker gjerne en kombinasjon av flere produkter. Vær Det som bestemmer hvilken måte man skal manipulere skiene på er været, snøtypen og temperaturen. Alle disse faktorene er nesten alltid forskjellige fra sted til sted. Det er med andre ord ikke gitt at det som fungerte på et sted vil fungere like bra på et annet sted, selv med like øvrige forhold. 8

9 3 Planlegging og metode 3.1 Rammebetingelser Oppdragsgiver hadde ingen preferanser om hvilke programmeringsspråk som skulle brukes. Oppdragsgiver hadde ønsker om det kosmetiske og innholdet på siden og ønsket også enkelte tekniske løsninger. Disse ble diskutert med oppdragsgiver. Gruppen har kjennskap til PHP, HTML, CSS og MYSQL fra tidligere kurs på HIOA. Vi ønsket da å bygge videre på den kunnskapen, men tok høyde for at det måtte supplementeres med ytterligere språk. Vi endte opp med følgende språk og teknologier: 9

10 3.2 Teknologier og språk PHP PHP (Hypertext Preprocessor) er et dynamisk programmeringsspråk benyttet til å utvikle dynamiske nettsider. HMTL HTML (HyperText Markup Language) er et markeringsspråk brukt ved strukturering av informasjon som skal vises via en nettleser. CSS CSS (Cascading Style Sheets) er språket brukt for å definere hvordan en HTML- eller XMLfil skal se ut i nettleseren. JavaScript Et skriptspråk brukt for å gjøre en nettside mer dynamisk. Koden kjøres lokalt hos klienten. jquery Et JavaScript bibliotek som hjelper med manipulering av HTML-filer. Here document Here document tillater oss å skrive tekst og tegn uten å bekymre oss for syntaks. Brukes av oss i PHP. TextMate Et tekstutviklingsprogram til å skrive all kode utenom SQL. HeidiSQL HeidiSQL er et databaseoppsettprogram brukt til å lage MySQL koden. Ferdig kode kan sendes til server og benyttes der. Adobe-Photoshop 10

11 Adobe Photoshop er et bilderedigeringsprogram som brukes til å redigere de visuelle elementene vi ikke lager med CSS. Adobe-Illustrator Adobe Illustrator et redigeringsverktøy for vektorgrafikk. Gruppen har brukt programmet til å lage ikoner og til å lage ulike skjemaer og modeller. Trello En oppgavefordelingsside som lar gruppen bruke Scrum metodikken. Oppgaver blir fordelt mellom de tre gruppemedlemmene. Man fører opp oppgaver som skal gjøres på "To do". De oppgavene man arbeider med flyttes til "Doing" og de man er ferdige med er flyttes så til "Done". Metoden gir gruppemedlemmene en god oversikt over hva som må gjøres til hvilke tider og man ser hvem som arbeider med de ulike oppgavene. Microsoft Workbench En databaseoppsettverktøy. Man kan sette opp entiteter og attributter og lage ER-diagrammer med verktøyet. XAMPP Xampp er et serverprogram som muliggjør lokalt arbeid med for eksempel PHP og MySQL. Den inneholder Apache som er selve webserveren, den inneholder også phpmyadmin som gir tilgang til databaseløsninger. 11

12 3.3.1 Tiden 3.3 Andre betingelser Fordi dette er et hovedprosjekt med klare frister og innleveringer, har tiden vi har hatt til rådighet vært en opplagt rammebetingelse. Gruppen har satt opp et Gantt-diagram for å lettere følge med på hvilke frister vi har satt og hvilke oppgaver som skulle bli gjort når (se Vedlegg 3.2) Kunnskap ved oppstart Den kunnskapen som fantes i gruppen ved begynnelsen av prosjektet, var en betingelse for hvordan vi valgte å løse oppgaven. Kunnskapen har ekspandert i løpet av prosjektperioden. Nye språk og teknologier er blitt tatt i bruk. Vi føler vi har videreutviklet ferdighetene vi startet med, samt tilegnet oss ny kunnskap Teknologi tilgjengelig hos oppdragsgiver Oppdragsgiver benytter seg av privat utstyr til bruken av nettsiden, og det er dermed ikke noen formelle krav eller grenser for hvilke nettlesere eller plattform nettsiden skal brukes til. Vi har prøvd å gjøre den kompatibel med Safari, Google Chrome, Mozilla Firefox og Internet Explorer (derav bruk av blant annet jquery). 12

13 3.4 Arbeidsmetodikk Som overordnet metodikk brukte vi Scrum til å håndtere diverse oppgaver relatert til programmering og databaseoppsett. Vi ønsket å programmere med MVC kontroller metoden. Til det visuelle brukte vi papir og blyant i starten. For å få på plass hvordan nettsiden skulle se ut, benyttet vi to idemyldringssesjoner hvor vi uavbrutt skrev opp ideer på Post-it lapper, og gjennomgikk dem i etterkant for å diskutere frem fordeler og ulemper. Gruppen brukte også denne metoden i prosessen for å lage databasen (figur 3.1) Gruppen benyttet et Ganttdiagram til å holde frister og oversikt over arbeidsoppgaver (Vedlegg 3.2). Figur 3.1 Post it 13

14 3.5 Dokumentasjon Gruppen startet med å lage forskjellige dokumenter for å få en formell struktur på hvordan vi ville utføre prosjektet. Prosjektet startet med å lage samarbeidsavtale, risikoplan og en prosjektbeskrivelse. Da vi begynte å få oversikt over prosjektets mål og krav var det viktig å få på plass kravspesifikasjonen, i tillegg til en aktivitetsplan (i form av et Gantt-diagram. Se Vedlegg 3.2) og en milepælsplan. Dette var styringsdokumentene vi forholdt oss til gjennom arbeidet og ved endringer fra oppdragsgiver ble styringsdokumentene revidert. Gruppen har også ført møtereferater og dagbok Styringsdokumentene Styringsdokumentene ble opprettet tidlig i oppgaveprosessen, eller så tidlig som det har vært mulig å sette krav. Gruppen har forholdt seg til disse dokumentene under prosjektprosessen. Hvis endringer har forekommet er de blitt revidert på gruppesiden. Samarbeidsavtale En avtale som forplikter og klargjør for gruppemedlemmene hvordan ansvars- og oppgavefordeling blir i gruppen. Den skal fastholde hvordan arbeidet gjennomføres og hvilke spilleregler som gjelder for å sikre et best mulig resultat i prosjektet. Ligger under vedlegg 3.1. Risikoplan Risikoplanen setter opp hvilke scenarioer som kan oppstå for å skade progresjonen til prosjektet. Risikoplanen lister de forskjellige scenarioene, risikoen og alvorlighetsgraden. Gruppen lister også tiltak for å forhindre problemene. Gruppen er samstemte om planen. Ligger under vedlegg 3.3. Milepælsplan Milepælsplanen er konkrete mål vi skal ha gjennomført. Gruppen gir seg selv absolutte datoer for når målene skal være utført. 14

15 Aktivitetsplan Gruppen har satt opp en aktivitetsplan for hvilke oppgaver som skal ha gjøres og har gitt det en tidsperiode for når det bør være ferdig. Planen er representert ved et Gantt-diagram. Aktivitetsplanen er en form for en milepælsplan, men er mer omfattende. Her kan man kun kan begynne på en oppgave etter at en gitt er ferdigstilt. Til forskjell fra milepælsplanen er ikke datoene absolutte, de er ment som veiledende frister. Møtereferater Gruppen har skrevet referater fra møtene med veileder og oppdragsgiver. 15

16 3.6.1 Møter med veileder og oppdragsgiver 3.6 Arbeidsprosess Vi hadde faste ukentlige møter med veileder (mandager), hvor vi oppsummerte progresjonen til databasen, nettsiden og dokumenteringen. Det ble opprettet en felles Dropbox mappe hvor informasjon ble delt oss imellom og med veileder. En notis ble sendt til veileder og gjorde han oppmerksom på endringer når det var aktuelt, slik at han kunne lese igjennom. Med oppdragsgiver ble det gjennomført både en felles videokonferanse med veileder og møter hvor det kun var oppdragsgiver og gruppen. Et av gruppemedlemmene sto i direkte kontakt med oppdragsgiver og kunne derfor få daglige tilbakemeldinger relatert til prosjektet. Tilbakemeldingene fra både veileder og oppdragsgiver gjorde at vi etterhvert fikk et klart bilde over hvordan vi mente prosjektet skulle se ut og oppføre seg. Gode innspill til teknologier vi vurderte å benytte og nye ideer som oppstod ble ofte tatt godt imot av oppdragsgiver. På den måten hadde vi litt frihet til å utforme løsninger vi selv mente ville passe. Produktet ble jevnlig vist frem til oppdragsgiver og mot slutten av prosessen, når prototypen nærmet seg ferdigstillelse, fikk oppdragsgiver muligheten til å prøve nettsiden Arbeidsfordeling I begynnelsen startet gruppen med å jobbe felles om å løse Modellen i MVC, som går opp mot databasen. Slik at alle på gruppen forsto fra start av hva grunnsteinene i prosjektet dreide seg om. Utformingen av modellene ble også skissert i felleskap, slik at ikke uenigheter skulle oppstå etter mye arbeid. Når vi hadde oppnådd en generell enighet om den videre utførelsen, ble oppgaver fordelt i større grad. Vi lagde tidlig et Gantt-diagram som også ble benyttet som et oppgavefordelingsverktøy. I tillegg brukte vi Scrum metodikken via nettjenesten Trello. Vi valgte å holde oss til våre arbeidsoppgaver, uten å rullere inn alle gruppemedlemmene på hver oppgave. Når det er sagt, så var det heller ingen "låste" oppgaver. Trengte man hjelp så fikk man hjelp av andre på gruppen. Det har vært enkelt å hjelpe hverandre siden vi har møttes daglig for å jobbe med prosjektet. Gjennom denne metoden føler gruppen prosjektet ble mer effektivt. For at samtlige skulle få læringsutbytte av oppgaven var det likevel 16

17 nødvendig at alle tok del i oppsettet av de forskjellige delene (modellen, view og controller), bare ikke i like stor grad. Man hadde sine hovedområder å jobbe med Prosjektdagbok Gruppen skrev møtereferater fra samtlige møter med veileder og oppdragsgiver. Vi prøvde også å skrive ned diskusjoner og ideer vi hadde på egenhånd. Ideene kunne vi overbringe videre til oppdragsgiver og veileder for å få svar på. Mens diskusjonene var viktig å dokumentere for å begrunne valgene våre. Koden har kommentarer slik at selv de på gruppen som ikke har skrevet koden kan forstå hva den gjør Arbeidsplass Gruppen har stort sett jobben på HIOA sine lokaler. Her har vi koblet oss opp på skolen sitt nettverk, og våre egne hjemmeområder. Med VPN så har vi også kunnet jobbe hjemmefra. 17

18 4 Om utviklingsprosessen 4.1 Oppstart Gruppen ble dannet høsten 2013 av tre studenter som hadde jobbet sammen før og kjente hverandre godt. En gruppeside ble opprettet, hvor vi satte opp en samarbeidsavtale som alle ble enige om. Gruppen så på potensielle oppdragsgivere via HIOA. I mange av oppdragene var det ønskede rammeverk som gruppens medlemmer hadde begrenset kjennskap til og andre oppdrag virket som enkle nettsider for å promotere den aktuelle oppdragsgiver. Vi vurderte flere, men fikk samtidig inn en forespørsel fra en av gruppemedlemmenes foresatt om et oppdrag som skilte seg ut. Prosjektet var unikt da det ikke fantes lignende løsninger på markedet. Samtidig kombinerte det flere elementer vi hadde ervervet kunnskap om under skolegangen her på HIOA og det var rom for å utvide den faglige kunnskapen. Etter et innledende møte hvor oppdragsgiver forklarte oppgaven nøyere, fikk gruppen bekreftet at dette var en oppgave vi gjerne ville ta på oss. Prosjektet inneholder endel ord og uttrykk som ikke er dagligtale for enhver. Ettersom det var en av gruppens foresatte som var oppdragsgiver, hadde også dette gruppemedlemmet god kjennskap til miljøet og uttrykkene og kunne forklare nøyere hva de innebar og sammenhengen dem imellom. Denne forståelsen var viktig for sammensetningen av databasen, og totalbildet i forhold til hvordan det i hele tatt kunne lønne seg å lage et slikt prosjekt. Etter litt tid hadde alle god forståelse av hva som skulle lages. 18

19 4.2 Avgrensning og problemstilling "Bruker ønsker å få opprettet en smøredatabase. Hvordan kan vi på best mulig måte utvikle et verktøy som kan benyttes til å lagre data om produkter, forhold, resultater med mer? Hvordan gjøre databasen lettfattelig å benytte? Samtidig som den kan være tilgjengelig både online og offline?" Gruppen skisserte dette som problemstilling. Med den så prøver vi å sette en grense for hvor avansert og komplisert utformingen av databasen skal bli. Det er ønskelig fra oppdragsgiver side å få et verktøy som er intuitivt, oversiktlig og lite tidkrevende å benytte. Produktet skal, for å si det på en annen måte, nesten fungere som en avansert notatbok. Så hvordan går vi frem med oppgaven? Utfordringene ligger i å få dokumentert dataene. Skismurning som "fag" blir mer komplisert jo mer tid og penger man legger i det. Det finnes utallige produkter og verktøy som benyttes på forskjellige forhold, og noen ganger virker de på forhold de i utgangspunktet aldri var tiltenkt å fungerer på. Dette gjør jobben til en smører omfattende dersom man skal ha marginene på sin side i skisporet. "Jobben" til en smører går kort sagt ut på å teste forskjellige produkter fra ulike produsenter opp mot hverandre og velge ut de som fungerte best. Utfordringen våre ligger i at de resultatene smørerne får, utelukkende er basert på smørernes egne erfaringer og tester. De er med andre ord subjektive og er ikke eksakt vitenskap. Det er heller ikke nødvendigvis mulig for en annen smører å lese dataene og få de samme resultatene av å benytte produktene. De vil nok få relativt likt resultat, men det er omskrevet, det er egne erfaringer som rår hos smørerne. Det er en mal for hvordan legge på pulver på skiene, hvordan sette manuell struktur, hvordan smøre feste osv. men i realiteten har i midlertidig de fleste smørerne, over tid, lært seg egne teknikker og metoder som de sverger til. Dette gjør at resultatene kan bli noe forskjellige for smører A og B. Dette kalles ofte for taus kunnskap, vi tar opp mer omkring temaet under "Faglige utfordringer" 4.6. Vi tenker, i samråd med oppdragsgiver, at det å legge inn alle detaljer omkring hvor mange lag smøring som ble brukt, hvor hardt den manuelle strukturen ble lagt og hvor lenge 19

20 smørejernet var i kontakt med skien ved pålegging av pulver, blir mer arbeid for brukeren å huske og skrive opp enn det han tar seg bryet med. Dette er som nevnt allerede, erfaringer smører A sitter på, og vil gjøre likt til neste gang uansett. Det er også vanskelig å dokumentere nøyaktig hva som er gjort, da dette er en taus kunnskap. Vi velger å konsentrere oss om fakta, hvilke ski ble valgt? Med hvilken slip? Hvilke produkter? Det eneste stedet det kan være verdt å ha med "detaljnivå" er på manuell struktur. Dette er et redskap som kan benyttes på bakski, framski, eller hele skien, og i miks med andre strukturer. Det bygger litt på erfaring, men går også under rene fakta. Kort forklart er en manuell struktur en stålvalse som setter ett mønster i sålen på skien uten å skade den slipen som allerede er satt med en maskin. En ski har fått preget inn en slip hos en fabrikk eller leverandør, den er permanent helt til en ny slip blir satt, men over denne slipen, kan man sette en struktur. Strukturen blir "vasket" ut nå man glider skiene. Altså, disse manuelle strukturene har mange forskjellige typer mønster som kan benyttes og det er forksjellig hvor mye trykk en smører legger på valsen. Funksjonen til den manuelle strukturen er å drenere vannet/fuktigheten i snøen. Forskjellige varianter av manuell struktur testes ofte på ulike måter og hvordan den påføres går også under taus kunnskap. Hvordan strukturen påføres er altså vanskelig å dokumentere, vi kan dokumentere hvor på skien den er brukt, men ikke hvor hardt eller løst. Bruken av databasen skal være slik at oppdragsgiver og noen av hans medsmørere skal benytte den. De er stort sett samkjørte i sine erfaringer og kan ved tvil spørre hverandre hvis uforutsette situasjoner oppstår. Et annet smøreteam vil ha andre erfaringer og kan bygge opp databasen etter egne resultater som vil stemme overens med det de vet. 20

21 4.3 Første fase - Databasen Det første vi begynte å se konkret på opp mot oppgaven, var hvordan databasestrukturen skulle se ut. Oppdragsgiver hadde gitt oss punkter som han ville ha med i databasen, sammen med kravspesifikasjonen utgjorde disse en mal på hva vi skulle ha med, og det ble vår oppgave å få det til å passe. Under er punktene oppdragsgiver ønsket å ha med: -Glid. Består av glider, pulver og topping -Feste. Består av Base, klister og voks -Struktur -Snøtype -Temperatur -Luftfuktighet -Ski nr -Ski slip -Sted -Dato -Kommentar Vi startet med å lage et logisk skjema med hjelpeverktøyet Microsoft Workbench (Figur 4.1), plottet inn aktuelle entiteter og deres attributter og prøvde å sette det opp med relasjoner. Utseende i Workbench ble ikke så oversiktlig som ønsket. Vi besluttet derfor å ta et steg tilbake og lage en enkel oversikt over tabellene. Med det fikk vi en bedre forståelse av databasestrukturen som vi senere kunne bygge videre på. 21

22 Figur 4.1 Microsoft Workbench ER-diagram Figur 4.2 enkel oversikt 22

23 Figur 4.2 viser en mer ryddig oversikt over alle tabellene vi så for oss at skulle implementeres. Vi la også inn streker som representerer relasjonene mellom tabellene. Dette er en helt enkel oversikt, som illustrerer hvordan de ulike tabellen er koblet sammen. Denne modellen representerer hvordan vi tenker at databasen skal henge sammen. Etter å ha satt opp dette diagrammet prøvde vi å beskrive hva hver av entitetene skulle inneholde og hvordan de enkelte attributtene skulle oppføre seg. Gruppen startet opp med å se for seg at databasen inneholdt attributter med boolske variabler. Altså enten så er det sant, eller så er det usant. Dette kunne nok fungert for entitetene Bruker, Snøtype og deler av Omstendighet tabellen. Men for de entitetene som inneholder produkter passer det ikke med boolske variabler. Vi kunne delt det opp og brukt tekstbokser eller nedtrekksliste i noen tilfeller, og valgknapper i de andre. Men etter et møte med oppdragsgiver, hvor vi blant annet diskuterte dette, kom vi frem til at en enklere løsning blir det beste for bruker. Med enklere løsninger menes det at vi hjelper til der det er naturlig, som i dato, bruker eller skinummer. Mens de resterende feltene som krever interaksjon fra bruker, blir skrevet i et tekstfelt. Dette betyr at alle dataene som blir skrevet inn i tekstfelt også blir lagret som tekst. Vi vurderte å lage en produkttabell som skulle inneholde alle produkttypene som blir benyttes. Tanken var da at hvis produktet var lagret i databasen, så kunne bruker velge produkt fra en liste. Man skulle også kunne legge inn og fjerne produkter fra produkttabellen. Gruppen så på muligheten for å importere produktkatalogene til de forskjellige produsentene, fra en nettside eller lignende. Problemet er at produsentene ikke opererer med denne praksisen pr. dags dato. Det er også utfordrende at man i blant bruker hjemmelagde produkter eller blander flere ulike produkter til et nytt. Oppdragsgiver var interessert i å fylle ut produktene selv. Dette fordi det ofte kan være flere lag med produkter innen samme kategori. Eksempel på dette er for eksempel ved påføring av voks, her kan det bli brukt opp til 4 forskjellige vokstyper under samme ski. 23

24 Gruppen tenkte at det ville være naturlig å skrive hvilke lag som legges når, og eventuelt hvor mange lag som ble lagt av hver. Men dette temaet inngår i den såkalte tause-kunnskapen en smører besitter. For erfarne smørere ville dette feltet muligens fremstå som overfladisk og unødvendig. Det ville ikke bidra med noe smøreren ikke viste allerede. Smørerne vet hvilke lag han skal legge hvor og når, smøreren kan heller ikke smøre identisk fra gang til gang når det gjelder antall lag. Men for en smører under opplæring eller lignende, kan det være hensiktsmessig å notere mer av prosessen i de forskjellige feltene, dette for å forsøke å tilegne seg den tause kunnskapen han enda ikke har ervervet. Forholdene, traseen og ikke minst utøverne oppå skiene forandrer seg og spiller inn i vurderingen av hvordan feste bør legges. Vi skal ta for oss temaet taus-kunnskap senere i rapporten under Faglige utfordringer (4.6), men poenget blir at dette er vanskelig for en smører å dokumentere og vanskelig å lese noe ut av, dermed dropper vi laginndeling helt fra vår database. Det mest avgjørende poenget for å ikke lagre produktene for seg selv, var at når brukeren skal søke i databasen, så søker han aldri etter produkter. Det er vanskelig å vite hvilke produkter som er relevante for stedet. Bruker ønsker heller å søke etter sted, temperatur eller snøforhold, for så å se hvilke produkter som ble brukt under disse værforholdene. Altså blir aldri produkt et søkekriteriet. Figur 4.3 ER diagram, endelig utfall. 24

25 Vi viser i dybde hver enkel entitet og hva den inneholder i figur Bruker Det var et kriteriet i kravspesifikasjonen, under avsnitt 2.3 om ikke funksjonelle krav, at man skulle kunne logge seg inn på nettsiden, da trenger man en form for identifisering. Gruppen har valgt å lage en tabell Bruker, hvor man lagrer data om forskjellige brukere. Hver bruker kan lage seg et passord som de bruker til å identifisere brukeren med. Vi har også gitt mulighet til å velge mellom smører og utøver. Brukertabellen blir også brukte når man skal registrere et innlegg. For mer om denne funksjonen se Oppsummeringstabell lenger nede i dokumentet Innlegg Innlegg er den tabellen hvor alle de andre IDene blir lagret og lagt under en Innleggs ID. Det blir også lagt inn sted og dato Omstendigheter Omstendigheter inneholder alle data om værforhold, snøforhold og snøtype. I starten planla vi å legge snøtype som en egen entitet med forskjellige attributter. Dette gikk vi senere bort ifra da det kan variere hva slags snø det er på et sted, det kan for eksempel være en blanding av natursnø og kunstsnø, og en rekke andre sammensetninger. Ved å gi brukeren et tekstfelt å skrive i, står han fritt til å legge til sine egne betraktninger eller observasjoner, som vi ikke hadde tenkt på, eller som var en del av problemstilling per dags dato. Selv om man risikerer dobbeltlagring eller store felt med mye tekst, valgte vi etter samtaler med oppdragsgiver, at den beste løsningen var å la brukeren fylle inn observasjonene manuelt Skiinfo 25

26 Alle skipar er nummererte med unike nummer, det gjør dem identifiserbare. To like par ski, av samme merke og modell, er ikke identiske å gå med for utøveren. Som nevnt i introen til oppgaven (2.3 "Noen fakta om skismurning og begreper i oppgaven"), så kommer ikke ski med en slip. Dermed måtte vi ha muligheten åpen for at det ikke måtte, men kunne være en slip lagret under skipar tabellen. Gruppen måtte også tenke på at bruker skal kunne bruke manuelt strukturverktøy (se avsnittet 4.2 "Avgrensning og problemstilling" for å forstå mer om manuell struktur). Vi la derfor opp til at man skulle legge inn hvor strukturen ble lagt på skien. Lagringen av denne dataen ble løst ved å lage to tabeller ekstra, skipar og strukturtype. I skipar lagres skinummer og hvilken slip skiene har. Den andre tabellen inneholder informasjon om strukturen som blir brukt. Disse blir da lagret under en felles skiinfo_id som blir sendt til Innleggstabellen Glid Glider er "lag 1" i prosessen med å gi en ski glid. Ettersom det per dags dato finnes en mengde forskjellige gliderprodukter, og disse igjen er kombinerbare, har gruppen nok en gang vurdert det dit hen at det å skrive inn hvilket produkt man har brukt i et tekstfelt er den enkleste løsningen. Vi så tidlig på en løsning der hver glider kombinasjon fikk en verdi, slik at man kun lagre en verdi av hver kombinasjon. Med et tekstfelt gir vi brukerne frihet til å tilføye kommentarer han selv ønsker å ha med. Pulver er "lag 2" i prosessen med å gi en ski glid. Som med glider, så kan flere pulverprodukter kombineres. Dette gir tilsvarende løsning som med glider, et tekstfelt hvor smører kan skrive inn hvilke produkter og eventuelt andre betraktinger han ønsker å ha med. I motsetning til glider, er det ikke alltid man bruker pulver. Når pulver påføres benyttes det et smørejern, temperaturen på jernet blir lagret sammen med type pulver. Det var et krav fra oppdragsgiver å ha med jerntemperatur som er benyttet ved påføring av pulver. 26

27 Siste delen i glidprosessen, og "lag 3", er topping. Det er uvanlig å kombinere forskjellige toppingprodukter. Alle delene av Glid blir lagret i Glid_ID og sendt til Innleggstabellen Feste Her, som i glid, kan produktene blandes. Det eneste produktet man alltid benytter når man legger feste tilhører Base. Ellers er det null eller flere lag Voks og Klister, for å oppnå en type feste. På samme måte som i glid, tastes benyttede produkter inn i et tekstfelt med mulighet for en kommentar fra bruker Oppsummeringstabell Oppsummeringstabellen er en tabell som består av et felt dedikert til eventuelle kommentarer eller oppsummeringer smøreren måtte ha til innlegget. Siden smøreren står fritt til å skrive det han vil inn i de andre tekstfeltene, så det er mer betraktninger om løpet, eller avvik fra det smøreren pleier å gjøre som ender opp i kommentarfeltet. Kanskje vil utøveren komme med en vurdering av hvordan han opplevde skiene den aktuelle dagen, og dermed blir det muligens brukt av utøver i samråd med smører. Vi har med en karaktersetting av innlegget også. Karakteren vil gå fra 1-6, hvor 6 vil være best. Det er opp til smører og utøver å vurdere karakteren. Hovedgrunnen for å ha med en karakter av innlegget er at en smører raskt kan se om innlegget er relatert til en god eller dårlig smøring. Hvis bruker søker på f.eks. sted og temperatur, og får opp 3 resultater, hvor to var karakter 2 og ett var karakter 6, så vil det med høyest karakter virke som den beste resepten for det stedet. Det kan selvsagt også være interessant for smøreren å se på de innleggene med lav karakter for se hva man ikke burde gjøre. Selv om det står mer utfyllende informasjon inne i selve innlegget, så vil denne vurderingen av innlegget, i tillegg til å kunne raskt se hva som er bra, kunne eliminere antall innlegg smøreren har interesse av å lese for å få informasjonen det søkes etter. 27

28 Problemet er at det ikke finnes noe direkte målbart resultat her. Man kan aldri vite om skiene var en karakter 6 verdig. Selv om løperen kommer på førsteplass kan skiene vært lang fra optimale. Både løper og smører sin vurdering kan bli overvurdert siden resultatet ble bra for utøver. På en annen dag med annen motstand kunne resultatet (for utøver) blitt helt annerledes, og dermed kanskje også vurderingen. 28

29 4.4 Andre fase - Layout Betraktninger brukergrensesnitt (GUI) Brukergrensesnitt også kjent som GUI, graphical user interface, kan sies å være mer enn vinduet mellom modellen og funksjonaliteten. Ofte er det slik at det er GUI som er avgjørende for om brukerne sitter igjen med et godt inntrykk etter å ha arbeidet med et program. Selv om programmet er omfattende og har en mengde gode funksjoner som konkurrerende systemer ikke tilbyr, hjelper dette lite dersom brukerne ikke finner det intuitivt og lett å bruke. Dermed er det viktig at brukerne føler de mestrer programmet uten å måtte gjennom en lang læringsprosess. I vårt tilfelle er det viktig at brukerne, som er skismørere, sparer tid på å registrere ny data og gjøre søkeprosessen vesentlig kortere enn den er i dag. Om brukerne mener brukergrensesnittet er for komplisert vil det medføre at de heller fortsetter med dagens penn og papirsystem og prosjektet kan ikke sies å ha nådd sine mål. For designeren er det viktig å sette seg inn i brukernes arbeidsprosess og tankegang. Denne preges i høy grad av taus kunnskap, med mye informasjon som vanskelig lar seg dokumentere (se avsnitt om taus kunnskap under faglige utfordringer 4.6.1). Det vi vet er hvilke data som er av interesse for skismørerne og i hvilken rekkefølge disse som oftest loggføres. Vi har også tilegnet oss informasjon om hvordan det er mest hensiktsmessig for brukerne å føre inn slike data. Her har det for eksempel vist seg at en kombinasjon av nedtrekkslister og manuell inntasting er å foretrekke, avhengig av type data som skal registreres. Hindringer i arbeidsflyt kan være grunn nok til å ikke ta programmet i bruk, derfor har vi vektlagt brukernes ønsker og tilbakemeldinger ved design av GUI. De skal føle de har kontroll på verktøyet, noe vi gjennomfører ved å gi oversikt og tilbakemeldinger på utførelse av handlinger. Eksempler på slik respons er at brukeren ser forandring når man trykker på en knapp og at vi har fargekodet de ulike seksjonene slik at man vet hvor man befinner seg og ser sammenhengen (figur 4.4). Brukeren skal oppleve kontroll gjennom gode tilbakemeldinger. Dersom en ikke tillat handling blir forsøkt utført, er det viktig at man forstår hvorfor den aktuelle handlingen ikke er lov, korte konsise tilbakemeldinger er å foretrekke. 29

30 Figur 4.4 Hovedmenyknapper med respons. Vi har vurdert å implementere en progressbar, hvor man får et visuelt inntrykk av hvor lang tid søk tar å laste og så videre, men slik som systemet fungerer er all lastetid såpass minimal at dette synes unødvendig. Det mest essensielle punktet for et godt brukergrensesnitt er trolig at det fremstår som intuitivt. Det skal være selvforklarende å benytte de ulike funksjonene uten å måtte tilegne seg bakgrunnskunnskap gjennom manualer eller dokumentasjon. Dersom bruker er usikker på hvilke valg som er mulig har vi også lagt til en hjelpeboks med kortfattet forklarende tekst. Man har også tilgang til forsiden og alle undersider fra header til enhver tid, dersom man forsøker å navigere seg til en annen side før en økt er lagret blir man varslet om dette. Vi har forsøkt å la oss inspirere av brukernes miljø når vi utformet de visuelle elementene. Bakgrunnen består for eksempel av skispor, et særdeles sentralt element i smørernes hverdag. Fargekoder er inspirert av typiske voks og klister produkter og fargene på ikonene man trykker på for å komme til de ulike undersidene går igjen i disse Utvikling av GUI Utformingen av GUI har gått gjennom flere faser og vært gjennom en iterativ utviklingsprosess. Dette har gitt oss muligheten til å evaluere og teste de ulike forslagene underveis og oppdragsgiver har kunnet bidra med tilbakemeldinger som vi har tatt hensyn til i neste runde. Gjennom gjentatte iterasjoner sikres det at tjenesten forbedres kontinuerlig og at svakheter enkelt kan lukes bort uten for omfattende endringer. 30

31 Figur 4.5 Skjermbilde av første iterasjon Figur 4.5 viser et av de første utkastene til hvordan vi så for oss gruppering av søke- og registreringstabeller. Her prøvde vi oss frem for å finne ut hvordan man kunne sortere ulike kategorier og hvilke elementer som var viktig å ha med i databasen. På dette stadiet hadde vi ikke begynt å tenke på den visuelle utformingen. Utstrakt bruk av grafiske elementer tidlig i prosessen kan dessuten virke forstyrrende på den videre utviklingen og vanskeliggjøre diskusjonen med oppdragsgiver. Vi så det som et poeng at de første utkastene vi la frem til arbeidsgiver fremstod som uferdige og på skissebasis. På dette stadiet ønsket vi først og fremst tilbakemelding på hva oppdragsgiver ville ha med i systemet og om vi var på rett spor i forhold til gruppering. 31

32 Figur 4.6 Skjermbilde av andre iterasjon Med tilbakemeldinger fra oppdragsgiver i mente, luket vi bort unødige elementer og kom med et nytt forslag med tydeligere gruppering etter en kort sprint. 32

33 Figur 4.7 Skjermbilde av andre iterasjon, søkeside Figur 4.7 viser et eksempel fra andre iterasjon, her fra søkesiden. Utkastet var nyttig i den forbindelse at det gjorde det lettere å diskutere hvordan GUI skulle se ut og oppføre seg med oppdragsgiver. Her har vi begynt å ta inn noe grafiske elementer i form av bakgrunnsbilde. I samråd med oppdragsgiver fant vi ut at slik det fremstår i figur 4.8, tar bakgrunnen for mye fokus bort fra funksjonaliteten. Noe vi endret på i neste iterasjon. Figur 4.8 Skjermbilde av andre iterasjon, ikonbasert 33

34 I samme iterasjon presenterte vi et mer ikonbasert forslag, tanken her var å se om oppdragsgiver kunne være interessert i en alternativ form i forhold til hva som hadde blitt diskutert tidligere. Vi kom frem til at slik skissen fremstod kunne den fungere greit på nettbrett, men den var ikke optimal i forhold til bruk på andre plattformer. Forslaget gav oss i midlertidig inspirasjon til å arbeide videre med ikoner til bruk i menysystemet. Figur 4.9 Utvikling av bakgrunn og rammer. Vi valgte tidlig at bakgrunnen skulle være inspirert av brukernes arbeidsmiljø og valget falt på skispor. Vi ønsket at bakgrunnen skulle være stemningsskapende, uten å ta fokus bort fra funksjonaliteten på sidene. Vi besluttet derfor å duse den ned og redusere kontrasten for å gjøre det hele mindre støyende og fremstå mer harmonisk. Figur 4.10 Utvikling av ikoner 34

35 Figur 4.10 viser utdrag av den iterative utviklingen av enkelte ikoner som er benyttet i systemet. Vi startet med firkantede ikoner, med en nøytral og dus farge som gikk igjen på alle ikoner. Ikonene er stiliserte figurative motiver som skal illustrere deres funksjon. Deretter differensierte vi disse ved å tilegne dem fargekoder. I de to øverste eksemplene var kategoriene registrer data, søk i databasen og registrer ny bruker. Ikonene var tenkt å vises på fremsiden og fungere som en navigasjonsmeny. Vi kom frem til at legg til ny bruker var en funksjon som ikke ville bli benyttet på daglig basis og at det dermed ikke var hensiktsmessig at funksjonen skulle være så fremtredende. Dermed besluttet vi å endre legg til ny bruker til et innstillingsikon, inspirert av et verktøy i form av en stilisert skiftenøkkel. Ny bruker blir en underfunksjon på denne. Under innstillinger vil det også være rom for å legge til ytterligere funksjoner. Som en ren visuell vri endret vi så den firkantede bakgrunnen på ikonene til sirkler. Objektivt sett synes både oppdragsgiver og gruppen at denne forandringen gav et renere og mer moderne uttrykk. Figur 4.11 Fremside -Navigasjonsmeny Gjennom den overnevnte prosessen kom vi frem til et resultat representert i figur Figuren viser hvordan fremsiden på nettsiden er tenkt utseendemessig etter innlogging. Bakgrunnen er tonet ned for å ikke konkurrere med de funksjonelle aspektene, de tre hovednavigasjonsvalgene er representert ved ikonene registrer data, søk i databasen og 35

36 innstillinger. Disse forstørres når musepeker er over dem og gir med det brukeren tilbakemelding om funksjonalitet. Headeren over er gjennomgående og tar brukeren tilbake til fremsiden fra alle undersider, denne skifter farge ved mouse-over. Logg ut knappen nederst til høyre logger brukeren ut, også denne forstørres før den trykkes på og går igjen på alle sider. Figur 4.12 Utkast for de 3 ulike hovedseksjonene Figur 4.12 viser et oversikts utkast av de 3 hovedseksjonene. Fra høyre er registrer data, søk i databasen og innstillinger. De ulike seksjonene har samme fargekode som deres respektive ikoner for å lette navigering og lesbarhet. 36

37 4.5 Tredje fase - Sluttresultatet Figur 4.13 Innlogging Figur 4.13 viser innlogging til nettsiden og er den første siden man møter. Bruker må ha fått tildelt brukernavn og passord for å få tilgang. Når bruker har fått dette har vedkommende anledning til å benytte alle funksjonene i systemet også å opprette flere brukere. Dette fordi vi ønsker å ha en form for innlogging slik at ikke alle kan ta i bruk databasen. Selve innloggingsiden består av en boks (figur 4.13) med brukernavn og passord og en "logg inn" knapp. Det er implementert en automatisk logg ut funksjon som trer i kraft dersom den innloggede brukeren har vært inaktiv for lenge. Figur 4.14 Hovedmenyikoner 37

38 Neste side er en "hovedside". Den vil bestå av tre hovedvalgmuligheter (figur 4.14). Registrer innlegg, søk i eksisterende innlegg og ikon for innstillinger som blant annet har en legg til bruker underside. På alle sidene er det en mindre framtredende logg ut knapp/funksjon nederst. Vi tenkte å bruke ikoner i tillegg til skrift for å understreke hva og hvor de forskjellige valgene tar deg. I tillegg vil ikonene bli større når man holder musen over ikonet for å fremheve hvilket valg man er i ferd med å ta (figur hovedmenyikoner). De tre ikonene vil være synlige i en header (figur header) på de andre sidene også, sammen med en tilbakeknapp som tar brukeren et steg bakover. Fargene og ikoner er inspirert av målgruppens habitat. Vi har forsøkt å holde oss til selvforklarende ikoner, uten for mye detaljer, som er intuitive i bruk. Eksempelvis er registrer ny data ikonet utformet som en stilisert skiløper, søk i data ikonet fremstår som et forstørrelsesglass og ikonet for innstillinger er inspirert av en skiftenøkkel. Fargene som er benyttet er inspirert av klassiske skismøringsprodukter, som f.eks. Swix Blå Extra. Figur 4.15 header Headeren (figur 4.15) går igjen på alle sidene og fungerer som en navigasjonsmeny på samme måte som hovedsiden. Ikonene består av registrer data, søk i databasen, innstillinger og en tilbakeknapp. I motsetning til på hovedsiden er det i ikke implementert tekst under disse. Vi mener ikonene i utgangspunktet er selvforklarende og ettersom forklarende tekst finnes på hovedsiden er det ikke nødvendig å ha med her. Tilbakeknappen finnes kun i headeren og har ikke forklarende tekst noe sted. Ikonet er i midlertidig velkjent og ofte brukt i andre sammenhenger. Visuelt sett er det også penere å unngå tekst i slike sammenhenger. 38

39 Figur 4.16 Oversiktbilde av registrer data funksjonen. Figur 4.16 viser oversikt for registrer data funksjonen. Headeren øverst tar brukeren tilbake til hovedmenyen, i navigasjonsmenyen under denne kan man navigere til de andre seksjonene. De ulike input feltene er delt opp og kategorisert etter oppdragsgivers ønsker. Her er det en kombinasjon av manuell inntasting og nedtrekkslister der det er hensiktsmessig. Til hvert felt er det en hjelp-knapp som viser bruker en hjelpeboks med informasjon om hvordan registrer de ulike data. Først identifiseres hvem som gjorde testene, lokasjon og aktuell dato. Videre tenker vi alt som går under værdata ordnes under en bolk, ski-info under en, glid under en, feste under en og til slutt en oppsummeringsmøte som inneholder kommentar og karakter av innlegget. Denne bolken gjør fremtidig søk på de aktuelle data mer verdifullt. For å lagre innlegget trykker man på ikonet som er utformet som en diskett, man får så tilbakemelding på at innlegget er lagret (figur 4.17), før man sendes tilbake til hovedmenyen etter fem sekunder. Sidene er laget slik at man kan zoome inn og ut uten at dette påvirker bakgrunnens utseende. 39

40 Figur 4.17 Registrert innlegg Figur 4.18 Oversiktsbilde over søk i data funksjonen Figur 4.18 viser oversiktsbilde av søk i datafunksjonen. Headeren og navigasjonsmenyen fungere på samme måte som i registrer datafunksjonen. Det er mulig å filtrere registrert data etter sted, temperatur, snøtype og rangering. Dette etter ønske fra oppdragsgiver da det er de kriteriene han har mest behov for å søke i. På søkesidens hovedside får man automatisk opp de seneste registrerte innleggene og utvalgt informasjon om disse. Informasjonen som listes ut her er sted, dato, temperatur, luftfuktighet, snøtype og karakter. Karakterfeltet vil gi brukeren en pekepinn på resultatet av det aktuelle innlegget og om det er ønskelig å studere dette mer i dybden. Ved å trykke på plussikonet ved innleggets venstreside får man opp 40

41 ytterligere detaljert informasjon om det enkelte innlegget. Man vil da ledes til en ny side med komplett listing av registrerte data. Den detaljerte visningssiden vil ligne på siden hvor bruker registrerer innlegget, i den form av at den er inndelt etter de samme gruppene (Værdata, Ski-info, Glid, Feste og Oppsummering). Øverst på siden vil det stå sted, dato og hvilken bruker som registrerte innlegget. Når man har studert dataene ferdig kan man, som på alle andre sidene, navigere seg tilbake til hovedsiden, til registrer datasiden, eller komme tilbake til oversiktssiden for søk, ved å trykke på tilbakeknappen eller søkeknappen. Figur 4.19 Detaljert visning av et innlegg 41

42 Figur 4.19, viser detaljert visning av et utvalgt innlegg. I tillegg til informasjonen man får listet ut i oversiktsvisningen listes det ut all informasjon som har blitt lagret i innlegget. Her inkluderes blant annet ski-informasjon, hvilke smøre produkter som er benyttet og en utfyllende kommentar. Figur 4.20 Innstillinger På innstillingsiden (figur 4.20) har man pr. dags dato mulighet for å registrere nye brukere og se oversikt over registrerte brukere. Det kan i fremtiden være aktuelt å utvide denne siden med ytterligere funksjoner. Databasen er nå klar for å testes av oppdragsgiver og man vil etter denne testfasen kunne oppdage eventuelle tilleggsfunksjoner man kan implementere her. Figur 4.21 Registrer ny bruker 42

43 Når en registrer ny bruker (figur 4.21) lager man brukernavn og passord. Det må også spesifiseres om vedkommende er utøver eller smører. Dette fordi det er relevant data som brukes når innlegg skal registreres. Figur 4.22 Ikonoversikt Figur 4.22 viser samtlige ikoner vi har laget klar til brukergrensesnittet. Gule ikoner tilhører registrer data delen, grønne ikoner tilhører søk i database delen og blå ikoner tilhører innstillingsdelen. Tilbakeknappen og logg ut knappen går igjen på samtlige sider og er 43

44 dermed ikke knyttet opp mot noen av de tre hovedkategoriene. Ikoner som er rammet inn er enda ikke implementert, men vi ser dem som aktuelle i prosessen med å videreutvikle databasen ytterligere. Grunnen til f.eks. at slett ikonet ikke er tatt i bruk på det nåværende stadiet er at vi ikke ønsker at den generelle bruker skal kunne slette innlegg og annen data. Når en administratorkonto er på plass vil det være aktuelt å aktivere denne funksjonaliteten. Figur 4.23 Ny logo Gruppen har etter forespørsel fra oppdragsgiver også laget et forslag til ny logo for WillWest Sport (figur 4.23) 44

45 4.6 Faglige utfordringer Som nevnt tidligere, er det en utfordring å vite hva som er dokumenterbart og ikke for en smører. For å utdype mer om bakgrunnen for dette har gruppen satt seg inn i begrepet taus kunnskap Taus kunnskap Taus kunnskap også kjent som tacit knowledge, er erfaringsbasert kunnskap og viten man får i utøvelse av en aktivitet, fagområde, yrke eller lignende. Det er kunnskap som ikke uten videre lar seg forklare med ord. Dermed er det vanskelig å formulere slik kunnskap i en lærebok eller rutinebeskrivelse. Begrepet ble lansert av filosofen og legen Michael Polanyi i 1966 gjennom boken The tacit dimension. Begrepet omhandler situasjoner der ting er lettere å demonstrere og vise enn å skrive ned i en manual eller lærebok. Den som får noe demonstrert finner sin egen måte å gjøre det på, uten å sette ord på det, og skriver dermed et nytt avsnitt i den tause kunnskapen. "Vi kan vite mer enn vi kan si." (Michael Polanyi, 1966, s.16) Kunnskap som kan uttrykkes i ord og tall representerer bare toppen av isfjellet av all mulig kunnskap Eksempler Vi kjenner igjen en persons ansikt blant millioner av andre. Likevel er man som oftest ikke i stand til å uttrykke hvordan man evner dette. Når man ser et ansikt er man ikke bevist på de individuelle særtrekk ansiktet representerer. Man fokuserer ikke på øyne, nese eller munn, men heller ansiktet som en helhet. Et annet eksempel er hvordan man oppfatter språk. Det er ikke mulig å lære et nytt språk bare ved å pugge reglene for grammatikk. En som snakker morsmålet sitt lærer det ved ung alder og er tilnærmet uvitende om de grammatiske reglene de først lærer senere. Et mer industrielt eksempel finner vi gjennom Bessmer steel process. Bessmer solgte et patent for hans avanserte prosess for å produsere stål og ble saksøkt fordi kjøperne ikke klarte 45