PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON

Forord Dette dokumentet beskriver gruppens arbeid og metoder benyttet for hovedprosjektet ved Høgskolen i Oslo, avdeling for ingeniørutdanning, Informasjonsteknologi, vårsemesteret 2007. Prosessdokumentasjonen er i første rekke ment for sensor og veileder, men kan også brukes av andre som er interessert i å sette seg inn i oppgaven vår og måten vi har valgt å gjennomføre den på. Det forventes at leseren har grunnleggende datakunnskaper. Dokumentet forklarer hvordan vi har gått frem, hvilke valg vi stod ovenfor underveis i prosessen og hva vi har lært gjennom prosjektet. Hovedmålet med oppgaven var å kartlegge hva slags tjenester som er populære på dagens communitysider, for senere å utvikle disse slik at oppdragsgiver kunne implementere det i sitt eksisterende produkt. Temaene som blir beskrevet prosessdokumentasjonen vil bli mer detaljert beskrevet i andre deler av sluttdokumentet. Dokumentet er tilrettelagt for papirutskrift. Page 2 of 21

Innholdsfortegnelse Forord... 2 Innholdsfortegnelse... 3 1.Innledning... 5 1.1 Oppgaven... 5 1.2 Firmaet... 5 1.3 Dagens situasjon... 5 1.4 Rammebetingelser... 7 1.5 Implementering av funksjoner basert på kartlegging... 7 1.5.1 Rating... 7 1.5.2 Kommentarer... 7 1.5.3 Deling... 8 1.5.4 Nedlasting av delte låter... 8 1.5.5 Layout og design... 8 2. Arbeidsmetode og planlegging... 9 2.1 Idéfase... 9 2.1 Forprosjekt... 9 2.2 Kartlegging... 9 2.3 Planlegging... 10 2.4 Verktøy... 10 2.5 Prosjektdagbok... 10 2.6 Tilbakemelding... 10 3. Utviklingsprosessen... 11 3.1 Samarbeid i gruppen... 11 3.2 Samarbeid med oppdragsgiver... 11 4. Utvikling av produktet... 12 4.1 Database... 12 4.2 Kode... 13 4.3 Brukergrensesnitt... 13 4.4 Optimalisering... 15 4.5 Kompabilitet... 15 4.6 Sikkerhet... 16 4.7 Videreutvikling... 17 4.8 Ferdige løsninger... 17 5. Utfordringer og løsninger... 18 5.1 Utfordringer og løsninger... 18 Page 3 of 21

6. Avslutning... 19 7. Figurliste... 20 8. Kilder... 21 8.1 Internett... 21 8.2 Bøker... 21 8.3 Andre... 21 Page 4 of 21

