inf 1510: evaluering...I'll present my newest usability guidelines in the tutorial on Fundamental Guidelines for Web Usability at the Usability Week 2009 conference in Las Vegas and

Tone

Bra

ttete

ig –

26/

3 20

12

inf 1510: evaluering

mål:

¤  oversikt over ulike metoder for evaluering

¤  bakgrunn for å planlegge og gjennomføre evaluering i prosjektet

dagsorden:

¤  evaluering; hva er det og hvorfor gjør vi det

¤  kort påminnelse om DECIDE-rammeverket

¤  midtveis-evaluering

¤  evaluering av gruppearbeidet (bakgrunn for Oblig 3)

Tone

Bra

ttete

ig –

26/

3 20

12

hvorfor evaluering?

vi lager ting for andre … “brukskunst” ?

¤  hva er det vi vil vite underveis i design-prosessen?

¤  klarer brukerne bruke produktet? Vil de bruke det? Vil de kjøpe det?

¤  hva kan vi teste underveis, og når? (ideer, modeller, prototyper mm)

¤  hvor og hvordan skal vi teste? (lab eller naturlige omgivelser)

Preece et al kap. 12, 13, 14 og 15

Tone

Bra

ttete

ig –

26/

3 20

12

hvor i tingenes livsløp?

kjøp vedlikehold søppel reparere

forstå lære, 5lpasse

kast

ønske behov produkt lage vane, mestre, forbedre

modernisere oppdatere, pusse opp, bygge om …

ideer

bygge & teste

oppd

rag

salg

design bruk

FORSTÅ PRAKSIS

IDENTIFISER

BEHOV & KRAV

MATERIALISER

KONKRETISER

TEST &

EVALUER

visj

on

skis

ser

prot

otyp

er

…

…

spes

ifika

sjon

Tone

Bra

ttete

ig –

26/

3 20

12

hvor i tingenes livsløp?



kast



ideer

bygge & teste

oppd

rag

salg

FORSTÅ PRAKSIS

IDENTIFISER

BEHOV & KRAV

MATERIALISER

KONKRETISER

TEST &

EVALUER

visj

on

skis

ser

prot

otyp

er

…

…

spes

ifika

sjon

¤  evaluering er innbakt i design

¤  evaluering er integrert med design & analyse (iterativ utvikling)

Boehm 1988

Tone

Bra

ttete

ig –

26/

3 20

12

hva er evaluering?

¤  é-valuer: se verdien av

¤  teste, prøve, sjekke, verifisere, validere … NB systematisk!

sjekke:

¤  at artifaktet virker + blir forstått

¤  at artifaktet 1) gjør de riktige tingene og 2) gjør dem riktig

validere og verifisere

de riktige tingene,

det vi ønsket

riktig resultat,

dvs. funksjonalitet ift kravspesifikasjon

Tone

Bra

ttete

ig –

26/

3 20

12

tingenes livsløp



kast



ideer

bygge & teste

oppd

rag

salg

design bruk

MATERIALISER

KONKRETISER

FORSTÅ PRAKSIS

IDENTIFISER

BEHOV & KRAV

MATERIALISER

KONKRETISER

TEST &

EVALUER

Tone

Bra

ttete

ig –

26/

3 20

12

Association for Computing Machinery

INTENTIONAL DESIGN FOR INNOVATIONCover Story by Karen Holtzblatt

WHAT MAKESTHINGSCOOL?

What Makes Things Cool? Intentional Design for Innovation

pulled unknowingly and unwillingly from within. It is the most basic of human emotions [4].

Throughout our research we encountered joy over and over, hid-den beneath the experience of cool. The experience of cool is compelling because it is tightly connected to the experience of joy and delight. But how can something as simple and limited as a technical gadget or a piece of software create an experi-ence as profound as joy?

Consider the following reactions:• “Look at this, Mom. It’s a flash-

card app to study for the SATs—they even flip. It makes the work like play!”

• “My old high school friend just contacted me—I haven’t talked to her in years. Facebook is soooo cool. I love it!”

• “Come see my HDTV. Can you believe the picture? Do you see the green? It’s better than real grass on the ball field! This is the coolest!”

Joy doesn’t come from one specific feature. It doesn’t come from using trendy colors, or add-ing people that move or jumping graphics. It doesn’t result from using a touchscreen or fewer clicks to complete a task. Rather, joy in life happens when products help us fulfill our most core human motivations: Accomplishment, Connection, Identity, and Sensation.

What is going on with people using cool things? What impacts the expe-rience of cool? How does the cool experience change across the life-cycle as we age? We wanted to iden-tify principles to guide companies in designing cool into their offerings.

