På Samling 3 skal vi jobbe med begrepet "awareness" og tar utgangspunkt i Tam og Greenberg's artikkel om awareness ved asynkront samarbeid.
Vi bruker denne bloggen for å utvikle lesestøtte til artikkelen sammen. Det som er den største forskjellen sammenlignet med Google docs, som vi har brukt på samling 1 og 2, er at dette verktøyet er asynkront.
Oppgave: Gå sammen to og to, og ta for dere ett av informasjonselementene for change awareness (fordeles på samlingen). Lag et sammendrag (på norsk) om informasjonselementet. Dette skal legges ut i denne bloggen som kommentarer til dette innlegget.
Sist endret av: Line Kolås 2011-01-11 10:12 Slett Endre
SvarSlettPål og Tor - punkt 4.1 -Where
Rune og Anders -punkt 4.2 - Who
Roar og Eivind - punkt 4.3 What
Rune og Jens - punkt 4.4 og 4.5 (How + When)
Aleksej - punkt 4.6 (Why)
4.3 What
SvarSlettBeskriver HVA som er endret: Action history. To ulike måter: Den ene måten tar for seg alle detaljene, inkl posisjonering, oppretting, navngiving etc.. Den andre måten er høy-nivå endringer.
Det er viktig å påpeke at man kan sammenstille og kombinere flere lav-nivå handlinger for å bygge en høy-nivå handling hvis man har nok utfyllende informasjon for å forstå sammenhengen mellom de enkelte små handlingene.
4.2 Hvem?
SvarSlettEn person som jobber i prosjektet og som har et person basert perspektiv vil sannsynligvis fokusere mest på "hvem" kategorien.
Å holde orden på hvem som har gjort hva er viktig for å kunne spørre den personen senere om mer informasjon.
I tillegg er det med på å gi en identitet til de endringene som er gjort. Dette er med på å gjøre det enklere for andre å godta de endringene som er gjort i det arbeidet de selv har gjort. Man merker også raskt hvordan man skal forholde seg til det de forskjellige deltakerne har gjort. (Folk jobber på forskjellige måter, og enkelte trenger kanskje noen som følger med litt mer enn andre gjør.)
Derfor kan også en logg som viser hva hver enkelt deltager har gjort være nyttig, i tillegg til loggen over hvem som har endret akkurat den og den biten.
I Gutwins konsept for historiske data kan en loggføre hvem som har lest hva og hvem som har skrevet eller endret noe. I tillegg til til dette kan en også se om en person har lest noe uten å gjøre endringer.
Dette er viktig da en vet at vedkommende har sett på endringene som er gjort uten å ha fremmet noen invendinger mot dette. En kan si at vedkommende implisitt har godkjent jobben som er gjort.
Denne kommentaren har blitt fjernet av forfatteren.
SvarSlettHvorfor?
SvarSlettDet er en naturlig faktor at du vil gjerne vite ”hvorfor” noen ting var forandret i et prosjekt, særlig hvis du var autor for akkurat denne delen av prosjektet. Hovedårsaker til at ”lederen” valgte å forandre noen ting i prosjektet skyldes av to årsaker: Kognitiv eller motivasjonsmessig.
Den kognitive årsaken, det vi si den logisk resonnement, kan stå bak at en forandring var gjort. Det blir ofte gjort fordi en gruppe jobber sammen mot et felles mål og har lyst å lykkes.
Den motivasjonsmessige årsaken er ofte en spontan reaksjon på et innhold som vekte en uenighet rundt et tema. Personen som har gjort den forandring bør ha et velbegrunnet svar på hvorfor han har gjort det. Ellers kan denne forandringen føre til mer omfattende uenighet som kan oppstå på et senere tidspunkt, der hvor personlig forhold kan bli utviklet til noe negativt.
En del forandringer skyldes av rent uhellmessig grunnlag. Det oppstår i de tilfeller når brukeren ikke har nok kunnskap om den tekniske aspekten av programvaren de benytter og derfor gjør små feil.
Lavt nivå: Små forandringer som er knytte mot grammatiske feil.
Høgt nivå: Store forandringer av innholdet.
Motivasjonsmessig årsaker er ofte veldig vanskelig å akseptere, siden mennesker kan bli uenige rundt et tema og da er den velformulerte begrunnelser som tar tak over andres påstander.
Moderne programvarer har en innebygd funksjon som kan skille mellom den tekniske eller kulturelle årsaken til hvorfor en forandring ble gjort. I de fleste tilfeller en forandring vil automatisk føre til en diskusjon.
4.1. Hvor?
SvarSlettPlasseringen i et 2D-grafisk arbeidsrom kan være et enkelt område, eller en direkte digital analog av fysiske avgrensninger. Det vil si rommene i et rom-basert system som TeamRooms (Greenberg and Roseman,2003) eller plasseringer kan være mer abstrakte i måten de knytter sammen forskjellige arbeidsroms-enheter. I alle sakene har plasseringen av en endring verdigfulle spor i sin del av konteksten. Dette leder senere folk mot videre utforskning. For eksempel en person kan spørre om en spesifikk endring var en del av prosjekt-komponenten som har gjennomgått omfattende endringer. Dette gjelder hvis endringen som oppsto befinner seg på samme sted som mange andre endringer er gjort.
Tabell 3 viser spesifikke spørsmålene som kan bli stilt for å forstå ”hvor” endringer har oppstått i forhold til hver av de tre arbeidsplass-perspektivene. Som tidligere nevnt så er forskjellen hvordan man spør om endringene som er blitt foretatt innenfor hvert enkelt perspektiv.
Spørsmålene kan være som følgende: Hvor er den nå? Hvor var den tidligere? Hvor har den vært siden sist jeg sjekket den.
Fra den person-baserte synsvinkelen, kan spørsmålene bli stilt om en spesifikk medarbeider. Hvor har denne personen vært eller sett i arbeidsrommet? Hvor endret personen noe?
Fra den arbeidsrom-baserte synsvinkelen kan følgende spørsmål bli stilt: Hvilke deler av arbeidsrommet har personer besøkt? Hvor ble verktøyene flyttet?
For å se hvor en person har gjort endringer bruker man Gutwin`s location, gaze og edit history. Location History refererer til hvor en person har besøkt i et workspace. Gaze History tar for seg hva i workspace en person har sett på. Forskjellen er at uansett om en person har vært på ein spesifikk plass på et workspace, så er det ikke sikkert at den personen har aktivt sett på alt i det workspacet. Dette gir ikke akkurat noe formening om hva som har blitt endret, men kan fortelle hvor folk har vært å hva som har blitt sett på, noe som igjen gir sterke tegn på hvor man kan lete etter forandringer.
Edit History tar for seg de forandringene som har blitt gjort.
test tid
SvarSlettHow?
SvarSlett“How”-kategorien spør hvordan den nåværende arbeidsplassen er forskjellig fra før. “Process history” indikerer hvordan arbeidsplassen har utviklet seg siden sist. Process history er tett knyttet opp i mot action history. Forskjellen er at action history inneholder alle handlingene som har skjedd siden brukeren har vært borte, mens process history inneholder et sett med alle handlingene i en serie med steg i en prosess.
Prosess oppfatningen er viktig siden folk kan ha problemer med å oppfatte umiddelbare forandringer. Dermed kan det hjelpe å beskrive de mindre stegene i en forandring for å forklare hva som har skjedd.
Den prosess-orienterte oppfatningen beskriver utviklingsmessige konteksten til forandringer, og gir innsikt i “why” og “how” hvordan ting kom til å bli i sin nåværende status.
Outcome history dreier seg rundt det endelige utkommet. Den presenterer bare de viktigste forandringene fra første til endelige status.
Valget mellom process history og outcome history er avhengig på hva som skal gjøres. En grafisk kunstner kan være interessert i teknikken brukt til å lage visuelle effeker. I dette tilfellet bør personen se process historyen til arbeidsplassen. En avisredaktør kan se igjennom en artikkel til en reporter har det mest sannsynlig travelt, og vil nok heller være interessert i outcome history.
When?
SvarSlett“When” - Innebærer når og i hvilken order forandringer har skjedd. Er viktig for å gi en kronologisk kontekst av arbeidsplassen.