176 |
|
|
177 |
In this article, we take the ideas seen in the above references |
In this article, we take the ideas seen in the above references |
178 |
a logical step further. |
a logical step further. |
179 |
We begin from three simple principles [XXXrefs???]: |
We begin from simple design principles |
|
|
|
|
- the user should always see [fragments of] all link targets |
|
|
"you should see where you can go to" |
|
|
|
|
|
- the link transition should be fluidly animated, so that the |
|
|
visible link target comes to the focus |
|
|
"you should see how you go there" |
|
|
|
|
|
- the link transition and resulting view should make it obvious to the user how |
|
|
to go back, without a "back button" [implies bidirectional links] |
|
|
"once you get there, you should see how you can get back". |
|
|
|
|
180 |
|
|
181 |
|
|
182 |
we apply some well-known, and develope a number of new user interface techniques |
we apply some well-known, and develope a number of new user interface techniques |
186 |
several visual effects that merely five years ago were only possible on expensive |
several visual effects that merely five years ago were only possible on expensive |
187 |
graphics workstations. |
graphics workstations. |
188 |
|
|
189 |
The interface requires less rigid structure of the view than |
The interface has less rigid structure of the view than |
190 |
earlier interfaces. |
earlier interfaces. |
191 |
|
|
|
To be able to show all the connected information near the focus, |
|
|
only the relevant fragments of the linked documents can be shown. |
|
|
Therefore, we must be able to fluidly animate a fragment to |
|
|
a whole document. |
|
192 |
The new visual tecniques include link targets |
The new visual tecniques include link targets |
193 |
floating around the focus called *buoys*; *break lines*, a way of showing |
floating around the focus called *buoys*; *break lines*, a way of showing |
194 |
and animating a document fragment as a torn-off piece of the whole; |
and animating a document fragment as a torn-off piece of the whole; |
216 |
|
|
217 |
In the following sections, we ... |
In the following sections, we ... |
218 |
|
|
219 |
User-interface techniques enabled by fast hardware |
The BuoyOING user interface |
220 |
================================================== |
=========================== |
221 |
|
|
222 |
|
The design of our user interface starts from |
223 |
|
three simple principles [XXXrefs???]: |
224 |
|
|
225 |
|
- the user should always see all link targets |
226 |
|
"you should see where you can go to" |
227 |
|
|
228 |
|
- the link transition should be fluidly animated |
229 |
|
"you should see how you go there" |
230 |
|
|
231 |
|
- the link transition and resulting view should make it obvious to the user how |
232 |
|
to go back, without a "back button" [implies bidirectional links] |
233 |
|
"once you get there, you should see how you can get back". |
234 |
|
|
235 |
|
To be able to show all the link targets near the focus, |
236 |
|
only the *relevant fragments* (the immediate surroundings of the other |
237 |
|
end of the link) of the target nodes can be shown. |
238 |
|
|
239 |
|
In order to make this work from a user interface perspective, |
240 |
|
we need to be able to help the user recognize the target documents, |
241 |
|
since document fragments can be confusing. |
242 |
|
|
243 |
|
|
244 |
|
Therefore, we must be able to fluidly animate a fragment to |
245 |
|
a whole document. |
246 |
|
|
247 |
In this section we describe several visual techniques that |
In this section we describe several visual techniques that |
248 |
have only recently become possible on commodity hardware. |
have only recently become possible on commodity hardware. |
250 |
Of these techniques, only the first seems to have been used |
Of these techniques, only the first seems to have been used |
251 |
prior to this work (XXX two papers in review process) |
prior to this work (XXX two papers in review process) |
252 |
|
|
253 |
Buoys |
In the following subsections, we discuss the details |
254 |
----- |
of the main components of the interface: buoy placement, unique backgrounds, |
255 |
|
and following that, some techniques which are not as essential but |
256 |
|
support this type of interface by clarifying the graphical appearance: |
257 |
|
break lines, |
258 |
|
nadir rotations and |
259 |
|
fisheye. |
260 |
|
|
261 |
|
Buoy placement |
262 |
|
-------------- |
263 |
|
|
264 |
Usually everything is either in the coordinate system of the |
Usually everything is either in the coordinate system of the |
265 |
virtual paper (e.g., the margins of the web page being scrolled) |
virtual paper (e.g., the margins of the web page being scrolled) |
287 |
- buoys should be placed close to their anchors |
- buoys should be placed close to their anchors |
288 |
- buoys anchored closer to the focus should be larger |
- buoys anchored closer to the focus should be larger |
289 |
- the view should animate continuously when the focus moves |
- the view should animate continuously when the focus moves |
290 |
|
- the user should be able to understand and predict the motion |
291 |
|
of the buoys. |
292 |
|
|
293 |
Furthermore, |
Furthermore, |
294 |
it is important to maintain orientation locally, |
it is important to maintain orientation locally, |
365 |
the simplest way to meet the layout requirements. |
the simplest way to meet the layout requirements. |
366 |
|
|
367 |
|
|
368 |
|
|
369 |
|
|
370 |
|
|
371 |
|
Paper |
372 |
|
----- |
373 |
|
|
374 |
|
Although the silhuettes of the buoys are different, |
375 |
|
the fragments of the documents still seem quite similar. |
376 |
|
The user could identify the related documents by |
377 |
|
reading the text of a fragment, but that requires attention. |
378 |
|
|
379 |
|
Using a unique background texture for each document changes the |
380 |
|
situation dramatically: the user can perceive the identity |
381 |
|
of the most familiar documents at a glance, |
382 |
|
even when only fragments are shown. |
383 |
|
Furthermore, when moving from node to node, the pre-attentive |
384 |
|
cues of identity help the user maintain a sense of direction. |
385 |
|
|
386 |
|
The background textures are randomly chosen using the identity as a seed. |
387 |
|
That is, each document has a unique backround texture, but the texture |
388 |
|
is not in any way related to the contents of the document (except |
389 |
|
that a hash of the contents could be used as an identity of an immutable |
390 |
|
document). |
391 |
|
That way, the textures in any view are as different as possible, |
392 |
|
even if the documents are similar. |
393 |
|
Furthermore, the unique background of any document can be instantly drawn, |
394 |
|
as soon as the identity inside the system is known. |
395 |
|
|
396 |
|
The distribution of the textures is designed to be maximally |
397 |
|
diverse and recognizable with respect to a rough, qualitative model |
398 |
|
of visual perception. |
399 |
|
For example, backgrounds with random pixels (noise) would all |
400 |
|
look the same, because the pixels are not perceived individually. |
401 |
|
However, shapes and overall colors should be independently random to |
402 |
|
maximize diversity. |
403 |
|
Making the backgrounds repeating creates well-defined patterns |
404 |
|
and improves recognizability when fragments are shown. |
405 |
|
|
406 |
|
Our hardware implementation (libpaper) uses a small set |
407 |
|
of *basis textures*, which are non-linearly combined on the |
408 |
|
GPU to create a large set of recognizable shapes. |
409 |
|
The coordinates of the component textures are |
410 |
|
randomly chosen affine functions of the paper location, |
411 |
|
but repeating with a randomly chosen *repeating unit* |
412 |
|
(a parallelogram). |
413 |
|
|
414 |
|
At each pixel, the combined values of the basis textures |
415 |
|
are used for interpolating between the colors |
416 |
|
of a small, randomly chosen palette of *compatible* colors. |
417 |
|
That way, the colors and shapes are independently random |
418 |
|
and the palette can be restricted to light colors to |
419 |
|
maintain readability. |
420 |
|
|
421 |
Break lines |
Break lines |
422 |
----------- |
----------- |
423 |
|
|
510 |
distinguished preattentively (REF; see fillets article) |
distinguished preattentively (REF; see fillets article) |
511 |
|
|
512 |
|
|
|
|
|
|
|
|
|
|
|
|
Paper |
|
|
----- |
|
|
|
|
|
Although the silhuettes of the buoys are different, |
|
|
the fragments of the documents still seem quite similar. |
|
|
The user could identify the related documents by |
|
|
reading the text of a fragment, but that requires attention. |
|
|
|
|
|
Using a unique background texture for each document changes the |
|
|
situation dramatically: the user can perceive the identity |
|
|
of the most familiar documents at a glance, |
|
|
even when only fragments are shown. |
|
|
Furthermore, when moving from node to node, the pre-attentive |
|
|
cues of identity help the user maintain a sense of direction. |
|
|
|
|
|
The background textures are randomly chosen using the identity as a seed. |
|
|
That is, each document has a unique backround texture, but the texture |
|
|
is not in any way related to the contents of the document (except |
|
|
that a hash of the contents could be used as an identity of an immutable |
|
|
document). |
|
|
That way, the textures in any view are as different as possible, |
|
|
even if the documents are similar. |
|
|
Furthermore, the unique background of any document can be instantly drawn, |
|
|
as soon as the identity inside the system is known. |
|
|
|
|
|
The distribution of the textures is designed to be maximally |
|
|
diverse and recognizable with respect to a rough, qualitative model |
|
|
of visual perception. |
|
|
For example, backgrounds with random pixels (noise) would all |
|
|
look the same, because the pixels are not perceived individually. |
|
|
However, shapes and overall colors should be independently random to |
|
|
maximize diversity. |
|
|
Making the backgrounds repeating creates well-defined patterns |
|
|
and improves recognizability when fragments are shown. |
|
|
|
|
|
Our hardware implementation (libpaper) uses a small set |
|
|
of *basis textures*, which are non-linearly combined on the |
|
|
GPU to create a large set of recognizable shapes. |
|
|
The coordinates of the component textures are |
|
|
randomly chosen affine functions of the paper location, |
|
|
but repeating with a randomly chosen *repeating unit* |
|
|
(a parallelogram). |
|
|
|
|
|
At each pixel, the combined values of the basis textures |
|
|
are used for interpolating between the colors |
|
|
of a small, randomly chosen palette of *compatible* colors. |
|
|
That way, the colors and shapes are independently random |
|
|
and the palette can be restricted to light colors to |
|
|
maintain readability. |
|
|
|
|
|
|
|
513 |
Distortion-oriented Focus+Context view of virtual paper |
Distortion-oriented Focus+Context view of virtual paper |
514 |
------------------------------------------------------- |
------------------------------------------------------- |
515 |
|
|
525 |
does not give satisfactory results, since the distorted regions are too blurred. |
does not give satisfactory results, since the distorted regions are too blurred. |
526 |
|
|
527 |
|
|
528 |
|
|
529 |
Implementation on the Gzz platform |
Implementation on the Gzz platform |
530 |
================================== |
================================== |
531 |
|
|