Interesting comments from John Thackara who chaired a seminar in London (Late 2002), organised by the Design Council, which brought together 100 academics, designers and business people to discuss: "how to get the most out of academic design knowledge".

• framing the initial question - on the basis that questions are more powerful than answers;

• assembling the actors - with an emphasis on the inclusion of people formerly known as users;

• obtaining resources - the process of designing and drafting project proposals, setting up projects, and co-coordinating them, is complex and very time-consuming;

• co-ordination and facilitation - the Sloan Business School's Centre for Co-ordination Science (sic) reckons that coordination should be allocated 30% of time and money resources in many projects - but never is;

• sharing results - will never happen if left to the end of the project.

  If I reflect, after the meeting, on success factors for design research, four of these stood out for me:

• locate at least part of the project in a real-world context. I heard no convincing examples of purely theoretical design research.

• Design research should involve the innovative re-combination of actors among the worlds of science, government, business, and education.

• If the results (and value) of design research are to be shared effectively, communication and dissemination methods need to be designed (and budgeted) in at the start.

• there's an urgent (and so far not visible) need to develop peer-to-peer methods for research and investigations.

  The list of barriers to the effectiveness of design research to emerge from the meeting was longer:

• limits of design knowledge; its epistemology (C Frayling);

• difficult to capture/represent - and thus share - a process;

  (processes are often tacit and social, not objective);

• divergent ways of working (WoW);

• inadequate access to, or knowledge of, who is doing what;

• impoverished stores, or more properly flows, of knowledge and experience

• IPR/ownership issues stifle sharing;

• institutional constraints (professional associations, disciplinary divisions);

• funding bodies are too slow, too mono-disciplinary;

• lack of ways to measure effectiveness (Jamie Oliver story)

1:33:53 PM    

Gene at Fredshouse.net- reflecting on Rem Koolhaas / IDEO's Prada disappointments - does some expectation-setting around deploying tech beyond the desktop: "I'm not surprised that Prada's experience has been less than delightful. We did some large-scale demo systems and real-world user experiments in cooltown, and we discovered some serious challenges in deploying even relatively simple ubiquitous computing technologies.

...what seems straightforward to build and run in the lab, is an order of magnitude harder to make work in the world. Using wireless LAN? Count on interference. Using infrared? Count on sunlight and heat sources. Using RFID? Count on damaged tags and misreads. Using PDAs? Count on dead batteries, lost styli, frequent crashes, both the soft and hard (floor) kind. Oh, and everything will be obsolete or broken in a year or two, so count on plenty of ongoing support to keep things fresh and fun....

Ubicomp is hard, understanding people, context, and the world is hard, getting computers to handle everyday situations is hard, and expectations are set way too high. I used to say ubicomp was a ten-year problem; now I'm starting to think that it's really a hundred-year problem." [Via Matt Jones]
11:58:52 AM    

Context Broker Architecture (CoBrA) is an agent based architecture for supporting context-aware systems in smart spaces (e.g., intelligent meeting rooms, smart homes, and smart vehicles). Central to this architecture is an intelligent agent called context broker that maintains a shared model of context on the behalf of a community of agents, services, and devices in the space and provides privacy protections for the users in the space by enforcing the policy rules that they define.

• CoBrA uses the Web Ontology Language OWL, a W3C Semantic Web standard, to define ontologies of context (people, agents, devices, events, time, space, etc.). In other systems, context is often implemented as programming language objects (e.g., Java classes), lacking the expressive power to support context reasoning and high-level knowledge sharing.
• CoBrA provides a resource-rich context broker to maintain a shared model of context for all computing entities in an associated space. In other systems, individual entities are usually required to manage their own contextual knowledge.
• CoBrA allows the users to define privacy policy to control the sharing and the use of their situational information (e.g., where they are, who they are with, what they are doing). In other systems, the computing entities are usually free to share any acquired situational information of a user.

Figure 1 shows an overview architecture diagram of CoBrA. For more information, please see the documents listed in the paper section.

10:38:12 AM