Webbaserad kommunikationsplattform

Transkript

1 Webbaserad kommunikationsplattform Henrik Ekblom & Mikael Wågberg Mars 2008 Examensarbete, 30hp Handledare på CS UmU: Lena Palmquist Examinator: Per Lindström UMEÅ UNIVERSITET INSTUTITIONEN FÖR DATAVETENSKAP UMEÅ

2 Webbaserad kommunikationsplattform 2 Sammanfattning En webbaserad kommunikationsplattform har utvecklats. Plattformens huvuduppgift är att hantera kommunikationen mellan studenter och lärare. Utvecklingsarbetet har fokuserats på att ta fram ett system som ska kunna expanderas, som erbjuder förbättrad säkerhet, användbarhet och effektivitet. En användarstudie med en webbaserad enkät och diskussioner med användare av det gamla systemet användes för att fastställa vad som var problemen med det gamla systemet. Implementationen av databasen och säkerheten för systemet lades som en grund för att nå de uppsatta målen. En relativt enkelt grafiskt gränssnitt implementerades för testning av funktioner men ett designkoncept föreslogs för fortsatt utveckling av gränssnittet.

3 Webbaserad kommunikationsplattform 3 Abstract A communication platform for the web A web based platform for communication has been developed. The main task for the platform is to handle the communication between students and their teachers. The development has been focusing on building a system that is expandable, offer improved security, usability and efficiency. A user study including an online survey and discussions with users of the old system was used to determine what the problems with the old system were. The implementation of the database and a security approach for the system was laid as a foundation to achieve the goals set up at the start. A relatively simple graphical user interface was also implemented for testing purposes but a design approach was suggested on how to continue the development of the GUI.

4 Webbaserad kommunikationsplattform 4 Tack till Lena Palmquist, Lars Norlin, Anders Marklund, Jon Persson, Jan Erik Moström, Marie Folkesson Karling och Apberget.se för all hjälp under arbetets gång. Ett speciellt tack till Marcus Spike Norlund!

5 Webbaserad kommunikationsplattform 5 Innehållsförteckning 1. Inledning Bakgrund Problembeskrivning Mål Förundersökning Enkätundersökning Tillvägagångssätt Målgrupp Resultat Felkällor Kreativa möten Referenssystem Gamla systemet Övergripande beskrivning Tekniken Databas Användargränssnitt Gränssnitt Inloggningen Huvudsida Kurssidor Meddelanden... 25

6 Webbaserad kommunikationsplattform Redigering av kurser Frånvaro Portfolio Administration Det nya systemet Introduktion Målgrupper Gränssnitt Skisser Prototyp Teknik Windows Small Business Server 2003/IIS ASP.Net Ajax Databas Säkerhet Forms Authentication Roller SSL Kontroll av indata Diskussion Referenser Bilagor... 55

7 Webbaserad kommunikationsplattform 7 Bilaga Enkät Bilaga Enkätresultat Bilaga Prioritetslista funktioner Prioritering 1 Basfunktioner Prioritering 2 Underlätta större arbeten Prioritering 3 Underlätta mindre arbeten Prioritering 4 Visioner Bilaga Serverspecifikation... 66

8 Webbaserad kommunikationsplattform 8 Figurförteckning Figur 1 Första frågan på enkätundersökningen Figur 2 Första steget av inloggningen Figur 3 Andra steget av inloggningen Figur 4 Första sidan efter inloggning för lärare Figur 5 Huvudsidan inne i "Klassrummet" Figur 6 Information om specifik kurs för lärare Figur 7 Meddelanden Inkorg Figur 8 Meddelande Läs meddelande / Svara Figur 9 Sida för redigering av kurser Figur 10 Vy över frånvarosammanställning för elever Figur 11 Eleverna laddar upp sina svar på inlämningsuppgifter Figur 12 Tidigt skiss av generell design Figur 13 Skiss ett moment senare Figur 14 Skiss från nästa moment, grund gjord i Flash med anteckningar om vidare förändringar Figur 15 Generellt prototypförslag för elevanvändare Figur 16 Administratorvy med listning av personer med allergier Figur 17 Låst arbetsyta Figur 18 ER schema över hela databasen Figur 19 Detaljbeskrivning av databasen... 43

9 Webbaserad kommunikationsplattform 9

10 Webbaserad kommunikationsplattform Inledning Detta projekt bestod i att skapa en ny plattform för ThorenGruppen och Thoren Business School för den interna kommunikationen, främst mellan lärare och elever. ThorenGruppen har ett system vid namn Progress (se avsnittet Gamla systemet ) som från början var tänkt som kommunikationsplattform, men systemet har visat sig passa dåligt för den gymnasieverksamhet som ThorenGruppen har utökat till idag. Det gamla systemet har vart svåranvänt, haft dålig prestanda samt att administrationen har varit besvärlig och tidskrävande. Progress skapades 2001 och blev en plattform för all kommunikation mellan elever och lärare på de distansutbildningar som bedrevs i företaget. Huvudsyftet för systemet var att ge lärarna möjligheten att skicka ut uppgifter till eleverna som eleverna i sin tur kunde genomföra och därefter skicka tillbaka till läraren. Funktioner för att hålla reda på elevers närvaro och studieresultat har också varit en viktig del i systemet. 1.1 Bakgrund ThorenGruppen AB är ett av Sveriges snabbast växande utbildningsföretag och tillhandahåller olika slags utbildningar som gymnasieutbildningar, komvuxutbildningar, företagsutbildningar, m.m. Utbildningarna genomförs till stor del på distans, men även lokalt. ThorenGruppen driver dessutom en gymnasieskola kallad Thoren Business School (TBS) som i dagsläget finns i fyra städer i Sverige.

11 Webbaserad kommunikationsplattform 11

