1 / 9

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

This article discusses the distinction between application-led research and application development in the field of ubiquitous computing. It emphasizes the need to obtain requirements from external sources, promote community self-regulation, and facilitate the reuse of components and concepts. The article also suggests the importance of sharing application experiences, domain knowledge, and test data, as well as developing metrics and benchmarks for evaluating applications and middleware. The text language is English.

josejacobs
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • statement:”you can’t have ubicomp without deployment – that’s 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 Brewery’s “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.

More Related