1 / 17

AtGentive WP2 Design Principles AtGentive; 2 nd General Meeting; 21-22 May 2006, Oxford, UK

AtGentive WP2 Design Principles AtGentive; 2 nd 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/. Table of content:. The Wish list. Flexible architecture

clara
Download Presentation

AtGentive WP2 Design Principles AtGentive; 2 nd General Meeting; 21-22 May 2006, Oxford, UK

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. AtGentiveWP2 Design PrinciplesAtGentive; 2nd General Meeting; 21-22 May 2006, Oxford, UK Thierry Nabeth, Yé Deng & Pradeep Kumar Mittal INSEAD CALT (Centre for AdvancedLearning 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

More Related