12 Webbaserad kommunikationsplattform Problembeskrivning ThorenGruppen har bestämt sig för att göra en uppdatering av Progress för att få ett system som känns mer modernt och samtidigt är mer anpassat efter dess nuvarande användningsområde. När Progress skapades var det i första hand tänkt för att användas för distansutbildningar, men eftersom det nu används av både gymnasieelever och företagskunder har det visat sig att systemet inte riktigt är anpassat för detta. Det nuvarande systemet startade som ett litet system och därefter har nya funktioner plåstrats på utan att ha en grundstruktur som klarar av expansion. Progress börjar enligt ThorenGruppen nå sin gräns i hur många fler användare som kan läggas till samt hur många nya funktioner som kan implementeras. Det finns vissa problem som kan uppstå med användandet av en digital version för kommunikation mellan lärare och elever i jämförelse med att ha direktkommunikationen, människa till människa (Barab, Kling, & Gray, 2003). I den digitala versionen läggs begränsningar in i vad elever kan skriva vilket är positivt ur vissa perspektiv, t.ex. då administratören för systemet kan ta bort diskussioner och inlägg som på något sätt är opassande för skolans regler. Nackdelen kan vara att vissa diskussioner kan behöva göras direkt mellan två personer, t.ex. då en kurator pratar med en elev om något problem. Progress och det nya systemet är dock inte den enda kommunikationen mellan lärare och elev, den direkta kommunikationen finns kvar i skolan under vanliga lektioner och raster etc. Plattformen är istället ett komplement till den konventionella undervisningen och finns för att förenkla det administrativa arbetet.

13 Webbaserad kommunikationsplattform Mål Specifikationerna för arbetet har skapats under förstudien till projektet, men innan arbetet påbörjades fanns det grundläggande mål som skulle uppnås. Att skapa en användarvänlig kommunikationsplattform o Lättnavigerad med en intuitiv design o Effektivisera arbetet i systemet o Effektivisera administrationen av systemet o Bättre feedback till användarna o Roligare användning Förbättra säkerheten o Kryptering av kommunikation o Kryptering av data (lösenord m.m.) o Bättre kontroll av skadlig indata i formulär Målet med arbetet är att skapa en grund till ett nytt system som i sin tur skall leda fram till en fullt fungerande plattform vilken hösten 2008 ska ersätta det gamla systemet.

14 Webbaserad kommunikationsplattform 14

15 Webbaserad kommunikationsplattform Förundersökning För att få en grund till systemet behövdes en prioriteringslista på de funktioner som var viktigast att implementera initialt. För att skapa denna prioritering genomfördes möten med ledningen på ThorenGruppen där deras önskemål fördes fram samt en enkätundersökning som användarna av det gamla systemet fick genomföra. Enkätundersökningen (se 3.1 Enkätundersökning ) som genomfördes hade till syfte att få fram önskemål hos det nya systemet samt åsikter om det gamla systemet. Resultatet från enkätundersökningen framfördes vid mötena med ledningen för att få fram en prioritering som kunde stå för både ledningen och användarna. 3.1 Enkätundersökning Syftet med förundersökningen var att få en uppfattning om hur det gamla systemet fungerade och vad användarna tyckte om det, samt att få fram användarnas önskemål av funktioner till det nya systemet Tillvägagångssätt Enkäten genomfördes som en webbenkät (se Figur 1). Frågorna och svaren fanns upplagda på en hemsida där respondenten kunde fylla i textrutor (där fritext användes som svarsalternativ) samt fylla i ett av flera färdiggjorda svarsalternativ (t.ex. där användaren ombads gradera från 1 6 ett förslag till en ny funktion) i en s.k. radioknapplista 1. Tillvägagångssättet med internet som medium valdes för att insamlingen av data skulle snabbas upp samt förenklas (Dahlström, 2005). Detta var nödvändigt då detta projekt hade ett relativt litet tidsspann. De data som samlades in 1 En lista med knappar (se Figur 1) där användaren av en webbsida kan trycka in en av flera knappar för att välja ett alternativ (Microsoft ASP.NET Team, 2007)

16 Webbaserad kommunikationsplattform 16 lagrades i en databas och ett gränssnitt togs fram för att lista alla svaren samt sortera dessa utifrån olika kriterier. Respondenterna fick veta varför de var utvalda att svara på detta undersökningsformulär då det är viktigt att förklara detta (Dahlström, 2005). Målgruppen var dagens användare av Progress där det stora flertalet kommet att använda det nya systemet, således var det aktuellt att fråga denna grupp. Dahlström menar vidare att enkäter uppdelade på flera sidor bör ha en indikator på var i enkäten man befinner sig. Respondenten kan annars avbryta enkäten i förtid. En annan fördel med att ha frågorna uppdelade på flera sidor är att de redan ifyllda svaren sparas undan i databasen om något fel skulle uppstå. Enkäten som genomfördes var uppdelad på flera sidor baserat på ovanstående fördelar men även för att hålla ned storleken på enkätsidan. Figur 1 Första frågan på enkätundersökningen Målgrupp Enkätens målgrupp var de användare som använde det gamla Progress, dessa användare kategoriserades i fyra olika grupper: lärare, gymnasieelever, distanselever och övriga. Dessa kategorier skiljdes åt genom att skicka ut olika länkar till enkäten där länken innehöll information om vilken kategori den svarande tillhörde.

17 Webbaserad kommunikationsplattform Resultat Resultatet av enkäten sammanställdes i en PowerPoint presentation (se Bilaga 2 ) som användes som underlag vid den intervju/diskussion (se 3.2 Kreativa möten ) vi hade med ThorenGruppens ledning. Svaren sammanfattade den generella syn användarna hade på det nuvarande systemet samt deras åsikter om framtida funktioner till det kommande systemet. Några av resultaten var: Användarna använde Progress frekvent, största delen flera gånger per dag. Chattfunktion i det kommande systemet var önskvärt. Bloggfunktion hade jämt utspridda svar på skalan 1 6 för önskvärdhet. Kalenderfunktion i det kommande systemet var mycket önskvärt. Gästbok i det kommande systemet var önskvärt. Vidare sade enkäten att användarna upplevde Progress för komplicerat att använda samt erbjöd dålig användbarhet ur grafisk synpunkt samt funktionalitetsmässigt. Resultatet av enkäten sammanställdes på en generell nivå utan att gå in på detaljer om vad de olika grupperna hade svarat. Enkäten skulle ge ett underlag för ett kreativt möte (se 3.2 Kreativa möten nedan) med ThorenGruppens ledning samt lärare. Detta underlag skulle generera den slutgiltiga prioritetslistan för det kommande systemet Felkällor Trots försök att eliminera felkällor av olika slag under enkätundersökningen finns det alltid risk för felaktigheter i svaren. Några av dessa är: Lärare kan ha fyllt i enkät som var menad för elever. Lärarna fick ett separat utskick med en internetlänk till deras enkät men såg även elevernas internetlänk (på den allmänna nyhetsplatsen i det gamla systemet Progress). Utskicket skedde via Progress vilket gjorde att de som inte använde Progress under den period enkäten var ute kan ha missat att fylla i den.

