Den 3. stemme - en undersøgelse af skønlitterære ... - Kjeld Schmidt

More documents

Recommendations

Info

74 Design - vores proces Dekomponering af funktioner Dekomponering af funktioner (Dewan, 2001, s. 82ff) er en aktivitet, hvor den overordnede systemfunktionalitet opdeles i underfunktionaliteter. Dewan giver eksempler s˚asom ’undo’ og ’adgangskontrol’. Ved at foretage denne dekomponering er det muligt at fokusere sit design. De forskellige underfunktionalieter, der indg˚ar i det samlede system, vil ofte i nogen grad være afhængige af hinanden, men ved dekomponeringen bliver det muligt at isolere de komplekse dele, som alene vedrører en enkelt underfunktionalitet. Den overordnede kompleksitet i designarbejdet kan herved reduceres. Som i Dewans model startede vi med at finde frem til systemets funktionalitet. Vi startede med de overordnede punkter, vi fandt frem til i analysen. Der er her tale om b˚ade konkrete funktioner, f.eks. støtte til notetagning eller et persongalleri, og mere komplekse funktionaliteter, s˚asom diskussion og støtte til gensidig opmærksomhed (jf. liste i figur 4.4). Vi vil her hævde, at selvom vi har fundet komplekse funktionalitetskrav til systemet fra relevant CSCW-litteratur, havde det ikke været muligt at definere mere forfatterspecifikke krav uden en informationsindsamling og analyse af samme. Hvorfra Dewan udleder kravene til et givent systems funktionalitet, er ikke beskrevet i artiklen. Men forst˚aelsen af brugeres arbejdspraksis og en analyse af samme, mener vi, er et essentielt fokuspunkt i en udviklingsproces. Scenarieudvikling Scenarieudvikling (Dewan, 2001, s. 84ff) bruges til at beskrive en brugers interaktioner med en applikation. Der vil tidligt i en systemudviklingsproces være tale om hypotetiske scenarier, idet de anvendes i et forsøg p˚a at forst˚a, hvordan de potentielle brugere kunne tænkes at interagere med applikationen. Dewan beskriver to former for scenarier: [They] can be application-specific or application-independent based on whether it is described in terms that are specific to a particular application. (Dewan, 2001, s. 84) Om de to typer scenarier forklarer Dewan, at de applikationsspecifikke indeholder beskrivelser om fiktive brugere, der udfører en given handling, og de identificerer derved krav til applikationen. De applikationsuafhængige scenarier beskriver en handling i mere abstrakte termer og opstiller s˚aledes bl.a. krav til infrastrukturen.
5.1 Fremgangsm˚ade i designprocessen 75 Dewan fremhæver, at en vekselvirkning mellem de to bringer gode resultater, og de kan hver især være med til at generere scenarier af den modsatte type. Da vi ikke beskæftiger os med designmæssige aspekter, der har med infrastrukturer at gøre, har vi udelukkende opereret med applikationsspecifikke scenarier. Disse har været særligt anvendelige i forbindelse med udviklingen af et samarbejdssystem, hvor en fasttømret og veldefineret arbejdspraksis ikke findes. Derfor er det nødvendigt, at vi som designere forsøger at forestille os de situationer, som kan opst˚a i arbejdet med det kommende system, for p˚a den m˚ade at finde frem til de krav, et s˚adant system fordrer. Her er scenarier brugbare, fordi de netop opstiller situationer for arbejdet med det fremtidige system. Det har desuden været essentielt for os, at vi i arbejdet med scenarierne har inddraget vores viden om brugerne. Et eksempel p˚a, hvordan vi har inddraget denne viden, kan opsummeres i dette spørgsm˚al: Hvad nu hvis Loke ønsker at se nogle gamle versioner af Jespers bidrag til projektet, fordi han er g˚aet i dialog med indholdet i disse bidrag (jf. afsnit 4.4.2). Dewan pointerer, at det kan være svært at inddrage brugerne direkte i scenarieudviklingen, da de kan have svært ved umiddelbart at tage stilling til, hvad der teknisk kan lade sig gøre. Vi vil dog hævde, at der findes kvaliteter ved at indsamle viden om omr˚adet ved hjælp af etnografiske metoder og herudfra udarbejde scenarierne. Scenarierne kan s˚a igen anvendes ved en forst˚aelsestest af skærmbillede mock-ups, hvilket vi vil komme ind p˚a senere i afsnittet om brugen af workshops. Ud fra de funktionalitetskrav, som vi fandt frem til ved dekomponeringen (Dewans 1. fase), forsøgte vi gentagne gange ved hjælp af scenarier at beskrive en eller flere potentielle processer for vores kommende system (se figur 5.1 i afsnit 5.2.1). Det vil sige, at vi forestillede os processen fra begyndelsen af et projekt og frem til skrivningen. For vores projekt har det at arbejde med scenarier desuden været et vigtigt værktøj, som ogs˚a er blevet anvendt i andre henseender. Scenarierne har hjulpet os til at forst˚a funktionaliteters potentielle muligheder og har fungeret som diskussionsoplæg i designprocessen. Derfor kan scenarier for os ikke reduceres til et punkt i en faseinddelt model, men snarere som en aktivitet, der under hele designprocessen kan bruges til at klarlægge vigtige designbeslutninger og komplekse problemstillinger. Principper Udover scenarieudvikling som hjælp til at identificere krav til det kommende system, pointerer Dewan relevansen af den forskning, som allerede har fundet sted
Page 1:
Den 3. stemme - en undersøgelse af
Page 5:
Abstract The work described in this
Page 8 and 9:
8 INDHOLD 4.4.3 Overlap mellem indi
Page 10 and 11:
10 INDHOLD
Page 12 and 13:
12 FIGURER
Page 14 and 15:
14 Indledning samarbejde om disse h
Page 16 and 17:
16 Indledning af, hvad vi med udvik
Page 18 and 19:
18 Begreber og position De forsknin
Page 20 and 21:
20 Begreber og position 2.1.2 Produ
Page 22 and 23:
22 Begreber og position er ogs˚a m
Page 24 and 25: 24 Begreber og position [W]ork is a
Page 26 and 27: 26 Begreber og position den m˚ade,
Page 28 and 29: 28 Forfattere og værket 3.1 Forfat
Page 30 and 31: 30 Forfattere og værket The author
Page 32 and 33: 32 Forfattere og værket for at kom
Page 34 and 35: 34 Forfattere og værket
Page 36 and 37: 36 Analyse med det angivne fokus p
Page 38 and 39: 38 Analyse ¡ for denne information
Page 40 and 41: 40 Analyse Figur 4.1: Triangulering
Page 42 and 43: 42 Analyse forst˚aelse for begrebe
Page 44 and 45: 44 Analyse benytter sig af de neden
Page 46 and 47: 46 Analyse spørgsm˚al, som angive
Page 48 and 49: 48 Analyse N˚ar jeg endelig skrive
Page 50 and 51: 50 Analyse For fælles projekter er
Page 52 and 53: 52 Analyse Jesper]. Hvor jeg troede
Page 54 and 55: 54 Analyse derfor nogle af disse as
Page 56 and 57: 56 Analyse Kritik af tekst Hvorn˚a
Page 58 and 59: 58 Analyse En fiktionsfilm er en be
Page 60 and 61: 60 Analyse rende til den der kan se
Page 62 and 63: 62 Analyse man ikke bruge det, der
Page 64 and 65: 64 Analyse Figur 4.4: Affinitetsdia
Page 66 and 67: 66 Analyse give mulighed for at fin
Page 68 and 69: 68 Analyse Et overordnet problem, s
Page 70 and 71: 70 Analyse
Page 72 and 73: 72 Design - vores proces 5.1 Fremga
Page 76 and 77: 76 Design - vores proces inden for
Page 78 and 79: 78 Design - vores proces vi har for
Page 80 and 81: 80 Design - vores proces og vi har
Page 82 and 83: 82 Design - vores proces skærmbill
Page 84 and 85: 84 Design - vores proces 5.3 See—
Page 86 and 87: 86 Design - vores proces til flere
Page 88 and 89: 88 Design - CONCERT Figur 6.1: Invi
Page 90 and 91: 90 Design - CONCERT Figur 6.6: ’C
Page 92 and 93: 92 Design - CONCERT 6.1.3 Scener op
Page 94 and 95: 94 Design - CONCERT Figur 6.11: Log
Page 96 and 97: 96 Design - CONCERT det til eventue
Page 98 and 99: 98 Design - CONCERT 6.2.2 XML Schem
Page 100 and 101: 100 Design - CONCERT Med denne refe
Page 102 and 103: 102 Design - CONCERT mulighed for a
Page 104 and 105: 104 Design - CONCERT
Page 106 and 107: 106 Design - diskussion af designva
Page 118 and 119: 118 Diskussion - relevante forsknin
Page 124 and 125:
124 Diskussion - relevante forsknin
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
138 Perspektivering 9.1 Videre fors
Page 140 and 141:
140 Perspektivering
Page 142 and 143:
142 Litteratur
Page 144 and 145:
144 LITTERATUR J. Brixvold, P. H. L
Page 146 and 147:
146 LITTERATUR J. Irving. Min filma
show all

Den 3. stemme - en undersøgelse af skønlitterære ... - Kjeld Schmidt

Create successful ePaper yourself

Delete template?

Save as template?