Confirmed users
70
edits
Education/Projects/JetpackForLearning/Profiles/MUPPLE: Difference between revisions
Jump to navigation
Jump to search
Education/Projects/JetpackForLearning/Profiles/MUPPLE (view source)
Revision as of 03:30, 1 February 2010
, 1 February 2010→Technical Notes & Further Work
| Line 119: | Line 119: | ||
We adapted some cross-site scripting style strategies in order to achieve a tight coordination between Jetpack and the code in the slidebar; therefore we use a hidden iframe (fed with data URIs) to communicate from the slidebat to jetpack (which listens for the load event), while from jetpack to slidebar or to any tab we inject script tags with raw code or JSONP. | We adapted some cross-site scripting style strategies in order to achieve a tight coordination between Jetpack and the code in the slidebar; therefore we use a hidden iframe (fed with data URIs) to communicate from the slidebat to jetpack (which listens for the load event), while from jetpack to slidebar or to any tab we inject script tags with raw code or JSONP. | ||
We use the Jetpack storage in a particular way: we store a large part of the slidebar's DOM tree into the store instead of individual objects | We use the Jetpack storage in a particular way: we store a large part of the slidebar's DOM tree into the store instead of individual objects. | ||
Since the slidebar is also the Model, we need to store things there which should not be revealed to the user (such as IDs, URIs, types). For this prototype we chose to use RDFa annotations. We will investigate if HTML5 microdata would bring us more benefits; we're also thinking of the possibility of creating a workflow microformat. | The concept is that the slidebar it is not a mere View (as in MVC) of a Model, but the Model itself, directly manipulable. If someone drags and reorder some actions (DOM elements) there is no need for propagating those changes to an underlying granular database, no need to determine which individual records have to be updated in a consistent manner. | ||
This approach was inspired by the [[http://en.wikipedia.org/wiki/Naked_objects Naked Objects pattern]]. | |||
Since the slidebar is also the Model, we need to store things there which should not be revealed to the user (such as IDs, URIs, types). For this prototype we chose to use RDFa annotations. | |||
We will investigate if HTML5 microdata would bring us more benefits; we're also thinking of the possibility of creating a workflow microformat. | |||
Having such a Model+View combo would allow for a very simple sharing strategy: you could just select and copy a workflow from the slidebar, and paste it in a blog post - all the underlying data would be just propagated and MUPPLE could just recognise in any web page published workflows and prompt the user to import them at will. | Having such a Model+View combo would allow for a very simple sharing strategy: you could just select and copy a workflow from the slidebar, and paste it in a blog post - all the underlying data would be just propagated and MUPPLE could just recognise in any web page published workflows and prompt the user to import them at will. | ||
Having RDFa annotations also allows us to serialise the Model to RDF and it would be possible to publish a workflow via a public RDF store (like the [[http://www.talis.com/platform/ Talis Platform]]), this would allow MUPPLE to look-up existing workflows involving a site the user is browsing. And what we believe that is more important in collaboration: it may allow an user to discover friends and co-workers workflows - this would be achievable by publishing workflows with a [[http://xmlns.com/foaf/spec/#term_maker foaf:maker]] relation, and the user's foaf profile could point to friends, organisations (hence co-workers). If the user lacks an explicit foaf profile, we could use one based on his Twitter relations: http://semantictweet.com | Having RDFa annotations also allows us to serialise the Model to RDF and it would be possible to publish a workflow via a public RDF store (like the [[http://www.talis.com/platform/ Talis Platform]]), this would allow MUPPLE to look-up existing workflows involving a site the user is browsing. | ||
And what we believe that is more important in collaboration: it may allow an user to discover friends and co-workers workflows - this would be achievable by publishing workflows with a [[http://xmlns.com/foaf/spec/#term_maker foaf:maker]] relation, and the user's foaf profile could point to friends, organisations (hence co-workers). (If the user lacks an explicit foaf profile, we could use one based on his Twitter relations: http://semantictweet.com ) | |||
We consider each recordable action as an annotation, and we would like to have them compatible/interoperable at some level with [[http://www.openannotation.org/ Open Annotation]] initiative. We already use [[http://xpointerlib.mozdev.org/ xpointerlib]] for 'note actions' which would allow us to create [[http://www.w3.org/2001/Annotea/ Annotea-like]] annotations and be interoperable with Open Annotation. | We consider each recordable action as an annotation, and we would like to have them compatible/interoperable at some level with [[http://www.openannotation.org/ Open Annotation]] initiative. We already use [[http://xpointerlib.mozdev.org/ xpointerlib]] for ''note actions'' which would allow us to create [[http://www.w3.org/2001/Annotea/ Annotea-like]] annotations and be interoperable with Open Annotation. | ||
Xpointerlib proved quite useful in prototyping [[http://gridinoc.name/blog/2009/10/ubiquity-history/ recording]] and [[http://gridinoc.name/blog/2009/10/sharing-ubiquity-commands/ sharing]] of Ubiquity commands; having them as recordable actions in MUPPLE could enable the creation of workflows based on an 'open market' of Ubiquity commands and provide by this a straight forward way in extending MUPPLE functionality. | Xpointerlib proved quite useful in prototyping [[http://gridinoc.name/blog/2009/10/ubiquity-history/ recording]] and [[http://gridinoc.name/blog/2009/10/sharing-ubiquity-commands/ sharing]] of Ubiquity commands; having them as recordable actions in MUPPLE could enable the creation of workflows based on an ''open market'' of Ubiquity commands and provide by this a straight forward way in extending MUPPLE functionality. | ||
Moreover, think of the possibilities that the sole command 'translate' from Ubiquity could bring to MUPPLE: collaboration that spans language barriers | Moreover, think of the possibilities that the sole command ''translate'' from Ubiquity could bring to MUPPLE: '''collaboration that spans language barriers'''. | ||
A 'reboot' of MUPPLE II is required, and we plan to do it in February. After learning how to fly a Jetpack we can now focus on core functionality and code clarity. | A ''reboot'' of MUPPLE II is required, and we plan to do it in February. After learning how to fly a Jetpack we can now focus on core functionality and code clarity. | ||
=Original Proposal= | =Original Proposal= | ||
The initial [[vision MUPPLE II|vision of the MUPPLE II]] Firefox Jetpack talks more about the motivation and introduces a use case to write collaboratively a paper using Web 2.0 webpages. | The initial [[vision MUPPLE II|vision of the MUPPLE II]] Firefox Jetpack talks more about the motivation and introduces a use case to write collaboratively a paper using Web 2.0 webpages. | ||