18 Webbaserad kommunikationsplattform Kreativa möten Efter det att enkätundersökningen genomförts hölls möten med ledningen på ThorenGruppen samt med ett par lärare på Thoren Business School. Dessa intervjuer genomfördes för att få fram ledningens specifika önskemål samt för att få en mer detaljerad översikt över de problem som det gamla systemet hade. Genom att föra fram enkätsvaren under dessa kreativa möten kunde ledningen få inblick i hur användarna upplevt det gamla systemet, samt vilka förslag till förbättringar som fanns. Dessa möten ledde i sin tur fram till en idé över hur det nya systemet skulle se ut och en prioritering över funktioner kunde tas fram (se bilaga 4). Ett av ledningens krav var att systemet måste vara framtidssäkert och ha utrymme för expansion när nya skolor startas och många nya användare skall läggas till. Det gamla systemet saknade även ett effektivt användargränssnitt för att ändra/skapa stora mängder data (exempelvis lägga till frånvaro för flera elever samtidigt), vilket också var ett krav på det nya systemet. Utöver detta fanns kravet på förbättrad säkerhet. Lärarnas önskemål skiljde sig en del från ledningens då det mer inriktades mot användbarhet, där användbarhetsförbättringar var prioriterat. 3.3 Referenssystem Det gamla systemet (Se avsnitt 4) kunde användas som referens då dess grundfunktioner var likartade som funktionerna i det nya. Önskemålen ovan vägdes mot den tid som fanns utsatt för projektet och en prioriteringslista kunde skapas vilken var grunden för den fortsatta utvecklingen av Progress. Att undersöka konkurrerande system var även det en bra informationskanal då de var liknande system som redan var i drift och således kunde ses som fungerande referenser. Eftersom tanken med att digitalisera lärandet inte är unik för ThorenGruppen finns det även andra företag som utvecklat motsvarande plattformar för detta. Genom att titta på liknande system och undersöka vilka lösningar de har valt att använda sig av har många idéer uppkommit till utvecklingen av detta system.

19 Webbaserad kommunikationsplattform 19

20 Webbaserad kommunikationsplattform Gamla systemet 4.1 Övergripande beskrivning ThorenGruppens nuvarande system är en kommunikationsplattform som heter Progress. Dess uppgift är att hantera kommunikationen mellan elever och lärare. Via Progress får lärarna möjlighet att lägga ut kursmaterial och annan information rörande utbildningen. Eleverna kan då ta del av den informationen och därefter utföra eventuella uppgifter. Samma system hanterar också inlämningar av uppgifter, dvs. eleverna får tillgång till sina uppgifter via Progress, utför dessa och lämnar därefter in dem via plattformen. Lärarna kan då ladda ner elevernas inlämnade uppgifter och genomföra rättningen. Systemet har utöver detta funktioner för att: Lärarna ska ha möjlighet att skicka ut inlämningsuppgifter till eleverna Användarna ska kunna skicka meddelanden till andra användare. Lärarna ska kunna registrera närvaro för kursdeltagare. Användarna ska kunna se överblicksbilder över kursers aktiviteter. Målsmännen till eleverna ska ha möjlighet att logga in och se elevens närvaro. Lärarna ska kunna lägga upp diagnostiska tester som kursdeltagarna genomför direkt på plattformen. Användarna ska kunna diskutera kurserna via ett forum. 4.2 Tekniken Det gamla systemet utvecklades under 2001 och är baserat på ASP med en Accessdatabas som grund. Systemet är anpassat efter Internet Explorer och saknar i viss mån stöd för andra webbläsare. Många av bristerna som systemet har beror just på de tekniska aspekterna eftersom det använder sig av gammal teknik.

21 Webbaserad kommunikationsplattform Databas Den Microsoft Accessdatabas som används fungerade tillfredsställande för denna mindre applikation då det inte var många samtidiga SQL anrop. Access är en databashanterare som är utvecklad för att hantera mindre applikationer med ett begränsat antal anrop. När användarskaran växte då Thoren Business School startade nya skolor runt om i Sverige fick databasen problem med att hantera alla samtidiga anrop på en acceptabel tid. Ett exempel på ett problem som kunde uppstå var att en elev laddade upp en stor fil till systemet från en dator som är uppkopplad via modem, vilket medförde att databasen låstes upp för skrivning så länge filen laddades upp. Detta var inte ett stort problem men har med tidens gång och en ökande användargrupp lett till att fler upplever systemet som långsamt. Att få responstider av ett datasystem som ligger på flera sekunder får enligt Schneiderman användare att uppleva systemet som långsamt (Shneiderman, 1984, s. 267) Användargränssnitt Programmeringsspråket som användes för att vara gränssnittet mellan användaren och databasen var ASP Active Server Pages (Microsoft, 2007). Språket är ett serversidespråk där koden kompileras i realtid till hemsidor som webbläsare kan läsa. Nackdelar med denna teknik är: Koden kompileras i realtid vilket kan leda till längre responstider. ASP använder VBscript vilket medför att man ej få samma funktionalitet som t.ex. det fullständiga Visual Basic ger. ASP saknar ett välutvecklat stöd för HTML kontroller vilket medför att programmeraren måste implementera mycket manuellt som det i t.ex. ASP.NET finns färdiga klasser för: valideringskontroller, inloggningssystem (se Forms Authentication ). 4.3 Gränssnitt Det nuvarande systemet har ett utseende som många användare upplever som plottrigt och för färgglatt (se bilaga 1 för enkätsvaren). Mappningen och färgsättningen av länkar och knappar är ej genomtänkt, det finns ingen tydlig koppling mellan systemets funktioner och gränssnittets utseende vilket Norman (2002) anser vara nödvändigt. Detta i sin tur leder till att systemet är svårnavigerat och användaren känner ej tillit till systemet.

22 Webbaserad kommunikationsplattform Inloggningen Det finns fem olika typer av användare: Kursdeltagare, Kunder, Utbildare, Målsmän och Administratör. Alla typer förutom administratören kan logga in i systemet på samma sida (se Figur 2) genom att först välja vilken användarkategori man tillhör och därefter logga in med användarnamn och lösenord (se Figur 3). Administratören måste dock logga in via en separat sida som ser likadan ut som den i Figur 3. Figur 2 Första steget av inloggningen Figur 3 Andra steget av inloggningen