1.Innledning 1.1 Oppgaven Oppgaven gikk ut på å kartlegge dagens communitysider for så å videreutvikle en nettside i.net for nedlastning av ringetoner i mp3-format for Smartlink AS. Nettsiden vi skal videreutvikle skal inneholde elementer fra de mest populære communitytjenestene, som f.eks brukerprofiler, rating-muligheter og kategorisering av låter. Nettsiden skal være enkel å bruke for enhver person uten spesielle datakunnskaper. Det skal også legges vekt på at bruker skal ha mulighet til å laste opp og tilpasse låter uten noen form for registrering. Dette for å få flest mulig brukere interessert i produktet uten at de må legge igjen privat informasjon. Ifølge oppdragsgiver forsvinner mange potensielle brukere dersom de må gjennom for mange steg før de får testet det aktuelle produktet. Selve registreringen skal ikke skje før bruker har valgt å lage en ringelåt/sms. 1.2 Firmaet Smartlink AS er et gründerselskap, grunnlagt i 2002 i Oslo, som utvikler mobile underholdningstjenester. Selskapets produkter retter seg både mot sluttkunder og bedriftskunder. Smartlink AS skal i år lansere en ny verdensomfattende lydog mobil-tjeneste (web og wap) hvor community-egenskapene til selskaper som YouTube.com og MySpace.com er sentrale. 1.3 Dagens situasjon I dag finnes det mange nettsteder som tilbyr lignende tjenester, men de fleste av disse tilbyr ikke brukeren å laste opp egne mp3-filer eller klippe ut deler av den. I tillegg tar disse nettstedene betalt for tjenestene. Phonezoo.com tilbyr de samme tjenestene som mymp3tone.com gjør, men de vesentlige forskjellene er at Smartlink sin løsning er uavhengig av mobiltype, operatør og land. Dvs at uansett i hvilket land du befinner deg, hva slags mobil du har eller hvilken operatør du bruker så kan du benytte deg av tjenesten. Phonezoo sin tjeneste er per dags dato kun tilgjengelig for amerikanske brukere og du må i tillegg registrere mobiltype og leverandør for å bruke tjenesten. Vi har ikke testet ut phonezoo.com men dette er informasjon oppdragsgiver har gitt oss. Smartlink tilbyr en revolusjonær løsning ved at brukeren registrerer seg første gang han eller hun ønsker å laste ned en låt til mobilen. Brukeren vil da motta et unikt bokmerke som gjør det mulig å hente ut låtene via wap på mobilen. Bokmerket bør lagres på telefonen slik at det blir enkelt å nå wapprofilen ved en senere anledning. Når det gjøres på denne måten blir det ingen utgifter for Smartlink. Brukeren betaler kun for nettrafikken, uavhengig av hvor mange låter man laster ned. Brukeren kan også laste ned de samme låtene flere ganger uten å måtte betale. Page 5 of 21

Figur 1.3.1 viser siden slik den ser ut idag og figur 1.3.2 viser utsnittsfunksjonen. For å teste ut dagens løsning besøk www.mymp3tone.com. Figur 1.3.1 Dagens design Figur 1.3.2 Velg utsnitt Page 6 of 21

1.4 Rammebetingelser Nettsiden vi skulle videreutvikle var programmert i.net og J#. Opplasting- og "utklippsbiten" er programmert i Java og Flash. Vi har skrevet om all koden fra J# til C#, siden J# forsvinner fra neste år. Ingen på gruppen hadde erfaring med.net fra tidligere, så dette har vi måttet lære oss for å kunne gjennomføre prosjektet. Vi på gruppen valgte å ta Webprogrammering i.net som valgfag på høgskolen dette semesteret med tanke på at vi skulle bruke dette utviklingsverktøyet i hovedprosjektet. Oppdragsgiver ønsket å benytte seg av ASP.NET-rammeverkets innebygde håndtering av registrering og innlogging. De ville også gjøre registreringen så kort som mulig så vi måtte tilpasse registreringsdelen slik at man slapp å skrive inn sikkerhetsspørsmål- og svar. De ville også ha et enkelere minimumpassord enn det som er standard i.net (minimum sju tegn, ett tall og ett tegn som hverken er tall eller bokstav). For å rate låtene ønsket Smartlink å benytte seg av ratingfunksjonen som er innebygd i AJAX Toolkit. Løsningen skal også fungere tilnærmet likt i de tre nettleserne Microsoft Internet Explorer, Opera og Mozilla Firefox. 1.5 Implementering av funksjoner basert på kartlegging Utifra kartleggingen ble vi mer bevisst på hva vi ville ha med og ikke ha med i vår applikasjon. Under kan du se hvilke funksjoner vi valgte å implementere. Dette er alle funksjoner som er populære og går igjen på de fleste communitysider. 1.5.1 Rating Dette er en svært populær funksjon ettersom det er mulig å følge med på toplister for forskjellige objekter(video, musikk osv). Den er også med på å gjøre at bruker logger seg inn oftere for å se om hans/hennes objekter er populær eller ikke hos andre. 1.5.2 Kommentarer Kommentering av objekter forekommer like ofte som rating. Det vil også ha noe av den samme effekten med tanke på at bruker oftere vil logge seg inn for å se hva andre mener om låtene/videoene deres. Page 7 of 21

