|
Tuomas J. Lukka, Ph.D, Group Leader |
|
|
----------------------------------- |
|
|
|
|
1 |
Gzz postmortem -- Fenfire prenatal |
Gzz postmortem -- Fenfire prenatal |
2 |
================================== |
================================== |
3 |
|
|
4 |
This spring, the work of our hyperstructure group has |
:Author: Tuomas J. Lukka, Ph.D, Group Leader |
|
undergone significant changes. While the overall goals |
|
|
and directions remain the same, the specific tools had |
|
|
to be changed due to Ted Nelson's actions with his U.S. |
|
|
patent on zzStructure. |
|
|
|
|
|
Currently, we are using RDF instead of zzStructure |
|
|
as a basis for our next-generation user environment. |
|
|
The underlying philosophy of deep linking simple navigation |
|
|
remains, however, and almost all our technologies and tools |
|
|
are still applicable. |
|
|
|
|
|
At the same time, we have split the project on the free software |
|
|
development server Savannah to several subprojects |
|
|
due to their maturity --- some parts should |
|
|
be easily applicable outside fenfire itself. |
|
|
|
|
5 |
|
|
6 |
Matti J. Katila |
This spring, the work of our hyperstructure group has |
7 |
--------------- |
undergone significant changes. While the overall goals |
8 |
|
and directions remain the same, the specific tools had |
9 |
|
to be changed due to Ted Nelson's actions with his U.S. |
10 |
|
patent on zzStructure. |
11 |
|
|
12 |
|
Currently, we are using RDF instead of zzStructure |
13 |
|
as a basis for our next-generation user environment. |
14 |
|
The underlying philosophy of deep linking simple navigation |
15 |
|
remains, however, and almost all our technologies and tools |
16 |
|
are still applicable. |
17 |
|
|
18 |
|
At the same time, we have split the project on the free software |
19 |
|
development server Savannah to several subprojects |
20 |
|
due to their maturity --- some parts should |
21 |
|
be easily applicable outside fenfire itself. |
22 |
|
|
23 |
Example application prototypes |
Example application prototypes |
24 |
============================== |
============================== |
25 |
|
|
26 |
There are various of ways to show information to user. |
:Author: Matti J. Katila |
|
Most of people know only systems with overlapping windows, |
|
|
menus etc. which are common in Windows(tm) like environments. |
|
|
We show some new innovations around user interfaces and |
|
|
combine them with ones that are already known but rarely seen. |
|
|
You are going to see in action: bidirectional links, buoys, |
|
|
fisheye, unique paper background and other techniques available |
|
|
with todays graphic hardware. |
|
|
|
|
27 |
|
|
28 |
Tuukka Hastrup |
There are various of ways to show information to user. |
29 |
-------------- |
Most of people know only systems with overlapping windows, |
30 |
|
menus etc. which are common in Windows(tm) like environments. |
31 |
|
We show some new innovations around user interfaces and |
32 |
|
combine them with ones that are already known but rarely seen. |
33 |
|
You are going to see in action: bidirectional links, buoys, |
34 |
|
fisheye, unique paper background and other techniques available |
35 |
|
with todays graphic hardware. |
36 |
|
|
37 |
Loom browses RDF as hyperstructure |
Loom browses RDF as hyperstructure |
38 |
================================== |
================================== |
39 |
|
|
40 |
We want to allow the users to bring together any information |
:Author: Tuukka Hastrup |
41 |
items they decide related, no matter which task the |
|
42 |
information originates from. These connections build a |
We want to allow the users to bring together any information |
43 |
hyperstructure, which should be easy to edit and navigate. |
items they decide related, no matter which task the |
44 |
Formerly, we used Ted Nelson's zzStructure as the form to this |
information originates from. These connections build a |
45 |
structure, but our current browser utilises the RDF standard. |
hyperstructure, which should be easy to edit and navigate. |
46 |
|
Formerly, we used Ted Nelson's zzStructure as the form to this |
47 |
Currently, we apply our previous experiences to the RDF browser |
structure, but our current browser utilises the RDF standard. |
48 |
called Loom. After 4 weeks of development, it can already |
|
49 |
browse structures and soon also edit. RDF does not have the |
Currently, we apply our previous experiences to the RDF browser |
50 |
limits of zzStructure, but we have learned from Gzz how to |
called Loom. After 4 weeks of development, it can already |
51 |
visualize rich structures. |
browse structures and soon also edit. RDF does not have the |
52 |
|
limits of zzStructure, but we have learned from Gzz how to |
53 |
RDF is a standard of the World Wide Web Consortium for machine- |
visualize rich structures. |
54 |
processable information, and the Semantic Web builds on it. |
|
55 |
Several other projects are using or evaluating RDF for |
RDF is a standard of the World Wide Web Consortium for machine- |
56 |
hypertextual information as well. Others can use Loom for |
processable information, and the Semantic Web builds on it. |
57 |
browsing, and we can make good use of the existing RDF |
Several other projects are using or evaluating RDF for |
58 |
libraries. |
hypertextual information as well. Others can use Loom for |
59 |
|
browsing, and we can make good use of the existing RDF |
60 |
|
libraries. |
61 |
|
|
62 |
.. zzStructure, but there are several alternatives. We re-evaluated |
.. zzStructure, but there are several alternatives. We re-evaluated |
63 |
some other structures after Ted Nelson received a patent on |
some other structures after Ted Nelson received a patent on |
64 |
zzStructure and wanted to enforce it, and found RDF better for |
zzStructure and wanted to enforce it, and found RDF better for |
65 |
us. |
us. |
66 |
|
|
|
|
|
|
Janne V. Kujala, MSc |
|
|
-------------------- |
|
|
|
|
67 |
Pre-attentive cues in user interfaces |
Pre-attentive cues in user interfaces |
68 |
===================================== |
===================================== |
69 |
|
|
70 |
Employing the effortless and parallel pre-attentive |
:Author: Janne V. Kujala, MSc |
71 |
processes of human vision can yield substantial improvements |
|
72 |
in the usability of computer interfaces. We show several |
Employing the effortless and parallel pre-attentive |
73 |
examples in our prototype interfaces: Fillets --- smoothing |
processes of human vision can yield substantial improvements |
74 |
of sharp angles at the joints --- make the connections in a |
in the usability of computer interfaces. We show several |
75 |
graph-like diagram easily discriminable. Unique background |
examples in our prototype interfaces: Fillets --- smoothing |
76 |
textures help the user instantly identify a familiar |
of sharp angles at the joints --- make the connections in a |
77 |
document, even if only a fragment is seen. Tearing instead |
graph-like diagram easily discriminable. Unique background |
78 |
of rectangularly clipped viewports makes document fragments |
textures help the user instantly identify a familiar |
79 |
comprehensible at a glance. |
document, even if only a fragment is seen. Tearing instead |
80 |
|
of rectangularly clipped viewports makes document fragments |
81 |
|
comprehensible at a glance. |
82 |
|
|
83 |
Lego controllers |
Lego controllers |
84 |
================ |
================ |
85 |
|
|
86 |
New user interfaces could benefit from customized controllers, |
:Author: Janne V. Kujala, MSc |
|
but it is expensive to design and produce for a specific |
|
|
purpose unless standard, mass-produced parts can be used. |
|
|
We show how controllers can be built from a standard mouse |
|
|
and Lego bricks, allowing anyone to reproduce the design |
|
|
without any tools and to easily prototype new designs. |
|
87 |
|
|
88 |
|
New user interfaces could benefit from customized controllers, |
89 |
Vesa Kaihlavirta |
but it is expensive to design and produce for a specific |
90 |
---------------- |
purpose unless standard, mass-produced parts can be used. |
91 |
|
We show how controllers can be built from a standard mouse |
92 |
|
and Lego bricks, allowing anyone to reproduce the design |
93 |
|
without any tools and to easily prototype new designs. |
94 |
|
|
95 |
Storm |
Storm |
96 |
===== |
===== |
97 |
|
|
98 |
Storm (STORage Module) is a library for storing and retrieving data as |
:Author: Vesa Kaihlavirta |
|
immutable byte sequences, which are identified by cryptographic |
|
|
content hashes. This allows for addressing two important issues |
|
|
of data mobility: dangling links and version management. |
|
|
|
|
|
Dangling (broken) links are a well-known problem in contemporary hypertext networks, |
|
|
ultimately caused by the links referring to a specific location. |
|
|
In Storm, we assume that location-independent identifiers are resolvable |
|
|
in an efficient and trusted manner, thus causing links not to dangle. |
|
|
|
|
|
Version management allows a user to fluently work with and move between |
|
|
between different versions of a resource. This includes editing |
|
|
the current version, merging it with another version, forking, and reverting |
|
|
to older versions. |
|
|
|
|
99 |
|
|
100 |
Hermanni Hyytiälä |
Storm (STORage Module) is a library for storing and retrieving data as |
101 |
----------------- |
immutable byte sequences, which are identified by cryptographic |
102 |
|
content hashes. This allows for addressing two important issues |
103 |
|
of data mobility: dangling links and version management. |
104 |
|
|
105 |
|
Dangling (broken) links are a well-known problem in contemporary |
106 |
|
hypertext networks, ultimately caused by the links referring to a |
107 |
|
specific location. In Storm, we assume that location-independent |
108 |
|
identifiers are resolvable in an efficient and trusted manner, thus |
109 |
|
causing links not to dangle. |
110 |
|
|
111 |
|
Version management allows a user to fluently work with and move between |
112 |
|
between different versions of a resource. This includes editing |
113 |
|
the current version, merging it with another version, forking, and reverting |
114 |
|
to older versions. |
115 |
|
|
116 |
Fenfire and P2P |
Fenfire and P2P |
117 |
=============== |
=============== |
|
|
|
|
We use Peer-to-Peer technologies to build a location transparent, |
|
|
hyperstructured desktop environment. We believe that the properties |
|
|
of Peer-to-Peer technology, such as the ad hoc connectivity and |
|
|
the lack of central authority, are prerequisites while mobilizing |
|
|
the Fenfire system. We wish to use globally unique, semantic-free |
|
|
references for locating data in Peer-to-Peer environment. Our future |
|
|
work includes a implmentation of Fenfire Peer-to-Peer prototype. |
|
118 |
|
|
119 |
|
:Author: Hermanni Hyytiälä |
120 |
|
|
121 |
Asko Soukka |
We use Peer-to-Peer technologies to build a location transparent, |
122 |
----------- |
hyperstructured desktop environment. We believe that the properties |
123 |
|
of Peer-to-Peer technology, such as the ad hoc connectivity and |
124 |
|
the lack of central authority, are prerequisites while mobilizing |
125 |
|
the Fenfire system. We wish to use globally unique, semantic-free |
126 |
|
references for locating data in Peer-to-Peer environment. Our future |
127 |
|
work includes a implmentation of Fenfire Peer-to-Peer prototype. |
128 |
|
|
129 |
Navidoc |
Navidoc |
130 |
======= |
======= |
131 |
|
|
132 |
Navidoc is a collection of lightweight tools built to support our |
:Author: Asko Soukka |
133 |
project's documentation. Navidoc expands UML diagrams embedded in |
|
134 |
design documentation to work as multi-ended links, which |
Navidoc is a collection of lightweight tools built to support our |
135 |
hypertextually connect design documentation to Javadoc generated |
project's documentation. Navidoc expands UML diagrams embedded in |
136 |
documentation. For describing UML diagrams, Navidoc provides a |
design documentation to work as multi-ended links, which |
137 |
readily-authored lexical language, which can be written within |
hypertextually connect design documentation to Javadoc generated |
138 |
design documentation. The example of Navidoc enhanced documentation |
documentation. For describing UML diagrams, Navidoc provides a |
139 |
could be found at http://himalia.it.jyu.fi/gzzdoc/ |
readily-authored lexical language, which can be written within |
140 |
|
design documentation. The example of Navidoc enhanced documentation |
141 |
|
could be found at http://himalia.it.jyu.fi/gzzdoc/ |
142 |
|
|
143 |
.. - developed as byproduct |
.. - developed as byproduct |
144 |
* components/features added when needed |
* components/features added when needed |
145 |
|
|
146 |
- Navidoc |
- Navidoc |
147 |
* linking different documentations via UML diagrams |
* linking different documentations via UML diagrams |
148 |
+ design documentation |
+ design documentation |
149 |
+ javadoc |
+ javadoc |
150 |
+ lexically described UML diagrams within design documentation |
+ lexically described UML diagrams within design documentation |
151 |
+ postprocessing html files, adding imagemaps and images, |
+ postprocessing html files, adding imagemaps and images, |
152 |
creating crosslinks/backlinks |
creating crosslinks/backlinks |
153 |
|
|
154 |
* Gzz's documentation in himalia as example |
* Gzz's documentation in himalia as example |
155 |
|
|
156 |
- built especially to fit for our needs, to fit and support |
- built especially to fit for our needs, to fit and support |
157 |
our software development process |
our software development process |
158 |
|
|
159 |
* usable with any text editor |
* usable with any text editor |
160 |
* use of open software toolchain |
* use of open software toolchain |
161 |
|
|
162 |
- using reStructuredText |
- using reStructuredText |
163 |
* documentation and code could be written with same tools |
* documentation and code could be written with same tools |
164 |
* "language" could be expanded with directives |
* "language" could be expanded with directives |
166 |
* describing diagrams is easy, placing could be difficult |
* describing diagrams is easy, placing could be difficult |
167 |
* (pegboard) |
* (pegboard) |
168 |
* (latex writer) |
* (latex writer) |
169 |
|
|
170 |
- test framework |
- test framework |
171 |
* adopting XP, importance of writing tests |
* adopting XP, importance of writing tests |
172 |
* framework minimizes the gap of writing and running test |
* framework minimizes the gap of writing and running test |
173 |
|
|
|
|
|
|
Tuomas J. Lukka |
|
|
--------------- |
|
|
|
|
174 |
Closing remarks |
Closing remarks |
175 |
=============== |
=============== |
176 |
|
|
177 |
The graphical interfaces in the demos shown above were written in |
:Author: Tuomas J. Lukka |
178 |
libvob, of which we didn't have an opportunity to discuss more - |
|
179 |
please contact us for details. We are planning to spin off more |
The graphical interfaces in the demos shown above were written in |
180 |
subprojects in the future as they mature. |
libvob, of which we didn't have an opportunity to discuss more - |
181 |
|
please contact us for details. We are planning to spin off more |
182 |
As an overall vision for the project, the basic idea is to keep |
subprojects in the future as they mature. |
183 |
doing what we are doing, working on cool stuff and trying |
|
184 |
to make a computer environment we would like to use ourselves. |
As an overall vision for the project, the basic idea is to keep |
185 |
|
doing what we are doing, working on cool stuff and trying |
186 |
|
to make a computer environment we would like to use ourselves. |
187 |
|
|