23 Webbaserad kommunikationsplattform Huvudsida Huvudsidan ser olika ut beroende på vem som loggar in, är det en lärare som loggar in syns en sammanställning över vilka kurser läraren har (se Figur 4). Eleverna kommer direkt in i det som kallas Klassrummet (se Figur 5), på förstasidan får eleven se den övergripande information som är inlagd. Det kan vara information som rör hela skolan eller en hel klass. Läraren kommer in i Klassrummet vid ett senare skede (se Figur 6 Information om specifik kurs för lärare ). Figur 4 Första sidan efter inloggning för lärare

24 Webbaserad kommunikationsplattform 24 Lista över användarens tillgängliga kurser Meny Lista över elever Figur 5 Huvudsidan inne i "Klassrummet" Kurssidor Varje kurs som finns inlagd i systemet har en egen plats där elever kommer åt de dokument som läraren på kursen har laddat upp (se Figur 6), denna vy är i det gamla progress och ej inne i Klassrummet. Här kan även den inloggade läraren se vilka elever som är inskrivna på kursen samt vilka lärare som har tillgång till den.

25 Webbaserad kommunikationsplattform 25 För att lärare ska komma till Klassrummet måste dom klicka här för den kurs dom vill se i Klassrummet Figur 6 Information om specifik kurs för lärare Meddelanden I systemet kan lärare och elever skicka meddelanden till varandra. Användarna har en traditionell in /utkorg (se fig.5). För att skicka ett meddelande måste eleven först klicka på Nytt Mail och därefter vem han/hon vill skicka meddelandet till genom att klicka på personens namn i användarlistan i mitten av sidan (Figur 7 & Figur 8). Användarlista Inkorgen Figur 7 Meddelanden Inkorg

26 Webbaserad kommunikationsplattform 26 Figur 8 Meddelande Läs meddelande / Svara Redigering av kurser Lärarna har möjligheten att gå in och redigera vilka kurser som eleverna deltar i, detta går endast att göra elev för elev och inte för flera elever samtidigt. Det betyder att om man vill redigera ett datum för en kursstart måste detta göras för varje elev separat (se Figur 9) vilket kan bli väldigt tidskrävande. Denna funktion skapades på den tid på Progress användes främst för distanselever där eleverna kunde ha olika kursstarter fast de läste samma kurs. Vid gymnasiestudier läser eleverna en kurs under samma tidpunkt vilket betyder att datumet för kursstarten är samma för alla elever i samma kurs.

27 Webbaserad kommunikationsplattform 27 Figur 9 Sida för redigering av kurser Frånvaro Lärarna lägger till frånvaron för varje elev separat. Elever, målsmän och lärare har möjlighet att se en sammanställning av elevens frånvaro där endast läraren har möjlighet att redigera frånvaron (se Figur 9) Figur 10 Vy över frånvarosammanställning för elever

28 Webbaserad kommunikationsplattform Portfolio Lärarna skapar inlämningsuppgifter som eleverna ska skicka in svar på inne i systemet. Detta gör eleverna genom att ladda upp dokumenten till en Portfolio som eleven har till varje kurs. Det finns ingen möjlighet för eleven eller läraren att se en sammanställning över alla filer som laddats upp. Figur 11 Eleverna laddar upp sina svar på inlämningsuppgifter 4.4 Administration Administrationen av det gamla systemet har visat sig vara mycket tidskrävande och kostsam för företaget. Den administration som genomförs handlar mest om att nya kurser och utbildningar skall läggas in i systemet och därefter skall rätt elever läggas in i rätt utbildning/klass o.s.v. Gränssnittet för det gamla systemet saknar många delar som hade underlättat det administrativa arbetet avsevärt, som t.ex. att administrera flera elever samtidigt, o.s.v. Administrationen har även många gånger gjorts på ett sådant sätt att det varit lätt att göra fel vilket i sin tur har lett till logiska fel i databasen.

29 Webbaserad kommunikationsplattform 29

30 Webbaserad kommunikationsplattform Det nya systemet 5.1 Introduktion Efter att ha fått en bild av vilka funktioner ThorenGruppen vill att deras system skall ha kommer det nya systemet att få en communityliknande grund med användaren i centrum. Det centrala är kommunikationsdelen mellan lärare och elev med utskick av uppgifter från lärare och svar på dessa uppgifter av elever. Med användaren i centrum kan systemet erbjuda en överskådlig bild av användarens kommande aktiviteter samt dennes meddelandeinkorg och övriga delar som är knutna till användaren. En community plattform kan erbjuda denna centralisering av användaren och en utformning så att det viktiga hamnar i fokus. Den största fördelen med det föregående systemet är dess åtkomlighet genom att den är webbaserad. Denna del bibehålls i det nya systemet med förnyelse av tekniken för att få en effektivare och snabbare plattform. Det grafiska gränssnittet kommer även det att byggas om för att göra användandet mer intuitivt, effektivisera arbetet tidsmässigt, passa bättre in i ThorenGruppens grafiska profil samt för att ge systemet ett modernare och pålitligare utseende. 5.2 Målgrupper Användarna av systemet är inte en homogen grupp då de består av en mångfald av olika användartyper vilka kan ha olika stor erfarenhet av systemet samt syfte med användandet. Här är en lista över kategorier av användare, en estimering av deras erfarenhet av det gamla systemet samt deras primära uppgifter i systemet:

31 Webbaserad kommunikationsplattform 31 Elever o Gymnasieelever Vana av gamla systemet: Förväntad relativt god då elever av systemet får bärbar dator från skolan samt förväntas sköta skolarbetet genom systemet Huvudmål: Ta emot samt svara på skoluppgifter och meddelanden från lärare o Personal o o o o Målsmän o o Vuxenutbildning/Komvux Vana av gamla systemet: Kan variera då personer i den eftergymnasiala utbildningen kan gå enstaka eller flera kurser Huvudmål: Ta emot samt svara på skoluppgifter och meddelanden från lärare Ordinarie lärare Vana av gamla systemet: Förväntad relativt god då utskick huvuddelen av det administrativa arbetet sker i systemet Huvudmål: Sköta det administrativa med uppgifter, närvaro samt kontakt med elever Vikarier lärare Vana av gamla systemet: Kan variera då vikariat kan vara kortvarigt Huvudmål: Sköta det administrativa med uppgifter, närvaro samt kontakt med elever Administratörer Vana av gamla systemet: Förväntad god då de skall administrera systemet Huvudmål: Administrera systemet, hantera stora mängder in /utdata, t.ex. inmatning av alla elever på en skola/klass/o.s.v. Övrig personal Vana av gamla systemet: Kan variera Huvudmål: Få information om aktuell arbetsplats Vana av gamla systemet: Kan variera Huvudmål: Få information om deras barns skolgång