1.5.3 Deling Det er også viktig for et community-sted at bruker har anledning til å dele sine objekter med andre brukere av nettstedet. I dette tilfellet vil det også være minst like viktig at brukeren faktisk kan velge å ikke dele låten(beholde den som privat). Til sammenlikning med f.eks YouTube vil aldri en bruker laste opp en video dit uten den hensikt at flest mulig skal få tilgang til den. På mymp3tone.com kan det være at du har en spesiell ringelyd du bare "MÅ" ha på mobilen din, men som du ikke ønsker at noen skal ha tilgang til. 1.5.4 Nedlasting av delte låter På mymp3tone.com vil det også være viktig at man ikke kun har muligheten til å høre på de låtene som andre brukere har lastet opp, men at det vil være mulighet til å legge disse til i sin egen wapprofil slik at de blir gjort tilgjengelig for nedlasting til mobiltelefon. 1.5.5 Layout og design For at brukere skal komme tilbake til et nettsted er det viktig at siden ser oversiktlig ut. En rotete side med masse forstyrrende elementer, som blinkende grafikk, sterke farger og rullende tekst vil gjøre at brukeropplevelsen blir dårligere og sannsynligheten for at bruker returnerer til nettstedet minker. Page 8 of 21

2. Arbeidsmetode og planlegging Dette avsnittet beskriver hvordan arbeidet er planlagt fra prosjektets start til prosjektets slutt. 2.1 Idéfase Vi kontaktet Smartlink AS med bakgrunn i at de hadde sendt inn prosjektforslag til Høgskolen i Oslo. Vi avtalte i demember 06 møte med bedriften for å få mer informasjon om prosjektet. Vi syntes prosjektet hørtes både interessant og utfordrende og valgte derfor å takke ja. Det at prosjektet skulle utvikles i.net gjorde det enda mer interessant ettersom.net er populært og mye etterspurt per dags dato. 2.1 Forprosjekt Denne fasen av prosjektet startet i november 2006 og varte til februar 2007. Poenget med denne fasen var å presisere problemområdet så konkret som mulig, samt å finne ut om problemet kunne løses innenfor de gitte rammene vi hadde. Arbeidet resulterte i en forprosjektrapport med innleveringsfrist 2. februar 2007. 2.2 Kartlegging Kartlegging av community-sider var del 1 av prosjektoppgaven. Vi brukte forholdsvis mye tid på å finne de mest populære community-sidene, samt å kartlegge hva de forskjellige communitiene tilbyr av tjenester. I tillegg forsøkte vi å finne en sammenheng mellom populariteten av sidene og tjenestene de tilbyr. Det var veldig utfordrende å finne ut hva som gjorde de forskjellige sidene spesielt populære, siden flere tilbyr akkurat samme tjenester men noen av de er noen populære og andre har ingen hørt om. Les mer om dette i del 1 av produktdokumentasjonen. Page 9 of 21

