Difference between revisions of "Viewer"
({{stub}}) |
(→Browser based viewer: action) |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{glossary}}<onlyinclude>[[File:TheBrain.jpg|right|200px]] [http://www.thebrain.com TheBrain] application shares a lot conceptually with the [[interface]] we're specifying in the [[software architecture]], if you're unfamiliar with TheBrain, see [http://blog.thebrain.com/beyond-hierarchies/ this blog post] for a quick introduction to the concept before continuing. | |
| + | |||
| + | To the right is an image of TheBrain (click it to enlarge) which is essentially a graphical concept and relationship mapping tool. It's very similar to a [[mind map]]ping tool, except that it's more node-oriented which allows more intuitive navigation around large complex structures of nodes and for diverse concepts to be connected more easily. The application is focused on one particular node in the network which is always at the centre of the screen. The user can move this focus to other nodes by following the linked relationships. Each node may act as a storage repository for information relating to its concept, for example a node representing a particular idea may contain notes, photos, website links and other related items. | ||
| + | |||
| + | The application is like a window, or "viewport" looking into the structure of nodes. The term "viewer" is used to refer to the general class of applications which allow users to view and edit collections of data. The viewer is a tool to provide a window onto the data set and allows the user to look at the data from different perspectives called "views". The idea of moving the "current focus" around the data set (in this case nodes) is a common feature of viewer applications.<onlyinclude> | ||
| + | |||
| + | Since nodes can be filled with associated content such as text notes and files, it's useful for the viewer application to allow easy switching between a number of different ways of looking at the node currently in focus. For example a "document view" would present the text-based aspects of the current node in a document format, or switching to "file view" the same node would appear as a collection of file attachments in a file-browser like way. | ||
| + | |||
| + | The main point here is that the viewer offers a number of unique views onto the current node which can be switched between at any time. Each view renders particular aspects of the current node and offers navigation methods appropriate to that kind of view for navigating the viewer to other nodes. The nodal view shown in the image of TheBrain to the right is just one view of many that could be added to the viewer application. | ||
| + | |||
| + | == Browser based viewer == | ||
| + | This paradigm of separating the viewer, the data and the domain logic is a well established model called [[MVC]] (Model-View-Controller). In fact the web browser application is itself built on this paradigm, and so it makes sense to use browser as the basis of our nodal viewer, at least in the initial stages of development. | ||
| + | |||
| + | The viewer is a [[Single Page Application]] using the [[Livelets]] SWF method so that events can be propagated asynchronously from the local peer up to the browser instances, and interface events can be routed the other way down into the peer if necessary. The browsers current URL determines the node in the network which currently has focus, and the specific context within that focus such as views, sub-views and actions. | ||
| + | :http://localhost:2012/#node/action... | ||
| + | The most important point in this URL format is the hash character since no change in the URL after that character is considered to be outside of the current document, so the entire viewer session (time during which that document/application is viewed) is self-contained into a [[Single Page Application|single DOM instance]] requested only once at the start of the session. | ||
| + | |||
| + | Each node is a [[closure]] within the JavaScript run-time environment, but also persists across sessions and locations by being stored in the form of semantically-connected values in a [[peer-to-peer]] network. | ||
| + | |||
| + | The ''action'' part of the URL determines the node within the current node that will initially gain the executional focus. In fact there could be more path elements after the ''action'' part of the URL which are interpretted by successively deeper levels on executional focus with the semantic structure being rendered by the viewer. | ||
| + | |||
| + | When the node ID changes by clicking on links or buttons in the application, JavaScript events are called by the DOM which update the page and may involve an AJAX request through ''localhost'' to the local peer instance for other node's content in the peer-to-peer network. | ||
| + | |||
| + | We made an experimental start on this idea which was documented in the [[Nodal interface using corMVC]] article, and development is currently continuing in the form of the [[Namecoin SPA]] project. | ||
== See also == | == See also == | ||
| + | *[[Namecoin SPA]] | ||
| + | *[[Nodal interface using corMVC]] | ||
*[[MVC]] | *[[MVC]] | ||
*[[Single Page Application]] | *[[Single Page Application]] | ||
*[[Interface]] | *[[Interface]] | ||
Latest revision as of 17:29, 10 September 2012
|
TheBrain application shares a lot conceptually with the interface we're specifying in the software architecture, if you're unfamiliar with TheBrain, see this blog post for a quick introduction to the concept before continuing.
To the right is an image of TheBrain (click it to enlarge) which is essentially a graphical concept and relationship mapping tool. It's very similar to a mind mapping tool, except that it's more node-oriented which allows more intuitive navigation around large complex structures of nodes and for diverse concepts to be connected more easily. The application is focused on one particular node in the network which is always at the centre of the screen. The user can move this focus to other nodes by following the linked relationships. Each node may act as a storage repository for information relating to its concept, for example a node representing a particular idea may contain notes, photos, website links and other related items.
The application is like a window, or "viewport" looking into the structure of nodes. The term "viewer" is used to refer to the general class of applications which allow users to view and edit collections of data. The viewer is a tool to provide a window onto the data set and allows the user to look at the data from different perspectives called "views". The idea of moving the "current focus" around the data set (in this case nodes) is a common feature of viewer applications.
Since nodes can be filled with associated content such as text notes and files, it's useful for the viewer application to allow easy switching between a number of different ways of looking at the node currently in focus. For example a "document view" would present the text-based aspects of the current node in a document format, or switching to "file view" the same node would appear as a collection of file attachments in a file-browser like way.
The main point here is that the viewer offers a number of unique views onto the current node which can be switched between at any time. Each view renders particular aspects of the current node and offers navigation methods appropriate to that kind of view for navigating the viewer to other nodes. The nodal view shown in the image of TheBrain to the right is just one view of many that could be added to the viewer application.
Browser based viewer
This paradigm of separating the viewer, the data and the domain logic is a well established model called MVC (Model-View-Controller). In fact the web browser application is itself built on this paradigm, and so it makes sense to use browser as the basis of our nodal viewer, at least in the initial stages of development.
The viewer is a Single Page Application using the Livelets SWF method so that events can be propagated asynchronously from the local peer up to the browser instances, and interface events can be routed the other way down into the peer if necessary. The browsers current URL determines the node in the network which currently has focus, and the specific context within that focus such as views, sub-views and actions.
The most important point in this URL format is the hash character since no change in the URL after that character is considered to be outside of the current document, so the entire viewer session (time during which that document/application is viewed) is self-contained into a single DOM instance requested only once at the start of the session.
Each node is a closure within the JavaScript run-time environment, but also persists across sessions and locations by being stored in the form of semantically-connected values in a peer-to-peer network.
The action part of the URL determines the node within the current node that will initially gain the executional focus. In fact there could be more path elements after the action part of the URL which are interpretted by successively deeper levels on executional focus with the semantic structure being rendered by the viewer.
When the node ID changes by clicking on links or buttons in the application, JavaScript events are called by the DOM which update the page and may involve an AJAX request through localhost to the local peer instance for other node's content in the peer-to-peer network.
We made an experimental start on this idea which was documented in the Nodal interface using corMVC article, and development is currently continuing in the form of the Namecoin SPA project.