We [2] began by going out into the field to understand people’s experi-ence with their cool products. We conducted field interviews with nearly 70 individuals between the ages of 15 and 60 across multiple locations in the U.S. Using Contextual Design [3], our well-known user-cen-tered design technique, we gathered and organized the data, producing affinity diagrams, personas of peo-ple and devices, and activity boards summarizing findings in key activ-ity areas such as health and family. Then we conducted an online sur-vey with more than 800 people in multiple cities across the U.S.

The analysis of all this data revealed the themes of the cool experience and implications for product design. We organized these themes into the Cool Concepts: the Wheel of Joy and the Triangle of Design. We introduce them below.

The absolute center of cool is joy. Joy is our autonomic response to our encounter with the world. Joy is

When Apple released the iPhone in 2007, it was a game-changing product in ways we had not seen for many years. Consumers were talking about it everywhere. They gathered around the phone to watch the pinch and the swivel; they were awed by the pictures, apps, and games. The technol-ogy industry reacted as well. Companies expressed their frus-tration at not being able to create a game-changer too. Everyone wanted to re-create the iPhone’s impact in their own products.

Game-changing products and applications are part of the natural ebb and flow of product design. But something different seemed to be happening with the release of the iPhone: something all-consuming, something related to the overall user experience, something more than previ-ous technology innovations.

But what is that something? What does it mean to design for a trans-formative experience? What makes things cool? What drives the cool user experience? [1] To guide design teams, and to understand what makes things cool, we launched the Cool Project.

Here we introduce the results of the Cool Project and the key con-structs we uncovered as core to the user experience of cool.

Tone

Bra

ttete

ig –

26/

3 20

12

hva er evaluering?

¤  é-valuer: se verdien av

¤  teste, prøve, sjekke, verifisere, validere … NB systematisk!

sjekke:




de riktige tingene,

det vi ønsket

riktig resultat,

dvs. funksjonalitet ift kravspesifikasjon

Tone

Bra

ttete

ig –

26/

3 20

12

hva er evaluering?

¤  teste hva i forhold til hva, for hvem

¤  hva er det som evalueres?

¤  i forhold til hva/hvem: kriterier og mål

¤  av hvem: hvem utfører evaluering og hvordan

¤  for hvem: hva brukes evalueringen til

Tone

Bra

ttete

ig –

26/

3 20

12

hva testes = ��kriterier og mål for evalueringen


¤  funksjonalitet (behov)

¤  kommunikasjon av funksjonalitet

¤  evalueringskriterier


¤  avhengig av hvem som evaluerer og hva som evalueres

at tingene gjøres riktig

de riktige tingene


Tone

Bra

ttete

ig –

26/

3 20

12

hvem og hvordan

¤  den som har laget artifaktet?

¤  den som har bestilt artifaktet?

¤  den som skal bruke artifaktet?

¤  eksterne?

¤  eksperter?

¤  mål: hva er godt nok? Hvem bestemmer det?

omfang

kostnad

(ressurser)

tid

eval

ueri

ngsk

rite

rier

Tone

Bra

ttete

ig –

26/

3 20

12

hvordan = metoder

¤  analytisk evaluering

¤  heuristisk evaluering

¤  summativ evaluering

¤  formativ evaluering

¤  predikerende evaluering

¤  kombinasjoner av disse

¤  bruker-testing

¤  brukbarhets-testing

¤  brukbarhets-studier

¤  bruker-studier

¤  feltstudium

¤  brukbarhets-lab

¤  kontrollert eksperiment

Tone

Bra

ttete

ig –

26/

3 20

12

hvordan = tilnærminger

3 hovedtyper: i lab, i felten, på kontoret

gir forskjellig informasjon, foregår på forskjellig tidspunkt i designprosessen

i lab: brukbarhetstesting

– observere og måle funksjonalitet og kommunikasjon av funksjonalitet

i felten: feltstudier

– observere og intervjue i bruk / med brukere

på kontoret: analytisk

– inspeksjoner, reviews

– heuristisk evaluering (f.eks. Nielsens oppsummering av 249 brukbarhetsproblemer)

Tone

Bra

ttete

ig –

26/

3 20

12

tilnærminger

3 hovedtyper: i lab, i felten, på kontoret

gir forskjellig informasjon og foregår på forskjellig tidspunkt i design

brukbarhetstesting

feltstudier

analytisk

brukere

gjør oppgaver

naturlig praksis

ikke involvert

sted

kontrollert omgivelse (lab)

naturlig

hvor som helst

når

prototype

tidlig

prototype

data

kvantitative

kvalitative

problemer

feedback

målinger og feil