2.3 Planlegging I planleggingsfasen arbeidet vi tett sammen for å utforme prosjektskissene. Hvert gruppemedlem fikk tildelt enkelte community-sider vi skulle se nøyere på. Prosjektet ble delt inn i fem deler, portalens asp-del, portalens c#(sharp)-del, databasen, design og dokumentasjon, hvor hver og en fikk hovedansvar for minimum en del. Disse ble fordelt utifra interesse og forkunnskaper. Selv om enkeltpersoner fikk hovedansvaret for enkeltdelene betyr ikke dette at den ene har gjort alt på den delen. Under hele prosjektets gang har vi vært avhengig av hverandres arbeid, dette har ført til at vi har samarbeidet hele tiden. 2.4 Verktøy Microsoft Visual Studio 2005, hovedutviklingsverktøy for koding. Ajax Control Toolkit. SQL Database. Adobe Photoshop for utvilkling av grafikk. Db-designer for databasemodellering. Internet Explorer, Opera og Mozilla Firefox (diverse versjoner), for testing av produkt. Microsoft Word for dokumentasjon. Adope PDF for publisering. 2.5 Prosjektdagbok Gjennom hele prosjektet har vi ført en felles prosjektdagbok for gruppen. Prosjektdagboken ligger ute på vår nettside for hovedprosjektet: http://student.iu.hio.no/hovedprosjekter/2007/data/33/ 2.6 Tilbakemelding Vi har gjennom hele prosjektet hatt regelmessige møter med oppdragsgiver. På den måten fikk vi innspill i hvordan oppdragsgiver så for seg alt fra databasen til funksjonaliteten på nettsiden. Vi har jevnlig besøkt oppdragsgiver for å vise det vi har implementert, for så å få tilbakemelding på dette. Når vi har gjort det på denne måten har vi forhindret at vi har lagt ned mye arbeid som senere kunne blitt forkastet. Vi har også hatt dialog med oppdragsgiver på e-post gjennom hele prosjektet i de periodene hvor det ikke har vært møter hos oppdragsgiver. I e-postene har vi kunnet stille spørsmål som vi raskt har fått svar på. Page 10 of 21

3. Utviklingsprosessen Dette avsnittet beskriver hvordan gruppen har samarbeidet innad i gruppen og med arbeidsgiver. 3.1 Samarbeid i gruppen Vi på gruppen kjente hverandre godt før vi begynte med hovedprosjektet. Dette er første gang vi jobber sammen på et prosjekt med unntak av faget webprogrammering i.net som har gått paralellt med hovedprosjektet. Samarbeidet har gått fint, vi har god kjemi innad i gruppen og snakker sammen på en konstruktiv og informativ måte. Når vi ikke har vært samlet har vi hele tiden kommunisert via MSN Messenger og e-post. Alle dokumenter og kodefiler som har blitt oppdatert har fortløpende blitt sendt til samtlige gruppemedlemmer. Vi har hele tiden jobbet tett sammen, og alle på gruppen har vært enige om hvordan prosjektet skulle gjennomføres og hvordan det endelige produktet skulle bli til slutt. Vi har hatt faste møter med vår veileder Ulf Uttersrud hver onsdag klokken 10.30. 3.2 Samarbeid med oppdragsgiver Arbeidet har stort sett foregått i lokalene til Høgskolen (i Vika) og hjemme hos gruppemedlemmene. Oppdragsgiver hadde ikke mulighet for stille med lokaler på daglig basis. De siste ukene av prosjektet har vi vært i Forskningsparken (hvor Smartlink holder til), én dag i uken. Der har vi jobbet med den endelige løsningen og fortløpende fått tilbakemeldinger fra Smartlink. Dette har vært helt nødvendig i sluttfasen av prosjektet fordi det var en del finjusteringer på forskjellige websider i løsningen som ville vært vanskelig og tidkrevende å diskutere på e-post. Vi har fått jobbe ganske selvstendig, og oppdragsgiver ga oss frie hender når det gjaldt utforming av nytt design på nettsiden. Når oppdragsgiver har kommet med nye elementer, f.eks flash-spilleren som spiller av låtene, har vi blitt kontaktet for å teste ut disse. Page 11 of 21

4. Utvikling av produktet Dette avsnittet inneholder kort informasjon om hvordan produktet er uviklet. 4.1 Database Databasemodelleringen er den tredje største enkeltstående oppgaven etter koding og dokumentasjon. Vi har brukt veldig mye tid på å få til en så fornuftig og sikker som mulig database. Databasen er laget slik at det er enkelt å utvide tabellene dersom oppdragsgiver skulle ønske dette etterhvert. Eksempler på dette kan være nye felt de vil ha med i profil-tabellen. For en mer detaljert og utfyllende beskrivelse av databasen henvises det til produktdokumentasjonen. Figur 4.1.1 viser databasemodellen. Figur 4.1.1 Databasemodellen Page 12 of 21

