Embed Size (px)
DESCRIPTION
Our aim is to find a way to build new texts which is fully satisfying for authors/users/active readers and whose structure is clear, i.e. suitable for linguistic computation. These are the main ideas of Novelle.
Citation preview
Introduction Structure Architecture Conclusions
NovelleA collaborative open source writing tool software
Federico Gobbo & Michele Chinosi{federico.gobbo,michele.chinosi}@uninsubria.it
Universita dell’InsubriaVarese, Italy
Introduction Structure Architecture Conclusions
What we learned from hypertexts
The digital revolution and the medium of writing
Since the Web Era (1991), new forms and techniques of writingsemerged, whose structural traits are still unclear, and therole/distinction between authors and readers beging to collapse.
The optimists say: ‘hypertexts realize our postmodern anddecostructionist dream of an ‘opera aperta’ (open work)’.
On the contrary, the pessimists say: ‘authors have lost their powerin this openness’.
Introduction Structure Architecture Conclusions
What we learned from hypertexts
The main ideas behind Novelle
Our aim is to find a way to build new texts which is fully satisfyingfor authors/users/active readers and whose structure is clear, i.e.suitable for linguistic computation. These are the main ideas ofNovelle.
We feel that the problems faced by hypertexts are much more thesames of blogs and wikis. We didn’t want to reinvent the wheel, sowe gave a lot of attention of the known literature, in particular onhypertexts.
Introduction Structure Architecture Conclusions
What we learned from hypertexts
The analysis of terminology on hypertexts
The technical (Cunningham, McCloud) and philosophical (Nelson,Bolter, Landow) description of the known problems faced byhypertexts had helped us to design Novelle. We started fromterminology.
Terms as ‘chapter’, ‘page’ or ‘footnote’ become senseless in thenew texts, or they highly change their meaning. What seems to belost is the relations, the texture underpinning the text itself –etimologically, ‘texture’ and ‘text’ both derive from the late Latinterm textum, coined by the Roman Rhetorician Quintilianus.
Introduction Structure Architecture Conclusions
What we learned from hypertexts
Terms we adopt
Some keywords we found useful for our analysis:
web canvas instead of ‘web page’, much more clear and notdependent from printing, from web comics (McCloud);
lexias, i.e. autonomous units of a hypertext, form hypertexts ineducation (Bolter).
transclusion, i.e. a kind of quotation, but with the ability to followthe evolution of the original document (see later).
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collectionswithout loss of context information.
comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.
typology of links, i.e. how to order links avoiding confusion.
version control, i.e. how to keep track of the history of everydocument.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collectionswithout loss of context information.
comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.
typology of links, i.e. how to order links avoiding confusion.
version control, i.e. how to keep track of the history of everydocument.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collectionswithout loss of context information.
comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.
typology of links, i.e. how to order links avoiding confusion.
version control, i.e. how to keep track of the history of everydocument.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collectionswithout loss of context information.
comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.
typology of links, i.e. how to order links avoiding confusion.
version control, i.e. how to keep track of the history of everydocument.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved.
We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved.
A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved.
The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved
by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.
comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.
typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.
version control is solved by the wiki model of documenthistory, so we keep this solution.
Introduction Structure Architecture Conclusions
Known problems and proposed solutions
The wiki model of document history
creation
a very oldversion
the documenthistory timeline
an old version
the currentversion
the lastversion
a restorean edit
destruction
sandbox
Introduction Structure Architecture Conclusions
Ownership and licencing
The problem of ownership
In order to address the remaining problems, we found that we hadto make a choice for the problem of ownership.
The Blog Way. Blogs follow the annotation model, where a singlelexia is central and the others are comments, sometimes organizedin threads (“write once, read many”). Advantage: suitable for alot of licences.
The Wiki Way. Wikis follow an free-to-edit model, where everylexia is central: no authorship, no signature, no hierarchy (“writemany, read many”). Disadvantage: only GPL-like licences.
Introduction Structure Architecture Conclusions
Ownership and licencing
The problem of ownership
In order to address the remaining problems, we found that we hadto make a choice for the problem of ownership.
The Blog Way. Blogs follow the annotation model, where a singlelexia is central and the others are comments, sometimes organizedin threads (“write once, read many”). Advantage: suitable for alot of licences.
The Wiki Way. Wikis follow an free-to-edit model, where everylexia is central: no authorship, no signature, no hierarchy (“writemany, read many”). Disadvantage: only GPL-like licences.
Introduction Structure Architecture Conclusions
Ownership and licencing
The problem of ownership
In order to address the remaining problems, we found that we hadto make a choice for the problem of ownership.
The Blog Way. Blogs follow the annotation model, where a singlelexia is central and the others are comments, sometimes organizedin threads (“write once, read many”). Advantage: suitable for alot of licences.
The Wiki Way. Wikis follow an free-to-edit model, where everylexia is central: no authorship, no signature, no hierarchy (“writemany, read many”). Disadvantage: only GPL-like licences.
Introduction Structure Architecture Conclusions
Ownership and licencing
Solution: free licencing
We decided to let users/authors free to choose the licence of theirworks, as in case or narrative or creative works ownership is treatedas authorship, even by fellows of free culture (Stallman, Lessig). Inother words, each user owns his own lexias (as blogs).
So, we decided to implement every standard Creative Commons(cc) Licence version 2.0. Consequently, everybody is free tocomment everything, but freedom of everything may be denieddepending on the licence. This have to be chosen on lexia creation.
Introduction Structure Architecture Conclusions
Ownership and licencing
Solution: free licencing
We decided to let users/authors free to choose the licence of theirworks, as in case or narrative or creative works ownership is treatedas authorship, even by fellows of free culture (Stallman, Lessig). Inother words, each user owns his own lexias (as blogs).
So, we decided to implement every standard Creative Commons(cc) Licence version 2.0. Consequently, everybody is free tocomment everything, but freedom of everything may be denieddepending on the licence. This have to be chosen on lexia creation.
Introduction Structure Architecture Conclusions
Ownership and licencing
How to manage editing and create derivative works
creation the documenthistory timeline
an old version
the currentversion
creation of aderivative work
a new document history timeline
Introduction Structure Architecture Conclusions
Ownership and licencing
For people who don’t like pictures
A user may let others edit his work, i.e. no No-Deriv option in theCC licence. If so, he has the right to retain or refuse the attributionafter the edits – for comparison: wikis let only to restoredocuments along history, you can’t “fork contents”; nor blogs.
In this case, a new history timeline start and a derivative link willbe put to mark the derivation from the original work.
Introduction Structure Architecture Conclusions
Ownership and licencing
Transclusion: beyond quotation
the documenthistory timeline
the currentversion
an other document history timeline
a freezed quotation
transclusion
Introduction Structure Architecture Conclusions
Ownership and licencing
Again, for people who don’t like pictures
Every user may comment and quote works by others – max. 10%of the original document may be quoted, as in the Italian Law. Wecall the quoted text transclusion, following Nelson. Unlike thecut-and-paste text, a transclusion retains a link to recall theoriginal context (quotation link), so it never points to out-to-datedata.
Furthermore, a transclusion may let the author/user to be living,i.e. to be kept up-to-date along the history timeline of the originaldocument.
Introduction Structure Architecture Conclusions
Ownership and licencing
An up-to-date transclusion example
the documenthistory timeline
an oldversion
an other document history timeline
an up-to-date quotation
transclusion
the currentversion
Introduction Structure Architecture Conclusions
Ownership and licencing
From transclusion to a typology of links
A quotation link is a special case of the deep links, i.e. every linkthat let users change the context. A web page becomes a view oflexias, where relations/differences/comparison between lexias arerendered visually in a single canvas. The choice of the (CC) licencemay be a guide for the user.
So, we distinguish between shallow links, i.e. links in a single viewof lexias, and deep links, i.e. links that let users change view orcontext.
Finally, links to web materials out of our system will be marked asexternal links.
Introduction Structure Architecture Conclusions
Ownership and licencing
From transclusion to a typology of links
A quotation link is a special case of the deep links, i.e. every linkthat let users change the context. A web page becomes a view oflexias, where relations/differences/comparison between lexias arerendered visually in a single canvas. The choice of the (CC) licencemay be a guide for the user.
So, we distinguish between shallow links, i.e. links in a single viewof lexias, and deep links, i.e. links that let users change view orcontext.
Finally, links to web materials out of our system will be marked asexternal links.
Introduction Structure Architecture Conclusions
Ownership and licencing
From transclusion to a typology of links
A quotation link is a special case of the deep links, i.e. every linkthat let users change the context. A web page becomes a view oflexias, where relations/differences/comparison between lexias arerendered visually in a single canvas. The choice of the (CC) licencemay be a guide for the user.
So, we distinguish between shallow links, i.e. links in a single viewof lexias, and deep links, i.e. links that let users change view orcontext.
Finally, links to web materials out of our system will be marked asexternal links.
Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and webcanvas as views of lexias.
comparing complex alternatives should be solved bytransclusions and the document history model by wikis.
typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.
version control is already solved by wikis.
Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and webcanvas as views of lexias.
comparing complex alternatives should be solved bytransclusions and the document history model by wikis.
typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.
version control is already solved by wikis.
Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and webcanvas as views of lexias.
comparing complex alternatives should be solved bytransclusions and the document history model by wikis.
typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.
version control is already solved by wikis.
Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and webcanvas as views of lexias.
comparing complex alternatives should be solved bytransclusions and the document history model by wikis.
typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.
version control is already solved by wikis.
Introduction Structure Architecture Conclusions
A simple overview
The Architecture of Novelle
This is a basic scheme of Novelle multi-tier architecture
AJAX
Ruby on Rails
RDBMS
XML
DBMS / Filesystem
GUI
Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because wewant to be able to save messages with their meanings.
XML is a W3C standard.
XML lets us extend and connect Novelle with otherapplications.
Storing separately data from their representations lets asystem run more efficiently and quickly.
Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because wewant to be able to save messages with their meanings.
XML is a W3C standard.
XML lets us extend and connect Novelle with otherapplications.
Storing separately data from their representations lets asystem run more efficiently and quickly.
Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because wewant to be able to save messages with their meanings.
XML is a W3C standard.
XML lets us extend and connect Novelle with otherapplications.
Storing separately data from their representations lets asystem run more efficiently and quickly.
Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because wewant to be able to save messages with their meanings.
XML is a W3C standard.
XML lets us extend and connect Novelle with otherapplications.
Storing separately data from their representations lets asystem run more efficiently and quickly.
Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,messages and their meanings.
We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).
None of these solutions let us store efficiently our datastructure.
An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.
Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,messages and their meanings.
We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).
None of these solutions let us store efficiently our datastructure.
An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.
Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,messages and their meanings.
We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).
None of these solutions let us store efficiently our datastructure.
An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.
Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,messages and their meanings.
We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).
None of these solutions let us store efficiently our datastructure.
An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.
Introduction Structure Architecture Conclusions
Why XML for data?
Why RDBMS don’t fit our needs
The commercial solutions we tested haven’t native support forXML data except an emulation layer that maps XML treesinto E-R model to store data into tables, losing most of theexpressive power. These products also introduce a cost forpurchase and use them.
Other free RDBMS, such as the most famous MySQL orPostgreSQL, are compatible with XML data but they alsostore XML trees in a relational schema or map the entire XMLtree as BLOB (Binary Large OBject) storing it in one largetable.
Introduction Structure Architecture Conclusions
Why XML for data?
Why RDBMS don’t fit our needs
The commercial solutions we tested haven’t native support forXML data except an emulation layer that maps XML treesinto E-R model to store data into tables, losing most of theexpressive power. These products also introduce a cost forpurchase and use them.
Other free RDBMS, such as the most famous MySQL orPostgreSQL, are compatible with XML data but they alsostore XML trees in a relational schema or map the entire XMLtree as BLOB (Binary Large OBject) storing it in one largetable.
Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.
While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.
Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.
eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).
Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.
While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.
Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.
eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).
Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.
While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.
Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.
eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).
Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.
While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.
Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.
eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).
Introduction Structure Architecture Conclusions
Why XML for data?
XML Repository in the filesystem
Like most blogs and wikis, we choose to store Novelle XMLrepository on time-based filesystem structure. Our representation isa directory tree that reflects quite well our idea of history.
For every message Novelle stores three XML documents:
The message itself
Its past history
The filesystem directory tree
Introduction Structure Architecture Conclusions
Why XML for data?
XML Repository in the filesystem
Like most blogs and wikis, we choose to store Novelle XMLrepository on time-based filesystem structure. Our representation isa directory tree that reflects quite well our idea of history.For every message Novelle stores three XML documents:
The message itself
Its past history
The filesystem directory tree
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. Inparticular:
gdiff/gpatch creates a patch from two files.
XML Builder offers a set of classes to menage XML files.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. Inparticular:
gdiff/gpatch creates a patch from two files.
XML Builder offers a set of classes to menage XML files.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. Inparticular:
gdiff/gpatch creates a patch from two files.
XML Builder offers a set of classes to menage XML files.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. Inparticular:
gdiff/gpatch creates a patch from two files.
XML Builder offers a set of classes to menage XML files.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails for the document history model
Using gdiff/gpatch we can implement our history model in aneasy way and saving space.
Moving across a history means to retrieve a fixed number ofsubsequent patches.
RoR doesn’t support XML native databases, so we temporarilyuse a RDBMS only for RoR needs.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails for the document history model
Using gdiff/gpatch we can implement our history model in aneasy way and saving space.
Moving across a history means to retrieve a fixed number ofsubsequent patches.
RoR doesn’t support XML native databases, so we temporarilyuse a RDBMS only for RoR needs.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails for the document history model
Using gdiff/gpatch we can implement our history model in aneasy way and saving space.
Moving across a history means to retrieve a fixed number ofsubsequent patches.
RoR doesn’t support XML native databases, so we temporarilyuse a RDBMS only for RoR needs.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
AJAX: Asyncronous Javascript And XML
AJAX is a web development tecnique for creating interactiveweb applications. It uses a combination of XHTML,Javascript, XML, CSS, DOM and the XMLHTTPRequestobject.
XMLHTTPRequest lets clients ask servers to give someparticular data using asyncronous handshake, while users canstill continue using the web application.
Ruby on Rails fully supports AJAX.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
AJAX: Asyncronous Javascript And XML
AJAX is a web development tecnique for creating interactiveweb applications. It uses a combination of XHTML,Javascript, XML, CSS, DOM and the XMLHTTPRequestobject.
XMLHTTPRequest lets clients ask servers to give someparticular data using asyncronous handshake, while users canstill continue using the web application.
Ruby on Rails fully supports AJAX.
Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
AJAX: Asyncronous Javascript And XML
AJAX is a web development tecnique for creating interactiveweb applications. It uses a combination of XHTML,Javascript, XML, CSS, DOM and the XMLHTTPRequestobject.
XMLHTTPRequest lets clients ask servers to give someparticular data using asyncronous handshake, while users canstill continue using the web application.
Ruby on Rails fully supports AJAX.
Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simplesearch engine.
The engine returns a list of meaning and a set of linksbetween them.
These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.
Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.
These modifications are stored into the history of thedocument.
Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simplesearch engine.
The engine returns a list of meaning and a set of linksbetween them.
These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.
Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.
These modifications are stored into the history of thedocument.
Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simplesearch engine.
The engine returns a list of meaning and a set of linksbetween them.
These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.
Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.
These modifications are stored into the history of thedocument.
Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simplesearch engine.
The engine returns a list of meaning and a set of linksbetween them.
These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.
Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.
These modifications are stored into the history of thedocument.
Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simplesearch engine.
The engine returns a list of meaning and a set of linksbetween them.
These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.
Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.
These modifications are stored into the history of thedocument.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and commonterminology for the team – done.
Test technologies in order to find out what may fit our needs– done.
Develop our first prototype with the basic data structure – inprogress.
Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.
Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and commonterminology for the team – done.
Test technologies in order to find out what may fit our needs– done.
Develop our first prototype with the basic data structure – inprogress.
Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.
Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and commonterminology for the team – done.
Test technologies in order to find out what may fit our needs– done.
Develop our first prototype with the basic data structure – inprogress.
Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.
Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and commonterminology for the team – done.
Test technologies in order to find out what may fit our needs– done.
Develop our first prototype with the basic data structure – inprogress.
Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.
Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and commonterminology for the team – done.
Test technologies in order to find out what may fit our needs– done.
Develop our first prototype with the basic data structure – inprogress.
Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.
Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and commonterminology for the team – done.
Test technologies in order to find out what may fit our needs– done.
Develop our first prototype with the basic data structure – inprogress.
Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.
Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.
Introduction Structure Architecture Conclusions
What is done, what’s still to do
Thanks
We wish to acknowledge Massimiliano Pepe for his collaboration.
Attribuzione - Non Commerciale - Condividi allo stesso modo 2.0 Italia
http://creativecommons.org/licenses/by-nc-sa/2.0/it/
You may have this file here: http://purl.org/net/fgobbo
Questions?