32 Webbaserad kommunikationsplattform Gränssnitt Gränssnittet är den yta som ligger mellan användare och det bakomliggande systemet, i detta fall en grafisk representation av de data som finns samt verktyg för att modifiera dessa data. Gränssnittets uppgift är att göra tekniken transparent för användaren och därigenom förbättra användbarheten (Wilding, 1998). Vidare skall gränssnittet förenkla huvudmålen för användaren men har även fler uppgifter, som att förmedla en viss känsla och att få användaren att känna sig trygg med systemet genom att använda sig av konceptuella modeller som användaren förstår (Norman, 2002, s. 189). Baumann och Thomas skriver om olika skalor som användarens upplevelser hamnar i (Baumann & Thomas, 2002). Skalorna som bör tas i beaktande är: Uppfyller förväntningar Besvikelse Intressant Tråkigt Alternativt Normal Följer trend Sätter trend Att ge användaren bättre feedback var ett av målen i projektet, dvs. användaren ska få information från systemet när input givits. För att åstadkomma detta finns många olika tekniker tillgängliga. Det nya systemet kommer att ge feedback till användaren på olika sätt bl.a.: Laddningsindikatorer o När systemet processar data. Dialogrutor o För att göra användaren uppmärksam på viktiga moment. T.ex. att man har en dialogruta som frågar administratörsanvändaren en extra gång innan administratörer tar bort ett betyg för en elev. Bekräftelser på moment o För att visa användaren att systemet mottagit input. T.ex. att man skriver ut Meddelandet skickat! när användaren skickat iväg ett meddelande Skisser Till en början användes brainstorming som metod för att få ut skisser till den design som skulle representera ovanstående idéer och mål. Layouter togs fram med penna och papper (se Figur 12) och ett första utkast lades in Macromedia Flash för att få en helhetsbild (se

33 Webbaserad kommunikationsplattform 33 Figur 13). Flash erbjuder ett snabbt sätt att få ut ett utkast på design samt enklare funktioner. Figur 12 Tidigt skiss av generell design

34 Webbaserad kommunikationsplattform 34 Figur 13 Skiss ett moment senare Nästa steg var att skapa de grafiska elementen i Adobe Illustrator, vilket är det program som användes för att göra de slutgiltiga bilddetaljerna (se Figur 14).

35 Webbaserad kommunikationsplattform 35 Figur 14 Skiss från nästa moment, grund gjord i Flash med anteckningar om vidare förändringar Prototyp De skisser som togs fram gav en grogrund för att få en grafisk generell prototyp över systemet samt mer specifika mallar som sattes in i olika scenarion. Utifrån målgruppernas förväntade vana av att använda systemet och mål som satts upp bör således designen inte vara statisk utan bör anpassas för avsedd användare. De med liten datorvana bör erbjudas en enkel design där huvudinformationen lätt uppmärksammas. Vidare kan de med mer datorvana erbjudas ett mer komplext gränssnitt för att förenkla in /utmatning av större mängder data. En administratör skall t.ex. kunna lista alla eleverna i en skola som tillhör en viss klass och har busskort, något som målsmän inte behöver. Att göra funktioner och grafik lättförståeliga med god mappning där det inte inkräktar på funktionaliteten är dock att föredra (Norman, 2002, s. 191) Detta används på de gemensamma ytor som alla användare kommer att se. Ett exempel är den del där utloggningen sker. Den bör ha en text som beskriver handlingen logga ut samt ha en gängse använd ikon i typ av ett hänglås som låses upp eller en pil som pekar ut genom en dörr vilket illustrerar att användaren loggar ut ur systemet. Standardisering får användaren att referera till vardagliga händelser (lämnar en plats pil ut genom dörr) samt referera till liknande situationer i andra digitala system (t.ex. logga ut från Hotmail). Detta fungerar när inget annat fungerar men även som en god grund i design (Norman, 2002, s. 200). Vissa generella mål för designen sattes upp för att ha en grund att arbeta från. Systemet skulle utformas på ett sätt användarna upplevde som intressant för att uppmana till användning, generellt följa en standard för att inte avskräcka ovana användare, anses som stabilt för att få användarens tillit samt följa en grafisk trend som använder element från Webb för att upplevas som nytt samt erbjuda en öppen och luftig design. 2 Ett uttryck som myntades av mjukvaruutvecklaren Tim O Reilly under O Reilly Media Web 2.0 conference, Web 2.0 innefattar främst idéer om programmering av hemsidor men även grafiska element.

36 Webbaserad kommunikationsplattform 36 Med detta i åtanke sattes följande designprototyper ihop: Testlogotyp Ikon Användarbild Figur 15 Generellt prototypförslag för elevanvändare. "Inprogress" var systemets arbetsnamn under utvecklingen. Testlogotypens och användarbildens spegling i underlaget samt glansen i ikonen (se Figur 15) är grafiska element från Webb 2.0.

37 Webbaserad kommunikationsplattform 37 Länk för att låsa systemet Figur 16 Administratorvy med listning av personer med allergier En viktig uppgift för administratorn och övrig personal i systemet var att kunna lista många objekt beroende på olika egenskaper. Figur 16 visar ett förenklat scenario då en administratör har listat personer med allergier av olika slag. Sådana listningar skall även vara lätta att skriva ut för att kunna få ett papper med denna information, t.ex. inför en resa med en klass. Listorna i systemet kommer att vara exporterbara till Microsoft Exceldokument, vilket kan förenkla hantering om någon extern källa vill ha denna lista, t.ex. den camping som klassen skall resa till. På samma sätt skall data enkelt kunna läggas in i systemet. Användaren skall kunna mata in data på flera poster samtidigt, t.ex. mata in personerna i en hel klass på en enda sida, föra in frånvaro för en klass på en enda sida etc. Detta har varit ett problem i det förra systemet Progress, då data matades in för en person i taget på separata sidor.

