In-Class Notes

[Jesse Cirimele]

(test-run on sending out in class notes)

Scott's Intro:

two papers:
1) how can we design for ubiquitous computing
2) how can we design ubiquitous computing for the web?

building ubiquitous systems was enormously difficult

key fieldwork results:
- presentation prototypes (just visuals), functionality not on
prototypes until late in the game
- video recording very valuable to have, but dealing with video is
very hard (production costs too much)

(question: how do you make video editing 1/10 the cost that it is now?)

(dtools example videos)
(dtools walkthrough)


low-entry, high-ceiling is really hard. we currently often glue two
different systems together, but can we do something to better
transistion between low-entry and high-ceiling?

evaluation of dtools:
1) rebuild existing prototypes with the new system and prototype new systems
2) run first lab study
- most of time to complete prototypes was in building the foam-core models
3) deployment in interaction design studio class

related work design side: arduino, istuff, phidgets, calder,
related work evaluation side: suede (2000), i-observe (1995), eva (1989)

later work: exemplar, d.stix, mash-ups

how long did this take? 5 man-years
how many publications? 1-4, but much more impact because opensource
could there be value outside of experimental build and test A vs B?
yes, sometimes called design research, trying to figure out importance
of all the tiny decisions that designers make

--------------------------------------------------------------------------------

discussion ( sameer, matt ):
testing methods: compare to precision, realism, generalizability
(breakout for small group discussion on talking about dtools experiment)
group comments:
-generalizability seems to be high for tools like video analysis, but
at the same time it seems like only one path down a wide space.
Comments - good that they took the low hanging fruit, but attacking
that nobody had looked at his demographic.

Q - what's the line between designer and programmer?
Comments
- yes it's clipping your wings, but maybe that's acceptable

Q - is something naturally better because it's a visual language?
comments
- tools become very specialized
- specific groups do very different work, cross group generalization
is difficult
- are we bashing a fork for not being like a knife?
- scratch: remixing as an example of generalization
- are visual languages always better? hard to do visual programming
after doing text for many years
- representation is important
- designers still aren't as good as engineerings at engineering tasks
- example: professor many years ago needed a secretary and had a
design firm to make their presentation slides. maybe this makes their
slides worse, but they can do it themselves.
- don't want the designers to _have_ to become the engineers
- example: design firm says lazer printer and printing restaurant
menus with fonts will be the "end of good design"

Q -
- use the quick mock up as a communication tool between designers and engineers
- paper prototyping the best return on investment, functional took
much more time but served a different purpose. dtools seemed like a
good bridge

Q - did we see transcending of the prototype model or just a
refinement/optimization of the process.
- not a strict optimization. it's a higher fidelity communication
method than paper prototyping. don't optimize the prototyping process
but optimize the communication between the designers and engineers

( second paper )

Q - why use paper? what do you gain by putting paper on the screen?
- why not have computer representation of a post-it?
- media matters, barrier to entry as soon as it's in media. post-its
persist, don't need to be "opened"

Q - what was the paper prototype of the whiteboard?
- did a bunch of wizard of oz systems, put post-its on whiteboards and
had a person be the computer and test out the functionality.