Master's degree project: Non linear browsing history tool
Regular webb-browsers have a history that can be described as linear. Given a position in the history there is at most one back and forward. Consequently, when you backtrace and take a new path you loose history. Furthermore, if you browse to a page already occuring in the history this isn't noted, i.e relevant information that could be used to support a feeling of overview is ignored by the browser. A linear history can easily be presented as a list where the current position is marked somehow. A history that doesn't forget old paths and notes when the same page is visited twice will be a full fledged graph.
We would like to see a graph history tool. Prefferably it should:
- Lose no information in terms of new paths, meta-data information etc.
- Consequtive visits make the graph more tightly connected, i.e. two visits to the same page are stored in the same node in the history graph.
- Allow logging of several different browsing activites for extendability, i.e. in Conzilla there is three different browsing alternatives that generate history.
- Have a graph based user-interface. (Prefferably based on conzilla.)
- Allow and even support history-revisions as a mean to simplify the experience for later revisitations.
- Allow storage of history. E.g. for presentational issues or as documentation of a learning process.
Mainly it would work as an navigational help when moving between contextmaps in conzilla. Another possiblity is to make it an applet or plugin to a regular webb-browser. It's important to note that conzilla already have:
- Graph based user-interface.
- Automatic layout.
- Support for editing of graphs.
- An history-listener architecture.
- A linear history.
Hence using this functionality will save much work and allow the project to reach further. This project will have strong connections to the project power-conzilla, i.e. deciding to revisit one specific path through a history, is with some suitable controlling mechanism, a typical presentation.
- We strongly believe in the open source concept and we would therefore like the produced code to be licensed under GPL (GNU Public License).
- For reasons of compatibility with earlier work, we prefer that the code is written in Java.