4.2 Kode Koden vi har jobbet utifra var skrevet i J#. Etter nærmere undersøkelse fant vi ut at dette programmeringsspråket forsvinner fra neste år. Med bakgrunn i dette samt å finne gode bøker/dokumentasjon vedrørende J# viste seg å være tilnærmet umulig, bestemte vi i samarbeid med Smartlink å skrive om koden til C#. I valgfaget Webprogrammering i.net lærte vi blant annet om ModelViewController, dvs dele opp applikasjonen i presentasjons-, forretningslogikk- og databaselag (heretter kalt MVC). Vi spurte oppdragsgiver om det var ønskelig at vi lagde MVC for løsningen, men uvisst av hvilken grunn ønsket ikke oppdragsgiver dette. Det hadde vært mer gunstig å bruke MVC fordi applikasjonen ville vært lettere å forvalte og videreutvikle, koden blir også mer oversiktlig. Vi ser nå i ettertid at vi burde ha stått på mer for å få gjennomslag for dette, men siden ingen av oss hadde kjennskap til.net fra før var det vanskelig for oss å innse viktigheten av dette med tanke på videreutvikling. Applikasjonen er idag mer tungvind og uoversiktlig å vedlikeholde enn den ville vært om vi hadde brukt MVC. 4.3 Brukergrensesnitt Oppdragsgiver har hele tiden vært klare på at de ønsker siden så enkel som mulig å bruke. De ønsker ikke å miste brukere på grunn av at de ikke finner ut hvordan ting skal gjøres, eller at de må gjennom lange registreringer for å få tilgang til siden. Dette har ført til at man kan laste opp låten sin, og velge det utsnittet man har lyst på, før man eventuelt registrerer seg. Dette for å vise brukeren hva siden har å tilby, før brukeren trenger å gjennomgå noen som helst form for registrering. Utifra dette ble den beste løsningen å lage to forskjellige registreringer. En kun for å få tilgang til å laste ned låter til mobilen. Denne registreringen består kun av et brukernavn og et passord, samt epostadresse. I den andre registreringen, som gir deg tilgang til community delen av mymp3tone, må du registrere deg med en del personlige data. Ved å separere disse to registreringene vil ikke mymp3tone.com miste brukere som kun er ute etter å laste ned låter til mobilen. Vi fikk tillatelse av Smartlink til å lage et nytt design, men de ønsket likevel at vi skulle beholde noe av det "lekne" utseendet på siden. Nettsiden som allerede ligger ute på nettet (ref. figur 4.3.1) bryter designmessig med alt vi har lært på skolen (for eksempel: ikoner som blinker, rulletekst og mange sterke farger). Vi synes at fargevalget skal være noe mer nedtonet, og har brukt blant annet facebook.com som inspirasjon, siden alle på gruppen mener denne siden er meget behagelig og oversiktlig. Se vårt designforslag; figur 4.3.2. Page 13 of 21

Figur 4.3.1 Opprinnelig design Figur 4.3.2 Nytt design Page 14 of 21

4.4 Optimalisering Mymp3tone.com vil gjøre mange databasekall så det er viktig å gjøre disse så effektive som mulig. En enkel måte å gjøre dette på er å kun hente ut de kolonnene som du trenger fra databasetabellene, dvs bytte ut asterikstegnet * med navnene på de kolonnene du har bruk for. Hvis du kun skal ha ut id'en til en låt fra tabellen users_tune vil spørringen i eksempel 1 være raskere enn spørringen i eksempel 2. Eksempel 1: SELECT user_id FROM users_tune WHERE tune_id = @requested_tune_id; Eksempel 2: SELECT * FROM users_tune WHERE tune_id = @requested_tune_id; 4.5 Kompabilitet Figur 4.4.1 Users_tune Smartlink ønsket at den ferdige løsningen skulle se tilnærmet lik ut i de tre browserne Microsoft Internet Explorer, Opera og Mozilla Firefox. Dette i seg selv er en ganske utfordrende jobb, da de browserne tolker html- og css-kode ulikt. Figur 4.5.2 Tune Details I Opera/ Firefox Figur 4.5.1 Tune Details i MSIE Page 15 of 21