beskrivelser

problemer

type

bruk / anvendelse

naturlig praksis

ekspert

(fra

Pree

ce e

t al

)

Tone

Bra

ttete

ig –

26/

3 20

12

5/13/11 3:29 PM10 Heuristics for User Interface Design

Page 2 of 2http://www.useit.com/papers/heuristic/heuristic_list.html

indicate the problem, and constructively suggest a solution.Help and documentation

Even though it is better if the system can be used without documentation, itmay be necessary to provide help and documentation. Any such informationshould be easy to search, focused on the user's task, list concrete steps to becarried out, and not be too large.

I originally developed the heuristics for heuristic evaluation in collaboration withRolf Molich in 1990 [Molich and Nielsen 1990; Nielsen and Molich 1990]. I sincerefined the heuristics based on a factor analysis of 249 usability problems [Nielsen1994a] to derive a set of heuristics with maximum explanatory power, resulting inthis revised set of heuristics [Nielsen 1994b].

Updated Findings

I'll present my newest usability guidelines in the tutorial on FundamentalGuidelines for Web Usability at the Usability Week 2009 conference in Las Vegasand Berlin.

The conference also includes a full-day course on other methods beyond usertesting.

See Also:

Bruce "Tog" Tognazzini's list of basic principles for interface design. The list isslightly too long for heuristic evaluation but serves as a useful checklist.Examples of the 10 heuristics in Web applications.The 10 usability heuristics applied to everyday life (just for fun).Full set of 2,397 usability guidelines (across multiple reports).

ReferencesMolich, R., and Nielsen, J. (1990). Improving a human-computer dialogue, Communications of

the ACM 33, 3 (March), 338-348.Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90

Conf. (Seattle, WA, 1-5 April), 249-256.Nielsen, J. (1994a). Enhancing the explanatory power of usability heuristics. Proc. ACM CHI'94

Conf. (Boston, MA, April 24-28), 152-158.Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability

Inspection Methods, John Wiley & Sons, New York, NY.

Copyright © 2005 by Jakob Nielsen. ISSN 1548-5552

5/13/11 3:29 PM10 Heuristics for User Interface Design

Page 1 of 2http://www.useit.com/papers/heuristic/heuristic_list.html

useit.com Papers and Essays Heuristic Evaluation Listof Heuristics

Search

Ten Usability Heuristicsby Jakob Nielsen

These are ten general principles for user interface design. They are called"heuristics" because they are more in the nature of rules of thumb than specificusability guidelines.

Visibility of system statusThe system should always keep users informed about what is going on,through appropriate feedback within reasonable time.

Match between system and the real worldThe system should speak the users' language, with words, phrases andconcepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedomUsers often choose system functions by mistake and will need a clearlymarked "emergency exit" to leave the unwanted state without having to gothrough an extended dialogue. Support undo and redo.

Consistency and standardsUsers should not have to wonder whether different words, situations, oractions mean the same thing. Follow platform conventions.

Error preventionEven better than good error messages is a careful design which prevents aproblem from occurring in the first place. Either eliminate error-proneconditions or check for them and present users with a confirmation optionbefore they commit to the action.

Recognition rather than recallMinimize the user's memory load by making objects, actions, and optionsvisible. The user should not have to remember information from one part ofthe dialogue to another. Instructions for use of the system should be visibleor easily retrievable whenever appropriate.

Flexibility and efficiency of useAccelerators -- unseen by the novice user -- may often speed up theinteraction for the expert user such that the system can cater to bothinexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist designDialogues should not contain information which is irrelevant or rarely needed.Every extra unit of information in a dialogue competes with the relevant unitsof information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errorsError messages should be expressed in plain language (no codes), precisely

5/13/11 3:36 PMAskTog: First Principles of Interaction Design

Page 1 of 11http://www.asktog.com/basics/firstPrinciples.html

nn/g useit.com jnd.org

Interaction Design Solutions for the RealWorld

Google Search

Interaction Design Section Living Section About Bruce TognazziniSelect Language

Powered by Translate Search WWW Search

asktog.com

NN/g Home AskTog Basics Principles First Principles of Interaction Design

Jump to:

AnticipationAutonomyColor BlindnessConsistencyDefaultsEfficiency of theUserExplorableInterfacesFitts' LawHuman-InterfaceObjectsLatencyReductionLearnability Limit TradeoffsMetaphorsProtect theUser's WorkReadabilityTrack StateVisible Interfaces

The following principles are fundamental to the design andimplementation of effective interfaces, whether for traditional GUIenvironments or the web. Of late, many web applications have reflecteda lack of understanding of many of these principles of interaction design,to their great detriment. Because an application or service appears onthe web, the principles do not change. If anything, applying theseprinciples become even more important.

