Proof-of-Concept Demonstrators and Other Evils of Application-Led Research

1
Proof-of-Concept Demonstrators and Other Evils of
Application-Led Research
Nigel Davies
2
background
most collaborative tools for mobile workers
Guide building the hitch-hikers guide to the
galaxy
e-Campus networks of pervasive public displays
3
deployment

• statementyou cant have ubicomp without
  deployment thats the ubiquitous bit in
  ubiquitous computing ?

4
a position statement

• clarify the distinction between application-led
  research and application development.
• can you get your requirements from elsewhere ?
• stop too many people from developing
  applications.
• community self-regulation.
• stop people from developing applications from
  scratch.
• make components/concepts easier to use.
• develop metrics and benchmarks for (a) evaluating
  applications and (b) evaluating middleware.
• enable comparisons and evaluations.

5
and then
6
the Brewery Arts Centre

• two weeks of events themed around the 1940s
• our focus was Evidence
• test case for early e-Campus technologies
• designed to make sure we start to understand
  practical issues of developing and deploying
  e-Campus systems
• this week and last week are the Brewerys
  Forties Fortnight

7
evidence

• content is coming from
• the video diary system
• digitised interviews with local residents
• digitised old film footage
• images (art) created using the Kirlian table
  developed by .the pooch.

8
deployment
9
a position statement

• clarify the distinction between application-led
  research and application development.
• can you get your requirements from elsewhere ?
• clarify the distinction between applications
  development for requirements capture/domain
  knowledge, inspiration and application
  development for evaluation (proof!).
• stop too many people from developing
  applications.
• community self-regulation.
• stop people developing applications for the
  wrong reasons.
• stop people from developing applications from
  scratch.
• make components/concepts easier to use
• share application experiences, domain knowledge
  (often done through seminars can we do this
  through papers) and test data
• develop metrics and benchmarks for (a) evaluating
  applications and (b) evaluating middleware.
• enable comparisons and evaluations.
• can we generate these from applications
  standard problems.