Labscape: A Progress Report

1
Labscape A Progress Report

• FDIS 02

Thanks DARPA, NSF, Intel Research, NIH
2
What I Said in '00

• Breaking down barriers through standard
  representations and experiment capture

3
What I did in '00

• Investigated sensor technologies ?
• Investigated advanced interaction modalities ?
• Studied what biologists do and what they need ?
• 1 out of 3 ain't bad!

4
Key Observation
Abstract, but informal
Physically complex, diverse.
5
Labscape TodayA Ubiquitous Laboratory Assistant

• Giant graph w/ globally unique nodes
• Specialization through inheritance, hierarchy,
  annotation.
• Material, control, and data flow

6
Metrics
First 10 minutes of an experiment
Activity Analysis
Thrash Interleave
0 1 2 3 4 5 6 7 8 9
Minutes
7
Deployment at CSI
8
Research Results

• Design lessons IEEE Pervasive, 9/02
• Systems Issues Pervasive02
• Evaluation Consolvo, Ubicomp02
• H.S. Education application

9
Design Lesson UI before AI

• Take 1 summer 00
• Sensor driven
• Plan recognition
• Emphasize flexibility

• summer 02
• Flexibility
• Usability
• Proactivity (w/ Asst. Cog.)

Flexibility

• Take 2 summer 01
• UI driven
• Plan representation
• Distributed/Robust/Reliable

Relative Utility
10
Design Lesson Values Matter

• Exploratorium (HP CoolTown)
• Kids and lay people doing science experiments
• Value is in the experience
• Interface became implicit at expense of
  functionality, quality
• UW Immunology Lab (Labscape)
• Professionals doing biology experiments
• Value is in the results
• Interface became explicit (the physical platform
  may disappear!)

11
Design Lesson The Rubicon

• Users should not have to cross the Rubicon. The
  true essence of invisible computing.
• Our design goal 100 task focus. All
  interactions with Labscape result in domain
  benefits to the user.
• Automatic persistence (no explicit file I/O, etc)
• Tolerate disconnection
• Dynamic reconfiguration
• Robust
• Available (like gas, water)
• Responsive
• Distributed

12
System Architecture
Asynchronous communicating components
13
one.world Runtime Env. Grimm

• Change
• Discovery (late binding)
• Asynchrony and notification
• Migration
• Checkpointing
• Composition
• Remote events
• Environments (interposition)
• Sharing
• Tuple Store
• Events over Standard IO

Node A
Node B
environment
Tuple Store
Component collection of event handlers. No
threads (except AWT), open connections, etc.
Environment a padded cell for components
14
Exploiting one.world environments
Client Device B
Server
15
Ubiquitous Access Migration

• Virtual Terminal
• Low latency, low performance
• Easy but inadequate
• Does not support disconnection
• State Migration
• Move all model and some view state
• High latency, high performance
• Easy in principle but fragile
• State Replication
• Low latency, high performance
• Potentially high cost unless we are smart about
  it
• Some is necessary. Hybrid approach will be best
• App developer trade-offs between what and when.
  Not how! We need ocean store!

16
Result

• Stable
• Fast response (all local speeds except DB query)
• Migration strategy evolving. Built-in mechanisms
  not good enough
• Disconnection/standalone OK. May have conflict
  resolution problems, but usually single writer!
• Dynamic reconfiguration yes. Location sensing,
  no.
• Replication works. Multiple users w/ different
  views of same model stay in synch
• Instrument interfaces are a huge problem. Just
  have file system snooper now.
• Seems scalable and evolvable (maintainable)

17
Evaluation

• Goal Do no harm!
• Assess impact on key aspects of user ubiquitous
  computing user experience
• Does it increase interleaving of information
  utilization with physical activity?
• Does it decrease thrashing associated with lack
  of readily available information?
• Does it make new things possible?

18
Characterization PCR
19
Thrash
20
Interleaving
21
Ballard HS Experiment
Concept Integrate Theory and Practice Does it
improve learning? Are requirements different?
22
Student 1

• Staining with EtBr
• Allows pictures to be made of the gels
• Unexpected result?
• Pipetting error
• Thermalcycler busted
• No DNA
• Ran the gel too long

• Staining with EtBr
• Binds to DNA and fluoresces under UV light
• Unexpected result?
• Forgot to load DNA - no bands
• Forgot forward/reverse primers - no bands
• Too short running time - Results not definitive
• Too high DNA concentration - a big bar (smudge)

23
Student 3

• Incubating at 100C - thoroughly breaks the chelex
  so it'll attach onto all DNA cells
• dNTPs I don't know what it stands for
• EtBr used to stain the gel to keep all data on
  the gel

• Incubating at 100C - breaks open the cells to
  release the DNA
• dNTPs This is the most important reagent,
  because it creates all the guanine, thymine, As
  and Cs for the DNA strand
• EtBr - sticks onto the DNA and helps the
  analyzer see the results with UV light

24
Interview

• Less magic
• Less text to read!?
• Better conceptual integration

25
Deployment

• CSI
• Marginal regular use
• Immunex ? Amgen
• User study phase.
• Ballard High (Seattle Public Schools)
• Successful pilot study completed
• Lisa Jenschke, director of educational outreach
  for CSI
• Summer push editing, math/control, usability,
  import/export, etc.

DARPA NSF NIH Intel MSR
26
Dynamic Reconfig Indirection

• First try (java sockets)
• Device proxies make connections to app over
  sockets.
• Proximity system sets up connections
• Fragile, costly
• Second try (one.world)
• Asynchronous messaging w/ indirection through
  late-binding discovery
• Increased latency (minor issue)
• Lost of in-order delivery guarantees (major
  issue)
• Robust, scalable
• System has to provide many delivery options and
  different guarantees. App developer chooses

27
Automatic Persistence

• Fail safe persistence w/ local responsiveness
• Stand alone operation
• Reconnect Synchronization
• Multi-user synchronization
• Key separation of concerns