• Belorussian Version:http://www.fatcow.com/edu/designedtogivefitts-be/

• Deutsche (German) Version:http://meiert.com/de/publications/translations/asktog.com/firstprinciples/

• Italian Version:http://www.10people.net/tutorial/interaction_design-ask_tog/pricipi_di_interaction_design.html

• Nederlands (Dutch) Version:http://aifia.org/nl/translations/000187.html

• Polish Version:http://offline.pl/blog/podstawy-projektowania-interakcji.html

• Portuguese Version:http://userdesign.org/principios.html

• Spanish Version:http://galinus.com/es/articulos/principios-diseno-de-interaccion.html

Effective interfaces are visually apparent and forgiving, instilling in theirusers a sense of control. Users quickly see the breadth of their options,grasp how to achieve their goals, and do their work.

Effective interfaces do not concern the user with the inner workings ofthe system. Work is carefully and continuously saved, with full optionfor the user to undo any activity at any time.

Effective applications and services perform a maximum of work, whilerequiring a minimum of information from users.

This work is copyright 2003 by Bruce Tognazzini. Permission to makecopies for personal use is granted without reservation, provided thiscopyright notice remains on the copy. Please contact the author forpermission to republish on a web site, to publish in bound form, or tomake multiple copies, except that educators and in-house corporate

Tone

Bra

ttete

ig –

26/

3 20

12

5/15/11 2:33 PMShneiderman's Eight Golden Rules of Interface Design

Page 1 of 1http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html

Shneiderman's "Eight Golden Rules of Interface Design"

These rules were obtained from the text Designing the User Interface by Ben Shneiderman. Shneidermanproposed this collection of principles that are derived heuristically from experience and applicable inmost interactive systems after being properly refined, extended, and interpreted [9].

To improve the usability of an application it is important to have a well designed interface.Shneiderman's "Eight Golden Rules of Interface Design" are a guide to good interaction design.

1 Strive for consistency.Consistent sequences of actions should be required in similar situations; identical terminology should beused in prompts, menus, and help screens; and consistent commands should be employed throughout.

2 Enable frequent users to use shortcuts.As the frequency of use increases, so do the user's desires to reduce the number of interactions and toincrease the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities arevery helpful to an expert user.

3 Offer informative feedback.For every operator action, there should be some system feedback. For frequent and minor actions, theresponse can be modest, while for infrequent and major actions, the response should be more substantial.

4 Design dialog to yield closure.Sequences of actions should be organized into groups with a beginning, middle, and end. Theinformative feedback at the completion of a group of actions gives the operators the satisfaction ofaccomplishment, a sense of relief, the signal to drop contingency plans and options from their minds,and an indication that the way is clear to prepare for the next group of actions.

5 Offer simple error handling.As much as possible, design the system so the user cannot make a serious error. If an error is made, thesystem should be able to detect the error and offer simple, comprehensible mechanisms for handling theerror.

6 Permit easy reversal of actions.This feature relieves anxiety, since the user knows that errors can be undone; it thus encouragesexploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or acomplete group of actions.

7 Support internal locus of control.Experienced operators strongly desire the sense that they are in charge of the system and that the systemresponds to their actions. Design the system to make users the initiators of actions rather than theresponders.

8 Reduce short-term memory load.The limitation of human information processing in short-term memory requires that displays be keptsimple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficienttraining time be allotted for codes, mnemonics, and sequences of actions.

From http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/rules.html

Tone

Bra

ttete

ig –

26/

3 20

12

i lab

Tone

Bra

ttete

ig –

26/

3 20

12

i felten

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket

¤  Determine goals

¤  Explore the questions

¤  Choose the evaluation approach and methods

¤  Identify the practical issues

¤  Decide how to deal with ethical issues

¤  Evaluate, analyze, interpret and present the data

fra Preece et al kap. 13

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket








¤  målene for evalueringen

¤  visjon, grensesnitt, brukbarhet, effekt, robusthet,

pålitelighet ...

¤  hvem skal bruke evalueringen, til hva?

¤  hvilken metode passer?

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket








¤  finn gode spørsmål

¤  hvordan kan dette måles?

¤  hva er indikatorer på dette?

¤  “som man spør, får man svar”

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket







¤  tilnærmingen bestemmer metode

¤  feltstudium, brukbarhetstesting …

¤  metode bestemmer hvilke data som samles inn & hvordan de analyseres

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket







¤  velge og finne brukere

¤  tid og ressurser til rådighet

¤  velge og finne evaluatorer