Figurene over (fig 4.5.1 og 4.5.2) viser utlisting av detaljer til en låt hendholdsvis i Internet Explorer og Opera/ Firefox. Grunnen til at disse er så forskjellige er måten browserne tolker css filen på. Tabellen som denne listingen er lagt inn i bruker klassen table_padding (fig 4.5.3) for å få luft melllom tabellen og elementene rundt. Pga av at klassene som blir brukt til selve utlistingen i utgangspunktet ikke inneholdt noen paddingelementer(fig 4.5.3), beholder Internet Explorer paddingen fra <table> elementet lenger opp, mens Firefox og Opera nullstiller padding en. For å løse dette problemet har vi satt padding elementer i alle klassene som er med i utlistingen av låtene. Da ble tabellene identiske i de 3 browserene. Figur 4.5.3 css.tabeller 4.6 Sikkerhet Vi har hele tiden underveis i prosessen tenkt på sikkerheten i applikasjonen. Herunder brukers tilgang til undersider og låter. For mer utfyllende informasjon og dokumentasjon om sikkerheten i systemet, henvises det til produktdokumentasjonen, punkt... og kildekoden på CD. Page 16 of 21

4.7 Videreutvikling Vi har lagt til rette for at Smartlink kan videreutvikle nettstedet med f.eks opplasting av bilde til profil og en funksjon hvor brukere kan opprette grupper og invitere sine venner til disse gruppene. Det er også lagt til rette for at låtene kan deles kun innad i gruppen. Databasetabellene ligger i aspnetdb.mdf og siden som oppretter gruppene er også utviklet. Pga dårlig tid har vi ikke implementert denne i løsningen men denne funksjonen var heller ikke en del av kravspesifikasjonen. Vi har også laget metodene som gjør at bruker kan laste profilbilde inn i databasen. Koden for å hente ut og vise bilder er ikke utviklet. Om ønskelig vil det også være enkelt å legge inn en redigeringsfunksjon til låtkommentarene. Dette har ikke hatt prioritet hos oss siden det ikke har vært en del av kravspesifikasjonen men vi har sett at en del av community-sidene har denne funksjonen. Alle metodene som er brukt i flere undersider er lagt i en egen klasse slik at vedlikehold av disse kun vil foregå på ett sted. Da slipper man å gjøre endringer i flere enn én metode dersom nettstedet skal forandres. Navnet på denne klassen hvor disse metodene er lagret er common_methods.cs. Alle metodene som gir output til bruker og som er felles for flere enn én underside er samlet i klassen common_messages.cs. Dette gjør det veldig enkelt å oppdatere informasjon til bruker uten å måtte gå gjennom og endre på hele kildekoden. Kildekoden under viser metoden _no_profile() som blir kalt dersom bruker uten brukerprofil forsøker å se en side han/hun ikke har tilgang til. Slik dette er bygget opp vil det være veldig enkelt å forandre utskriften som sluttbruker vil se. public static string _no_profile() { string _message = "<div class=\"normal_heading\">error!</div>"; _message += "<div class=\"normal_font\"> You need a userprofile to view this page</div>"; _message += "<div class=\"normal_font\"><a href=\"create_profile.aspx\">create Profile</a</div>"; return _message; } // end method Alle exceptions-meldinger er lagret som egne html-filer i katalogen error_pages. Dette gjør det veldig enkelt å editere både innhold og layout ved en senere anledning. 4.8 Ferdige løsninger Bortsett fra de innebygde ferdige løsningene som ligger ferdige i.netrammeverket har vi kun benyttet oss av ratingfunksjonen fra AJAX Control Toolkit. Dette ble gjort etter ønske fra oppdragsgiver. Page 17 of 21

