Re: [Gzz] Re: Is xupdf reasonable?!

[Asko Soukka]

Mon, 27 Jan 2003, Tuomas Lukka wrote:
> > My point is that there are dozens of different link types and if we start 
> > marking them somehow in xupdf we have to make big compromises: choosing 
> > what link types are enough to include, and what kind of graphical elements 
> > we add to present them. We have already used the "color coding" for 
> > papers' uniqueness. (should also remember 7+-2)
> 7+-2 is more about immediate grasping, not about remembering
> different types, right?

Yes, related with the size of working memory. More than amount of 
different link types (that could be learn as you said), I mean the total 
amount of things to keep track of in a single UI. Must be careful when 
adding new elements like labeling for the links.

> > > Asko's second idea was that this is only talking about different views.
> > I couldn't get xupdf compiled, so I don't know how it have changed during 
> > last month. 
> Please report any errors here!  Immediately!

http://www.cc.jyu.fi/~atsoukka/compile.log

Well, because mudyc got it compile, my system probably lacks now some 
package. Though, it crashed on Mudyc's siksak.it.jyu.fi.

> > Anyway I would like to see it only as an applitude among many 
> > others and would like to keep it as simple and tidy as possible. If we 
> > can't show something like link-types in xupdf without making it visually 
> > bloated, we should make a new view/applitude for them.
> Showing link types is not the problem - forcing the user to mark them is IMHO.

Sometimes the direction affects the type, so single labeling won't always 
work with our two-directional linking. Those ones were also on Trigg's 
list. "foo/foo2" like labeling would be ugly :) So we need at least 
distinct label to the start and end of connection (like marking 
"kardinaliteetit" in class diagrams). Maybe even something more general...

> There are some downsides here as well: one of the main faults of the normal
> raster views of the zz structure is that most dimensions are hidden and that
> the dimensions are sparse.

But spesific views have of course their own default dimensions.

> You cannot know if there are connection "hidden" without rotating around.

True. Would we need somekind of metaview to show "most active dimensions" 
in current cell?

> In this way, the separate views/applitudes thing needs more thinking; 
> something
> like hinting to the user that there's something in the other applitude here.

Well, we have to solve some time anyway the problem of browsing dimensions 
and views when there are "too many" of them. Could we use the structure to 
build some kind of "collections" from them? Some views would be "closer" 
and easier to use together, same with dimensions, and also some relations 
betheen spesific views/applitudes and their default dimensions.

-- 
Asko Soukka     | Taitoniekantie 9 A 603 | address@hidden
+358-40-8235947 | FIN-40740 JYVÄSKYLÄ    | http://www.iki.fi/asko.soukka/