¤  utstyr til evalueringen

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket







¤  samtykke-erklæring

¤  deltakerne må få informasjon om studien og om

hvordan dataene behandles

¤  og om personvern

¤  og kan avbryte om og når de ønsker

Tone

Bra

ttete

ig –

26/

3 20

12

DECIDE-rammeverket







¤  avhenger av tilnærming og metode

¤  husk:

¤  reliabilitet / pålitelighet (data repliseres) eller troverdighet

¤  validitet eller bekreftbarhet (av analyse, tolkning)

¤  bias eller systematisk skjevhet

¤  område: generalisering eller overførbarhet

¤  effekter og konsekvenser, inkludert bærekraft

Tone

Bra

ttete

ig –

26/

3 20

12

hvorfor evaluere?

vi lager ting for andre … “brukskunst”

¤  hva er det vi vil vite underveis i design-prosessen?

¤  klarer brukerne bruke produktet? Vil de bruke det? Vil de kjøpe det?

¤  hva og når kan vi teste underveis? (ideer, modeller, prototyper mm)

¤  hvor og hvordan skal vi teste? (lab eller naturlige omgivelser)

Preece et al kap. 12, 13, 14 og 15

¤  hva evalueres?

¤  i forhold til hva/hvem:

kriterier og mål

¤  av hvem: hvem utfører evaluering og hvordan

¤  for hvem: hva brukes evalueringen til

Tone

Bra

ttete

ig –

26/

3 20

12

��midtveisevaluering

hva fungerer bra og ikke?

(mer og mindre av)

hvordan jobber dere med emnet

(sml andre emner)

Tone

Bra

ttete

ig –

16/

1 20

12!

!

bli kjent med Arduino!

design

undersøke brukskontekst!

analysere brukskontekst !

!"#$%&%'()*#'"+,-%

fore

lesn

inge

r !

øvin

gsgr

uppe

& p

rosj

ekt!

obl.o

ppg.

1!

obl.o

ppg.

2!

obl.o

ppg.

3!

intr

o A

rdui

no!

mer

Ard

uino!

intr

o br

ukso

rien

tert

des

ign!

idee

r fo

r Ard

uino!

mer

bru

ksor

ient

ert !

desi

gn +

pro

sjek

tarb

eid!

met

oder

for

å fo

rstå

bru

k!

met

oder

for

å la

ge id

eer

og

visj

oner!

met

oder

for

å la

ge s

kiss

er

og p

roto

type

r!

intr

o so

siol

ogi!

intr

o m

edie

vite

nska

p!

intr

o ju

s!

intr

o ps

ykol

ogi!

opps

umm

erin

g og

tip

s!

uke

3 -

16/

1!

uke

4 -

22/

1!

uke

5 -

30/

1!

uke

6 -

6/2!

uke

7 -

13/

2!

uke

8 -

20/

2!

uke

9 -

27/

2!

uke

10 -

5/3!

uke

11 -

12/

3!

uke

12 -

19/

3!

uke

13 -

26/

3!

uke

14 -

2/4!

uke

15 -

9/4!

uke

16 -

16/

4!

uke

17 -

23/

4!

uke 18

- 3

0/4!

uke

19 -

7/5!

uke

20 -

14/

5!

uke

21 -

21/

5!

#$'%../%%.012%

eksa

men

sinn

leve

ring!

met

oder

for

å id

entifi

sere

be

hov

og k

rav!

intr

o pe

dago

gikk!

oppg

aver!

21-2

4/2

!

12/3

!

16/4

!

design!med brukere!

met

oder

for

eval

uere

ef

fekt

+ g

rupp

earb

eid!

øvin

g: !

grup

pear

beid!

obl.o

ppg.

4!14/5

!

30/5

!1/6

!gr

uppe

rap,

vid

eo, w

eb!

indi

vidu

ell r

app.!

prosjektperiode!

inf1

010-

oblig

1 –

10/

2!

inf1

010-

oblig

2 –

16/

3!

inf1

010-

oblig

3 –

20/

4!

inf1

010-

oblig

4 –

16/

5!

inf1

050-

oblig

1 –

2/3!

+,34525/6!

*+-%.%7%4819%

inf1

050-

oblig

3 –

4/5!

inf1

050

eksa

men

– 5

/6!

inf1

010

eksa

men

– 1

2/6!

Tone

Bra

ttete

ig –

26/

3 20

12

evaluering av gruppearbeidet��(bakgrunn for obligatorisk oppgave nr 3)

¤  leveranser i hht plan?

¤  oppdeling og koordinering av arbeidet

¤  roller og oppgaver

¤  arbeidsoppgaver og –ansvar