38 Webbaserad kommunikationsplattform 38 Delvis transparent bakgrund till låsningen Figur 17 Låst arbetsyta En funktion som byggts in i systemet öppnas genom den länk som heter Lås (se Figur 16). När systemet är låst (se Figur 17) måste användaren mata in sitt lösenord för att kunna fortsätta arbeta. Denna skärm kommer även upp automatiskt efter 20 minuter. Detta för att obehöriga inte skall komma åt systemet om användaren glömt att logga ut när denne lämnar datorn. Beroende på inställningar i systemet kan bakgrunden till låsningen vara delvis transparent (se Figur 17) men kan även göras heltäckande så att bakomvarande element inte syns. Detta kan vara användbart om användaren arbetar med konfidentiell information något som exempelvis skolkuratorn kan ha behov av.

39 Webbaserad kommunikationsplattform Teknik Det nya systemet bygger på två huvuddelar, ASP.Net 3.5 samt databashanteraren MySql 5.0. Systemet är en webbaserad databasdriven lösning som kommer att vara tillgänglig för alla användare via internet. Det kommer att köras på en helt egen webbserver som ThorenGruppen tillhandahåller och håller i drift Windows Small Business Server 2003/IIS6 Systemets server är av märket Dell och införskaffades efter förundersökningen var gjord. Nedan följer en kortfattad specifikation av servern (se bilaga 2 & 3 för fullständig specifikation): Intel 2.4GHz quad core o Processorbelastningen är inte så stor på en webbapplikation som är effektivt kodad och skall handha max 5000 användare. 4Gb ramminne o Ramminnet används för att cacha data från databasen, vilket kan snabba upp datahämtning avsevärt. Två RAID 1 speglade hårddiskar, 500Gb st. o Användarna kommer generellt inte att ha behov av lagring av filer större än några megabyte per styck. Extra utrymme har reserverats för framtida hopslagning med företagets intranät då större filer kan komma att lagras, bl.a. filmer. Raid 1 speglar informationen likadant på de båda hårddiskarna vilket medför snabbare läsning samt extra säkerhet. Om en av hårddiskarna skulle gå sönder finns informationen även lagrad på den andra.

40 Webbaserad kommunikationsplattform ASP.Net 3.5 ASP.Net 3.5 är utvecklad av Microsoft och är en vidareutveckling av deras ASP 3 teknik. Plattformen har flera positiva sidor, vilket ledde till att den blev stommen i systemet, dessa fördelar är bl.a. (Microsoft ASP.NET Team, 2007): Antal rader kod för att göra komplicerade system kan hållas nere tack vare inbyggda delar, bl.a. Validation Controls som validerar indata. Källkoden kompileras vilket gör att användare av systemet använder färdigkompilerade filer för att generera sidorna vilket i sin tur medför snabba laddningstider. Webbservern IIS har inbyggt stöd för att undvika problem med bl.a. minnesläckor och oändliga loopar i koden. Upptäcks sådant startas aktuella processer sömlöst om. Då källkoden ligger färdigkompilerad på servern kan programmeringsspråket väljas bland flera olika, bl.a. VB.Net, J# eller C# (detta systems språk). Det finns nackdelar då man jämför ASP.Net med andra alternativ (oftast open sourcescriptspråket PHP). En av de stora nackdelarna är att ASP.Net är utvecklat för att köras på Microsofts IIS server, vilken kräver Microsoft Windows (Microsoft ASP.NET Team, 2007). Detta var dock ingen nackdel i detta fall då operativsystemet på servern som tillhandahöll webbservern var Microsoft Windows Server Ajax Ajax står för Asynchronous JavaScript and XML vilket är ett samlingsnamn för olika tekniker som används för att skapa mer interaktiva webbapplikationer (AJAX: Microsoft ASP.NET Team, 2007). Tekniken som används bygger på XMLHttpRequest objekt vilket gör det möjligt att med hjälp av JavaScript göra serveranrop utan att hela sidan laddas om. Det innebär att man bara kan uppdatera den del av sidan som förändrats istället för hela sidan. DOM som står för Document Object Model är det som gör det möjligt att förändra innehållet på sidan med JavaScript (Batra, 2006). 3 Active Server Pages

41 Webbaserad kommunikationsplattform 41 Det nya systemet använder sig av Ajax på de ställen där data ska hämtas från databasen, är det en avancerad förfrågan som skickas till databasen som tar lång tid kommer användandet av Ajax att göra det möjligt att använda sig av en animerad bild som visar att systemet är upptaget. Största fördelen med tekniken är dock att trafiken mellan klienten och servern minskas avsevärt eftersom klienten återanvänder de delar av sidan som inte har förändrats Databas Databashanteraren som systemet använder sig av är av typen MySQL 5.0 där lagringstypen på tabellerna är InnoDB 4, detta för att ha stöd för sekundära nycklar och triggers. Dessa funktioner saknade tidigare versioner av MySQL och därför valdes MySQL 5.0 som databashanterare. För att systemet ska ha potential för att ytterligare kunna utökas har tabellerna gjorts så generella som möjligt, dvs. det finns möjlighet att använda databasen till ett intranät med fildelning samtidigt som det används som kommunikationsplattform mellan lärare och elever MySQL MySQL är världens mest använda open source databashanterare och används av många av världens största databasdrivna webbplatser, bl.a. Google, Wikipedia, Flickr och Facebook (MySQL AB). Från början härstammar MySQL från Sverige där det har utvecklats, men numera ägs MySQL av Sun Microsystems. Gränssnitten som användes till databashanteraren var NaviCat 8 (Navicat) och MySQL Administrator 1.2 (MySQL Administrator). Dessa verktyg har använts på olika sätt, där NaviCat främst har använts vid skapandet av tabeller och procedurer, MySQL Administrator har använts vid administration av själva MySQL servern Databasstruktur Databasen är konstruerad utifrån tanken att systemet skall vara förberett för framtida expansion och fler användningsområden än inom utbildning samt att det även ska kunna användas som intranät. För att komma fram till en struktur som fungerar har olika scenarion av extremfall tänkts igenom, t.ex. om en person ska ha två olika användare 4 InnoDB är en lagringsmotor i MySQL som till skillnad mot typen MyISAM gör det möjligt att använda sig av transaktioner och sekundärnycklar (Dyer, 2005, ss ).

