WP2: Design principles;

1
AtGentiveWP2 Design PrinciplesAtGentive 2nd
General Meeting 21-22 May 2006, Oxford, UK

• Thierry Nabeth, Yé Deng Pradeep Kumar Mittal
• INSEAD CALT (Centre for Advanced Learning
  Technologies)
• http//www.calt.insead.edu/

2
Table of content

• The Wish list.
• Flexible architecture
• The Web 2.0 principles
• Adaptation / adoption in the AtGentive design
• How to proceed

3
The Wish list

• The have to and nice to have

4
What we want

• Modularity, flexibility, simplicity. We want to
  focus our attention on improving the support for
  attention, not on solving technical problems.
• Possibility to reuse the work into individual
  applications (all the partners and not only the
  partners involved in the platforms- should be
  able to take advantage of the output after the
  end of the project)
• Reduce the dependence between the partners (we
  have different agenda, priorities, styles, ).

5
What we want (2)

• We want to work on things that make sense to us
  personally, and that we believe are useful. We
  would like to be the users of the tools and
  approaches that we develop.
• We want to design innovative things that have
  high added value.
• We want (and we need) that our deliverables are
  accepted by the EC

6
The flexible architecture

• The Web 2.0 principles
• Adopting web 2.0.

7
The Web 2.0 principles

• Principles
• Rich user experience User participation trust
  the users (Wikipedia) radical decentralisation
  (blog) emergence more people use them the it is
  useful fun to use attitude culture (community,
  versus process oriented, corporate and
  bureaucratic) navigation serendipity.
• Approaches.
• Small pieces loosely joined Mashup
  (combination) perpetual beta granular
  addressability of content tagging (not taxonomy.
  Folksonomies are not planned in advance) ideas
  originates from the leisure Internet.

8
Ye Deng Presentation of Web 2.0

• Presentation Web 2.0
• Any Question?

9
Web 2.0 The technical aspects

• The technicality of Web 2.0.
• A Different architecture. More distributed,
  loosely coupled, bottom-up, accessing external
  components.
• New technical mechanisms (web services, plugins,
  Ajax) and approaches (trackback, )
• Rich client (Dhtml/Ajax, flash, )

10
The Adoption / adaptation to Atgentive

• Components. Components are independent, simple,
  and have a very clear interface (web services,
  rich-client / server)
• Open Application / platform. Net API, plugin
  mechanisms.
• Open to external services. Instant messaging
  (Skype?, MSN), Tagging (Del.icio.us, Flickr),
  bloging, maps
• eXtreme Programming principles. Bottom-up, user
  centred, continuous improvement

11
Web 2.0 The issues

• The issues related to Adopting Web 2.0.
• Need to open the architecture. Additional layer.
  Services exposed via a clear Interface (API,
  plugins). This interface exists for both the
  applications platforms, and the components.
  What should be this interface? Can we express
  everything (complex things?).
• More distributed architecture. We can not really
  assume what it will be used for. Feeling of lost
  of control.
• More complex clients (Dhtml/Ajax, flash, )
• Bottom-up / user-centred / incremental
  continuous improvement (release often). Perpetual
  Beta.

12
Adoption / adaptation to AtGentive

• What is web 2.0 for us?
• How can we adopt web 2.0 principles

13
The Adoption / adaptation to Argentive

• Open Application / platform. The different
  platforms (ICDT, Ontdeknet, others?) should be
  opened (API / web services, plugin mechanisms).
  Ideas introduced by Claudia. We have to find some
  way to easily combine/glue the components
  (mashup).Note Probably some commonalities, but
  most probably this work will be platform
  specific.
• External Components. External components will
  have to be selected and wrapped. Examples
  Instant messaging (Skype?, MSN), Tagging
  (Del.icio.us, Flickr), blogging, etc..Work Some
  rich client interfaces will have to be created.
• Specific AtGentive Components. Difference
  specific AtGentive components will have to be
  created. Work Creation of small server
  components (exposed via web services, or
  incorporable into plugins) Rich client part.

14
The artificial Characters ?

• The character should be considered as a rich
  client
• A server component for piloting this client will
  probably have to be designed. (suggestion this
  server will be piloted via a high level API
  accessed via simple web services?)

15
How to proceed conclusion
16
How to proceed

• Identification of the components. Specification
  of the functional specification according to a
  user centred perspective (Not a detailled
  technical description !). Alignment of these
  components to the Conceptual framework.
• Definition of the technical framework.
  Clarification of the different mechanisms and
  approaches to be used. Plugin, API,
  etc.Definition of a common API. (not too
  detailed, with the objective is to sketch the
  principles, and be ready for easy later
  additions)
• Architectural definition of the AtGentive
  Components. Definition of the server part and of
  the Rich client part.

17
Conclusion

• Key Challenges
• Alignment with the conceptual framework, and
  guidance of this framwork
• Generate something useful, innovative and of high
  added value