¤  oppleves arbeidsoppgavene jevnt fordelt? Har alle lært noe nytt?

¤  kjøreregler (være sen, ikke komme, ikke levere, når er det et problem,

sanksjoner)

¤  fakta (# timer, # møter, # bidrag)

Tone

Bra

ttete

ig –

26/

3 20

12

til eksamen��evaluering av prosjekt (& arbeid)

¤  mål

¤  undersøkelse (metoder)

¤  analyse (behov, teori)

¤  design (ideer, prototyper)

¤  testing & evaluering

¤  helhet

¤  innlev. 1: sluttrapport

¤  innlev. 2: video

¤  innlev. 3: individuell rapport

!"#$%$&'()*+"',&$,'

INF1510: evalueringskriterier

Nedenfor er en kort beskrivelse av hvilke kriterier som brukes for å sette karakterer i INF1510. Sluttrapporten, som er en gruppeoppgave er det som gir karakteren til alle i prosjektgruppa. Men gruppa må bestå innlevering nr. 2: en videoen som presenterer design-resultatet: her kan hele gruppa stryke. I tillegg må alle medlemmene i gruppa bestå innlevering nr. 3: en individuell rapport om arbeidet og læringsresultatet i emnet. Det betyr at enkelt-individer i gruppa kan stryke om de ikke får bestått på sin individuelle rapport. Dersom alle i gruppa består alle tre oppgavene, får alle i gruppa samme karakter: den som ble gitt på rapporten. Tommelfingerregelen er at C er en grei gjennomføring av det som må gjøres i emnet, uten noe særlig ekstra innsats utover de forventede 10 studiepoengene (= 40 timer / 3 emner = 13,3 timer/uke i litt over 13 uker, dvs. ca et fullt månedsverk pr. person i gruppa). I en gruppe som får C har studentene lært det viktigste godt nok. A gis når studentene gjør en større innsats og oppnår resultater som er mye bedre enn forventet. B gis når studentene har gjort en stor innsats (i overkant av forventet) og resultatet blir godt, men ikke eksepsjonelt. En gjennomføring av emnet som ikke møter kriteriene for C vil gi prosjektgruppen karakteren D, E eller F, avhengig av hvor store avvikene er. F gis når vi ikke ser noen synlige spor av at de har fulgt emnet i de besvarelsene studentenes har levert. E viser slike spor, men er minimumskravet for å bestå emnet. Her er det viktige ting som studentene ikke har lært eller har misforstått. D brukes når studentene har lagt liten innsats i emnet og kommet kortere enn forventet, og gjort så lite at resultatet blir dårligere enn forventet. Krav til prosjektarbeidet kar mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyp) testing & evaluering helhet A Tema /område

er klart def., presisert til spørsmål med målgruppe og eval.krit. Gruppa har utnyttet egen kunnskap og interesser

Gruppa har gjennomført godt undersøkelser og brukt flere metoder. Metodevalget er godt begrunnet. Metodene er godt beskrevet (både gjennomføring og innsamlede data) og dataene er grundig presentert. Gruppa har observert / intervjuet flere brukere enn nødvendig. Gruppa har etablert samarbeid med en brukergruppe.

Dataene er analysert på en solid måte og det er identifisert behov og ønsker som begrunnes i bruks-situasjonen. Funn begrunnes og det argumenteres solid for funn. Gruppa bruker flere begreper fra (flere av) gjesteforelesnin-gene (HumSam), og det er argumentert for at og hvordan begrepene har bidratt til å forstå og forklare analysen av dataene. Ekstra litteratur er trukket inn.

Flere ideer er jobbet fram, og finnes i flere skisser. Sluttproduktet representerer en visjon som gruppa kan argumen-tere for basert på innsikt både fra bruk og teknologi. Løsningen er ny i brukssituasjonen og utnytter teknologiens muligheter. Den kommuniserer visjonen gjennom materialer, funksjon og form. Skisser og prototyper demon-strerer hvordan visjonen har ut-viklet seg iterativt og gjennom brukerdialog og brukertesting. Prototypevalg er godt begrunnet. Minst to forskjellige visjoner har vært vurdert og testet.

Løsningsforslag er testet (at det virker) og evaluert. Brukere har vært involvert i flere evaluerin-ger og gruppa har gjennomført flere iterasjoner med (re)design, bruker-dialog og -testing. DECIDE-rammeverket er brukt som mal for evalueringen, og egne evalueringskriterier er diskutert opp mot DECIDE. Minst to forskjellige visjoner har vært vurdert og testet. Gruppa har forkastet egne ideer etter brukerevaluering.