42 Webbaserad kommunikationsplattform 42 (fallet där en elev också arbetar som lärare) kan man inte ha personnumret som primärnyckel eftersom det kommer finnas två användare med samma personnummer. Det är emellertid svårt att på förhand föreställa sig alla tänkbara extremfall men alla tabeller har utformats på ett så generellt sätt som möjligt för att kunna hantera detta. När databasstrukturen hade upprättats skapades ett ER schema över databasen (Padron McCarthy & Risch, 2005, ss ). Ett ER schema ger en väldigt bra överblick över hur databasen är konstruerad. Vidareutveckling underlättas när det finns en grafisk representation av databasen att jobba efter, vilket även är till nytta för utomstående som ska sätta sig in i systemets uppbyggnad. Figur 18 visar en överblicksbild över hela databasens uppbyggnad. Figur 18 ER schema över hela databasen

43 Webbaserad kommunikationsplattform 43 Figur 19 visar en detaljerad bild över en liten del av databasen, tabellen som lagrar användare, tabellen som lagrar alla systemets grupper samt tabeller för dess relationer. Bilden visar även hur användarna ärver attribut från tabeller som innehåller ytterligare information om just den specifika användaren, dvs. är användaren en elev erhålles ytterligare information om användaren från elevtabellen. Tabellen Grupp i systemet kommer att innehålla samtliga grupperingar av användare, exempelvis kan en grupp vara klass, som i sin tur ingår i gruppen årskull, som i sin tur ingår i gruppen skola, o.s.v. På så vis kommer all grupphantering att bli dynamisk och man får en hierarkisk struktur på alla grupper i systemet. Användarhanteringen kommer också att använda sig av arv, där varje användare i tabellen Elev hör till föräldratabellen Användare. Genom att göra på detta sätt kommer alla elever att få alla attribut som finns i tabellen användare vilken är gemensam för samtliga användartyper i systemet. Figur 19 Detaljbeskrivning av databasen 5.5 Säkerhet Då mycket av den information som finns i systemet är känslig hade säkerheten högsta prioritet. Genom hela utvecklingsprocessen har säkerheten varit i centrum och varje steg har tänkts igenom för att i största möjliga mån förebygga eventuella säkerhetsluckor..net plattformen erbjuder ett stort paket av färdiga säkerhetslösningar vilket har underlättat arbetet, bl.a. Forms Authentication och Rollhanteringen som nämns nedan.

44 Webbaserad kommunikationsplattform 44 Lösenorden som lagras är samtliga krypterade med hjälp av hashning 5 och saltning 6, där varje lösenord har flera separata saltningar Forms Authentication För att hålla reda på att användaren är autentiserad användes.net Forms Authentication. I första stadiet kontrolleras om användarens namn och lösenord stämmer överens. Stämmer detta loggas användaren in, inloggningen hanteras av Forms Authentication genom hela användandet av den aktuella sessionen, som avslutas antingen genom att användaren loggar ut manuellt genom utloggningsknappen eller stängning av webbläsaren. Användarens inloggning hålls kvar genom en session och en relaterad session cookie, vilka skapas automatiskt. Detta kan leda till s.k. session hijacking, då någon illvillig person kommer över den cookie som den rättmätiga användaren har och använder för att få access till dennes inloggning. Detta är taget i beaktande och systemet har funktioner som märker av om fel person använder fel cookie Roller Även om användaren är autentiserad och inloggad betyder det inte att användaren har rätt att komma åt allt som finns i systemet. Administratörer har exempelvis rätt att lägga till och ta bort elever, vilket inte eleverna själva har. För att hantera detta användes.net Roles. Det är ett system för att ge olika användare rättighet att komma åt specifika platser på en hemsida. Den rollhantering som är standardiserad och förinställd kräver en Microsft MS SQL databashanterare vilket inte användes. Detta löstes genom att göra en egen Role klass vilket gav fördelen att rollerna kunde hämtas ifrån en MySqldatabashanterare. Att göra egna Role klasser möjliggörs då interfacet RoleProvider används. 5 I detta fall en envägskryptering för strängar. 6 Sträng som blandas med den sträng som ska krypteras.

45 Webbaserad kommunikationsplattform 45 I utveckling av systemet användes följande roller som grund (roller kan senare läggas till och tas bort): Gud o Används av några enskilda personer. Kan t.ex. lägga till/ta bort skolor, och administratörer från systemet. Administratör o Någon eller några personer per skola kommer att vara administratör, vilken t.ex. kan lägga till/ta bort lärare. Lärare o Lärarna kan t.ex. lägga till/ta bort elever och skriva in nyheter för skolan och klasser i systemet. Personal o Personal som inte är lärare får denna roll. Elev o Har inga rättigheter att ändra något i systemet förutom sina egna objekt, såsom meddelande, uppgifter etc. Målsman o Kan se information om sitt barn, t.ex. frånvaro, provresultat och betyg. Rollerna har en hierarkilknande struktur då en roll har de rättigheter som underliggande roller har. T.ex. har rollen Gud rättighet att lägga till/ta bort elever SSL För att förhindra sniffning 7 av data som skickas mellan server och klienten (användaren) använder det nya systemet SSL Secure Socket Layer. Detta innebär att trafiken krypteras och blir oanvändbar för eventuella avlyssnare. SSL är ett säkerhetslager som körs mellan TCP och ovanstående lager, t.ex. HTTP (Howard & LeBlanc, 2003). Krypteringsgraden är ofta antingen 40 eller 128 bitar, vilket motsvarar längden på den krypteringsnyckel som används. En högre bitlängd på nyckeln ger ett säkrare krypteringssystem och det nya systemet använder krypteringsgraden 128 bitar. Då all information skall krypteras/dekrypteras kan systemet få en minskad prestanda i 7 Att avlyssna trafik mellan två parter, i detta fall att avlyssna trafiken som skickas mellan klient och server. Bl.a. lösenord kan snappas upp om dessa skickas okrypterat i klartext.

