Technical Design Document 2

This document has been superceded by the more recent version:

http://docs.google.com/Present?docid=dcwg9z28_376dsvwhwmc

Summary

The design of the modelling4all rich internet application (RIA) uses three guiding heuristics:

  1. Make it as easy as possible to embed the service into other web services e.g. by pasting URLs and html 'badges'
  2. Make it as easy as possible for developers to create 'mashup' websites that utilise APIs to the modelling4all service, and other services
  3. Minimise the requirement to police users (e.g. long term costs)

Taking this approach will allow the project team to focus on the building the core of the system, namely constructing and experimenting with computer models. This approach seems to be the most sustainable in considering the state of internet technologies today.

Explore

Functionality

User interface

Construct

Functionality

User interface

Experiment

  • Build a RIA without account management, that functions much like a wiki in that anyone can create a unique URL that pertains to their model
  • The URL would be encoded so that it is not easy to derive (e.g. contain GUIDs).
  • There will be version control on the resource.
  • The design of the RIA will make it as easy as possible to 'embed' within other user agents such as social networks (facebook, orkut), VLEs (SAKAI, LAMS), assessment engines and survey tools, web pages (especially online journal articles and news reports, wikis, discussion forums, tagging (delicious, reddit) and chat clients.
  • The database will be designed to make it as easy as possible to create mashup websites based through calling API methods
  • Utilise an indexing/ search service to catalogue models and microbehaviours, and make it easy to find them whether they be within the modelling4all service or other internet pages
  • With respect to microbehaviours (MBs) then we envisage allowing modellers to be able to publish MBs and models within their own web tools e.g. blog, and make these discoverable through using an HTML tag that the modelling4all service can recognise and import into the 'staging' area.

Questions:

  • Should the site include any user generated content e.g. metadata, tagging, forum posts, endorsements, ratings etc. This would increase the risk of innappropriate content being put on a site.
  • Branding, modelling4all is a project name but not necessarily a good name for the service

Notes on another set of approaches:

  1. Create a standalone application that is just a filestore (no tagging, forum, wiki or account management)
  2. Create a 'gadget' or 'widget' that can be embedded in user agents such as SAKAI, LAMS, Facebook, iGoogle and other social networking sites (that offer tagging, wiki, forum and account management/ permissions)
  3. Utilise an open source social networking tool and add the application so in effect host a managed service

Idea 1

Provide just the ability for any user to explore, construct and experiment. There would be no login, each model would exist as a unique URL with a random element (URL based security as in temporary file transfer tools). Individual users would get to the site via URL, and paste URLs back into discussion tools within the environment of their/ their teachers choice e.g. VLE/ Social Networking site. Main trouble with this approach is the lack of account management which could expose the site to hacks and reduce likelihood that a community grows around the tool. It would be very similar to the openly available scrabble tool:
http://www.scrabulous.com/solitaire_scrabulous.php apart from this has no repository or export functionality.

This is also like: http://jottit.com/

Idea 2

This would be the idea way of allowing teachers and student to choose the tools they want to use to discuss models and modelling. Candidate user agents would include SAKAI, Facebook, Moodle, and Orkut. The trouble with this approach is it not being easy to create the tool as a widget or gadget that will work in a wide variety of these social networks platforms. Also it is likely that we would not be able to create mashups based on the models as the platform would lock the data. This approach would require support from the platform developers.

Idea 3

Utilise an open source platform to create a standalone complete service e.g.

http://www.boonex.com/products/dolphin/
http://noserub.com/

The trouble with this approach is the high cost of development and hosting over the long term. It is likely that teachers and students are already 'tied' to existing toolsets for communicating. Also there is still the requirement on the database to support an API for 3rd party querying ('mashup'). This approach would require support from the development community.

Idea 4

Related to Idea 1 but use Shibboleth or OpenID to do account management.

Phased approach

These approaches to not need to be exclusive as all are possible, the trick is to develop the software in the right order so that it does not exclude options unnecessarily. A phased approach works something like:

Phase 1

  • Develop Construct and Run aspects of the RIA
  • CRUD of models and microbehaviours within database

Phase 2

  • Develop Explore functionality
  • Indexing and search of pages
  • Tagging and search for tags

Phase 3

  • Online discussion tools relating to models e.g. forum, blog, chat, wiki

Phase 4

  • API development
  • Transposable HTML that can be embedded in a user agent ('badges')
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License