Nyskapende prosjekt der gruppa har tenkt ”ut av boksen”. Gruppa har samarbeidet godt og alle har lært om alle sidene i prosjektet.

Tone

Bra

ttete

ig –

26/

3 20

12

til eksamen��evaluering av prosjekt

¤  mål





¤  helhet




- egen kompetanse ses som ressurser

- klart definert tema

- målgruppe definert

- evalueringskriterier presisert

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- flere metoder for undersøkelser av bruk

- godt utvalg og argumentasjon for metodene

- god gjennomføring av undersøkelsene

- god dokumentasjon av undersøkelsene

- god dokumentasjon av data

- gode begrunnelser for avslutning av data-

innsamling

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- solid analyse av data

- analysen konkluderer med behov (som

lar seg underbygge av dataene)

- solide begrunnelser av funn og konklusjoner

- bruk av flere begreper og referanser fra gjeste-

forelesninger og annet fagstoff

- demonstrerer at begrepene gir bedre forståelse

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- flere ideer er jobbet fram, dokumentert i skisser

- flere av mellomproduktene er dokumentert

- prototypevalg er godt begrunnet

- sluttproduktet representerer en visjon som

er forankret i gruppas undersøkelser (bruk)

og som utnytter Arduino på en god måte

- minst 2 visjoner er beholdt lenge i prosessen

- brukerne har deltatt i designprosessen

- materialer og form kommuniserer visjonen

- feedback til brukerne er gjennomtenkt & -prøvd

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- løsningsforslaget er testet godt (både

verifisering og validering)

- DECIDE-rammeverket brukt (eller

gode argumenter for å gjøre noe annet)

- flere iterasjoner med design & test har

vært gjennomført

- brukere har vært involvert i testingen

- 2 visjoner har vært evaluert, en forkastet

- gruppa har forkastet egne ideer etter

bruker-testing

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- nyskapende prosjekt (tenkt “ut av boksen”)

- godt samarbeid

- gruppa har modnet

- prosjektet framstår som en logisk helhet

- alle har lært noe om alt (alle har bidratt)

Tone

Bra

ttete

ig –

26/

3 20

12

INF1510: Obligatorisk oppgave 3: evaluering av gruppearbeidet

Denne oppgaven gjøres i Øvingsgruppene i uke 15: 10-13. april). Prosjektarbeidet i inf1510 er godt i gang, og dere er omtrent halvveis i prosjektet. Det er ca. syv uker igjen til prosjektet skal avsluttes og dere skal levere eksamensoppgavene. Denne obligatoriske oppgaven skal være en vurdering av om gruppa jobber bra sammen slik at dere unngår å bruke mye tid og krefter på å få samarbeidet til å fungere videre i prosjektarbeidet. En viktig grunn til å diskutere gruppearbeidet nå er at det fremdeles er tid til å gjøre noe med det i grupper som ikke fungerer optimalt, slik at organi-seringen av arbeidet og arbeidsformene i den siste delen av prosjektet blir effektive. Hvis arbeidsfordel-ingen er skjev kan den endres, hvis rollene ikke fungerer kan de omfordeles. Denne øvelsen skal bidra til dette. Hvis noen i gruppa bidrar uforholdsmessig lite i forhold til de andre, kan gruppa stille krav til personen om å yte mer samt planlegge og sette en frist for leveranser. Studenter som ikke bidrar nok til gruppas arbeid kan bli bedt om å trekke seg fra gruppa, men dette kan og bør ikke skje uten at dere har tatt en grundig diskusjon med personen om avtaler og forventninger, i tillegg til at personen må få en sjanse til å forbedre seg. Trekk inn gruppelæreren i diskusjonen hvis deres gruppe er i en slik situasjon. Oppgave: Ta fram igjen oppstart-øvelsen fra uke 9 og 10, og se på Oblig 2, der dere skrev ned dere ble enige om. Da skulle dere bli kjent med hverandre og diskuterte bl.a. ambisjoner, interesserer, tidsbruk mm. Dere ble enige om følgende:

• møtetidspunkt i tillegg til de oppsatte timene i kurset (Øvingsgruppetimene) • roller i prosjektet, faste eller på omgang • arbeidsoppgaver og -ansvar: hvem skal gjøre hva til neste gang (se beslutningsreferat) • arbeidsområde eller deling av dokumenter • kjøreregler for prosjektgruppa

o man sier fra om man blir sen til et møte (hvor mye før?) o hva skjer om man ikke kommer på et møte? o hva skjer om man ikke har gjort det man skal? (hva ble dere enige om da?) o når blir slike ting et problem? o kan man kaste ut en som ikke gjør nok?