46 Webbaserad kommunikationsplattform 46 jämförelse med ett okrypterat system men säkerheten ligger i fokus och det är beräknat att prestandan skall räcka till för att få en snabb och användbar plattform även med SSL. Vidare erbjuder Secure Socket Layer ett certifikat där en trejdepart garanterar att den sida klienten försöker ansluta till verkligen är den sida som anges, detta för att förhindra falska sidor som lurar användaren att skicka in t.ex. sitt användarnamn (Klarqvist & Corneliusson). Det finns olika s.k. Certificate Authorities (CA), utfärdare av godkända certifikat som de stora webbläsarna litar på (Mozilla Firefox, Internet Explorer m.fl.). Det går att skapa ett eget certifikat för att garantera att den sida klienten surfar in på är den som utges men då måste användaren godkänna att den litar på certifikatet. Att använda en pålitlig CA är därför att föredra. SSL kan användas med en eller tvåvägscertifiering. Med envägscertifiering har bara servern ett certifikat och med tvåvägscertifiering har även klienten ett certifikat för att förvissa servern om dess äkthet. I detta system används envägscertifiering då det räcker att användaren litar på servern. SSL fungerar på följande sätt (Klarqvist & Corneliusson): 1. Klienten ansluter med en krypterad uppkoppling med prefixet HTTPS istället för HTTP. 2. Från servern skickas den publika nyckeln och information om certifikatet till klienten. 3. Certifikatet har olika data som processas av klienten, t.ex. giltighetsperiod och domännamn. 4. Data som skickas tillbaka från klienten krypteras med hjälp av den publika nyckeln. 5. Data tas emot av servern som dekrypterar den med dess privata nyckel. 6. Data (HTML sidan) som skall returneras till klienten krypteras med den privata nyckeln för att obehöriga personer inte skall kunna dekryptera dessa data. 7. Webbläsaren tar emot sidan och visar upp den genom att dekryptera den med den öppna nyckeln.

47 Webbaserad kommunikationsplattform Kontroll av indata Eftersom alla indata som användare kan mata in i ett system skall ses som möjligt skadliga måste skydd mot detta implementeras (Howard & LeBlanc, 2003). Med hjälp av inbyggda klasser för validering i ASP.Net 3.5 blir det på ett enkelt sätt möjligt att kontrollera alla indata som matas in via formulären i systemet. Det finns även inbyggda klasser för att skapa parameteriserade SQL anrop till databasen, på så vis kan man skydda sig mot skadliga SQL injections (Padron McCarthy & Risch, 2005, ss ).

48 Webbaserad kommunikationsplattform 48

49 Webbaserad kommunikationsplattform Diskussion Arbetet med utvecklingen av det nya systemet har i det stora hela fungerat ganska bra, men givetvis har problem uppkommit som vid de flesta projekt. Tidsplaneringen är den del som har varit det allra svåraste under arbetets gång, främst beroende på att vi har saknat erfarenhet av att utveckla ett system som är i den här omfattningen, men även beroende på andra faktorer. Dessa faktorer har bl.a. varit att vi i december blev administratörer för det gamla systemet i och med att den person som utvecklat och administrerat det tidigare slutade. Detta resulterade i att en del av vår tid gick åt till arbete med det gamla systemet. I och med detta arbete har vi dock fått en god inblick i vad som krävts av en administratör av ett system som vi sedan kunnat använda vid planeringen av det nya systemet. Vi hade även problem med att kunna avgöra vilken typ av server vi skulle beställa, även detta på grund av bristande erfarenhet inom ämnet. För att lättare kunna avgöra vilken kapacitet vi behövde på servern tog vi kontakt med bl.a. Apberget.se (en ungdomscommunity) för att få tips om detta. När servern väl blev beställd var det ganska lång leveranstid på den vilket även det ledde till en förskjutning i tidsplanen. Huvudmålet med projektet var att förbättra användarvänligheten och säkerheten, detta anser vi har åtgärdats i och med de lösningar vi har valt att använda oss av. Eftersom gränssnittet inte är helt klart så är det svårt att säga om effektiviteten i användandet har förbättrats eftersom inga användbarhetstester har gjorts på det nya systemet. Dock kan antagandet göras att det förenklade gränssnittet kommer att leda till förbättrad effektivitet jämfört med ThorenGruppens gamla system. Detta eftersom Normans forskningsresultat pekar på att god mappning av gränssnittet leder till detta (Norman, 2002). Detta har avklarats: Systemet har fått väl igenomtänkt säkerhet med bl.a. SSL, kontroll av alla indata till systemet och kryptering av känsliga data. Designen är gjord för att effektivisera arbetet samtidigt som det skall inbjuda till användning från många användargrupper. Feedback används för att ge användaren information om vad som händer. Bl.a. används en laddningsindikator i de AJAX fönster som laddar information för att användaren skall veta att något händer. Systemet är modulförberett vilket gör att många nya funktioner kan läggas till utan att komplikationer uppstår i databasen.

50 Webbaserad kommunikationsplattform 50 Systemet har fått en modularitet som gör att nya funktioner kan läggas till i framtiden genom att databasen är utbyggbar och webbsidorna är separata för olika funktioner. Systemet har en bättre skalbarhet då MySQL som databashanterare är snabbare än Microsoft Access, vilken Progress använder. Lärdomarna i detta projekt har varit otroligt många, bland annat har vi aldrig tidigare gjort följande (vi har således fått lära oss detta under projektets gång): Planerat ett så här stort system. Satt upp en komplett webbserver. Konfigurerat SSL protokoll. Krypterat data. Använt Visual Studio 2008/ASP.Net 3.5. Använt AJAX, m.m. Den största lärdomen vi har fått är hur omfattande det är att designa databasen på ett bra sätt från start då den är kärnan i systemet. Denna del är även väldigt tidskrävande men det är väl spenderad tid då misstag i databasdesignen kan generera mycket merarbete i slutändan, vilket vi bl.a. själva har upplevt då vi administrerat det gamla systemet (Progress). I skrivande stund är systemet ej i drift och saknar omfattande delar av gränssnittet för att det ska vara möjligt att kunna använda systemet fullt ut. Utvecklingen kommer att fortsätta och baseras på den prioriteringslista som tagits fram. Förhoppningen är att under tiden som systemet är i drift ska ny funktionalitet fortsätta utvecklas som i sin tur ska kunna leda till att systemet ska kunna säljas till andra skolor och företag. Vi har väldigt många idéer om vad som kan implementeras i framtida versioner eftersom möjligheterna för en webbapplikation är otroligt stora när man bl.a. använder sig av Ajax. Några framtida idéer: Lärare kan skicka ut massutskick till elever via SMS om t.ex. inställda lektioner m.m. Distanselever och lärare kan boka in hjälptimmar där läraren och eleverna har möjlighet att chatta med varandra och chatten sparas för framtida bruk. Lärare inom samma ämne på olika skolor i Sverige kan lägga ut kursmaterial som är åtkomligt av alla andra lärare inom samma ämne. Hantering av RSS flöden.