5. Utfordringer og løsninger Dette avsnittet beskriver hvilke utfordringer vi møtte underveis i prosessen. 5.1 Utfordringer og løsninger Den aller største utfordringen i forhold til prosjektet har vært at ingen av oss kunne noe som helst.net før vi begynte. Microsoft Visual Studio er et omfattende program som det tar lang tid til å sette seg inn i og vi har heller ikke funnet noen gode bøker som dekker emnet.net, med unntak av bøker som baserer seg på å slavisk bruke de innebygde pek-og slipp-elementene som ligger i rammeverket. Disse dekker ikke selve C#-koden, og selv om C#-språket har visse likheter med både Java og C/C++ er forskjellen likevel såpass store at det er vanskelig å konvertere kodingen mellom språkene uten noen form for dokumentasjon. Etterhvert som semesteret gikk og vi fikk mer erfaring med Visual Studio løste også startvanskene seg. Andre utfordringer har vært å tilpasse registreringen etter oppdragsgivers ønske. Her har vi måttet endre en del på webconfig-filen slik at sikkerhetsspørsmålet som er obligatorisk som standard i.net-rammeverket ikke ble med når bruker registrerte seg. Det samme gjaldt også for kravet til lengde og innhold i passord. Etter mange timer med "googling" og prøving av forskjellige løsninger fant vi endelig en som dekket våre behov. Vi ser nå i ettertid at dette faktisk er et ganske enkelt problem å løse men ettersom det ikke finnes litteratur i det tar det tid før man finner en god løsning på problemet. Figur 5.1.1 viser løsningen på hva som måtte inn i webconfig-filen for å slippe "secret question" samt å endre kravet om hvor mange tegn det må være i passordet i registreringen. Figur 5.1.1 Kode for å unngå "secret question" Page 18 of 21

6. Avslutning Gjennom dette prosjektet har vi lært mye om programmering i.net, SQLdatabaser og utforming av brukergrensesnitt. Vi er fornøyde med resultatet og arbeidsinnsatsen vår. Prosjektet har også vært lærerikt i forhold til samarbeid, og vi har fått erfare våre egne begrensninger så vel som muligheter. Når man lager en stor applikasjon er det lett å henge seg opp i detaljer, og det kommer gjerne noen krevende utfordringer som tar lengre tid å løse, dermed kan man lett komme i tidsklemmer. Vi har nå erfart at en god kravspesifikasjon helt klart er avgjørende når man starter denne typen prosjekter. Page 19 of 21

7. Figurliste Figur 1.3.1 Dagens design... 6 Figur 1.3.2 Velg utsnitt... 6 Figur 4.1.1 Databasemodellen... 12 Figur 4.3.1 Opprinnelig design... 14 Figur 4.3.2 Nytt design... 14 Figur 4.4.1 Users_tune... 15 Figur 4.5.2 Tune Details I Opera/ Firefox... 15 Figur 4.5.1 Tune Details i MSIE... 15 Figur 4.5.3 css.tabeller... 16 Figur 5.1.1 Kode for å unngå "secret question"... 18 Page 20 of 21

8. Kilder 8.1 Internett www.alexa.com www.youtube.com www.facebook.com www.nettby.no www.vox.com www.hi5.com www.bebo.com www.bolt.com www.myspace.com www.friendster.com www.mybloglog.com www.eblogger.com www.asp.net www.4guysfromrolla.com 8.2 Bøker -ASP.NET 2.0 everydayappz for dummies 2006 Doug Lowe -Programming ASP.NET 3rd edition Jesse Liberty, Dan Hurwitz -UML distilled Martin Fowler, Kendall Scott 8.3 Andre -Menneske-datamaskin-interaksjon og hovedprosjekt i data Ann Mari Torvatn -Eksempelhefte, Kommunikasjon for ingeniører -rettledning og eksempler Ann Mari Torvatn Page 21 of 21