1) Individuell oppgave (15 minutter): Gå gjennom oppstart-øvelsen (dvs spørsmålene over) og gjør dine egne vurderinger. Tenk også over: Fungerer gruppa bra? Fungerer den slik dere bestemte at dere skulle jobbe? Hvis ikke: hvorfor ikke? Hva kan forbedres? Og hvordan (kom med forslag du tror vil bedre situasjonen)? Svar i tillegg helt konkret på følgende spørsmål:

1. hvor mange timer pr uke bruker du på kurset (i gjennomsnitt)? 2. hvor mange timer brukte du i forrige uke? 3. hvilke deler av resultatet har du bidratt med og bidratt til helt konkret? 4. gjenkjenner du ditt bidrag i gruppas resultater? 5. hvor stor er din del og er du fornøyd med den? 6. hvordan opplever du at arbeidsoppgavene er fordelt? Har alle fått like stor andel i prosjektet?

Hvis nei: hvorfor ikke?

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- god framstilling: klar, logisk struktur & godt språk

- alle punktene ovenfor er

- godt dokumentert

- godt argumentert for

- gruppa viser selvstendig vurdering av

eget arbeid (kritisk: både + og -)

- relevante faglige referanser

Tone

Bra

ttete

ig –

26/

3 20

12


¤  mål





¤  helhet




- demonstrerer at og hvordan

løsningsforslaget virker

- presenterer visjonen

- presenterer funksjon, form og materialer

- en god fortelling

- utnytter Arduino godt

- en god “pitch” der alle i gruppa er med

Tone

Bra

ttete

ig –

26/

3 20

12


!"#$%$&'()*+"',&$,'

Innlevering nr. 3 skal dokumentere og presentere at hvert enkelt gruppemedlem har lært det hun/han skal og har bidratt i prosjektet.

Bestått NB tilsv. C

Alle skal fortelle hva de har bidratt med i prosjektet og hva de har lært av dette. Prosjektaktivitet Har bidrag Hva er ditt bidrag Hva har du lært Mål - spørsmål Undersøkelse Analyse Design - Ideer - Skisser - Prototyper (prog)

Test - evaluering Framdrift i prosjektet Rapportskriving (felles) Gruppearbeidet

NB Alle elementene må fylles ut. I tillegg skal studentene skrive en kort rapport som inneholder: 1) hva likte du best i prosjektet (hvilke aktiviteter, hva gjorde du og hva var det du likte med det?) 2) hva var problematisk i prosjektet, hvorfor og hvordan. Hvordan ble problemene løst? 3) hva lærte du mest av i prosjektet? Hva lærte du minst av? Hva er læringsutbyttet av prosjektet som helhet? 4) hvordan vurderer du prosjektet og din egen innsats?

Ikke bestått En av radene er ikke fylt ut, dvs at denne studenten ikke har bidratt til prosjektet på dette området. Det kan bety at gruppa har fordelt arbeidet skjevt eller at vedkommende ikke har deltatt like mye som de andre. Uansett grunn vil dette kvalifisere til ikke bestått. Intet eller lite læringsutbytte av emnet, dvs at rapporten viser at studentens læringsutbytte av emnet tilsvarer en D eller E (se under prosjekt / prosjektrapport).

Den individuelle rapporten skal være på inntil 5 sider, og ses i sammenheng med sluttrapporten (som er lest før de individuelle rapportene). Den første siden er et skjema tilsvarende det som står i tabellen ovenfor. De andre sidene kan utdype det som ikke får plass i tabellen + svare på de fire punktene ovenfor. Det er viktig at alle har et bidrag inn i alle prosjekt-delene, og at alle bruker litt tid i etterkant av prosjektet for å reflektere over sine egne erfaringer og sin individuelle læring. Hver enkelt skal vurdere prosjektet, både prosessen og produktet, og i tillegg vurdere sin egen innsats i prosjektet. Hva har hver enkelt lært av prosessen?


- arbeidet: vurder oppdeling, fordeling, roller – tiltak?

- resultatet: vurder gruppas og ditt bidrag, argumenter

- hva lærte du i prosjektet? Hva tar du med til neste gang?

Tone

Bra

ttete

ig –

26/

3 20

12

inf 1510: evaluering

¤  hva er evaluering?

¤  begreper og tilnærminger

¤  metoder og modeller

¤  underveis i undersøkelses- og analyse-aktiviteter

¤  underveis i design

¤  som egen aktivitet

¤  evaluering av læringsresultater

Documents

inf 1510: evaluering...I'll present my newest usability guidelines in the tutorial on Fundamental Guidelines for Web Usability at the Usability Week 2009 conference in Las Vegas and