Re: [Gzz] The FenPDF interface

[Tuomas Lukka]

On Wed, Apr 23, 2003 at 07:36:48PM +0300, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >On Wed, Apr 23, 2003 at 06:27:34PM +0300, Benja Fallenstein wrote:
> >
> >>What we need
> >>============
> >>
> >>- Move to a buoy
> >>- Move inside the focused article/canvas
> >
> >I prefer the terms "pan & zoom"
> 
> Pan is what?

x,y translation. In cinema, a camera pans from object A to object B.

> >>- Select an area (for linking or transclusion)
> >
> >Area of what? Area of canvas also, or only article?
> 
> Article.
> 
> >Between what? Do we want xu links now or not? I think possibly
> >transclusion + pp links would be ok
> 
> I think we want xu links.

I don't think we do, before next tuesday...

After that, yes, but for next tuesday we could easily live without them.
To me, they have never been as compelling as transclusions.

> >>Everything except left click and left drag is unusual to many people.
> >
> >Right click is often used for "context-sensitive menus"
> 
> Yes, but many people don't use it. I want to use it, but I want the 
> basic actions to be archievable without context menus.

Absolutely.

> >>The hardest decision
> >>====================
> >>
> >>It seems pretty clear that left-click should be moving to the 
> >>clicked point. But should left drag (on the focused article/canvas) 
> >>mean dragging the paper, or making a selection? Both are 
> >>well-established conventions in PUIs.
> >
> >Alternative: left-click *starts* selection and ends selection, drag 
> >moves.
> 
> Hyi. Well, ok, this *is* an alternative. But it's modal, and unusual 
> in PUIs.

Yes, it's not a very good one.

> >Um, you haven't defined a data model yet: do we have pieces of 
> >canvases
> >contained in a canvas? Or just links / transclusions?
> 
> I think that 'windows to canvases,' i.e. a piece of a canvas 
> transcluded to another canvas, is one of those things people *think* 
> they want. I think in practice, it has too little use and too many 
> issues, like what does it mean to place a new node on such a window? 
> Which canvas will it go to?
> 
> So the data model I propose is:
> 
> - xu links
> - transclusions onto PP canvases

And for next tuesday's demo, we'll drop xu links from that.
Or xu links are the thing we do *last*, after *EVERYTHING* else
works.

> >>Selections would be a rectangular shaded region of the article. You 
> >>couldn't select regions on a PP canvas.
> >
> >Couldn't select -> people will wonder why it won't work.
> 
> The point is that it wouldn't do anything useful, therefore we 
> disallow it.
> 
> >Maybe canvas
> >links should actually be not between content but geometrical 
> >locations.
> 
> Then dragging the content wouldn't move the link. I like 'between 
> content' better.

Umm, another reason for selecting an area, which is actually used
in a lot of PUI programs: select -> selects all objects in the area,
then can move them all in concert.

> >>- Left drag on focused article (outside current selection): Make 
> >>selection (shown as translucent grey overlay). There can be at most 
> >>one selection at a time. Moving (left clicking or dragging) destroys 
> >>the selection; so does making a new selection, or typing on a PP 
> >>canvas.
> >
> >As mentioned above, I don't like this. Grabbing & dragging feels
> >too natural to lose.
> 
> There are always tradeoffs. I think it's important that the left 
> button can do everything absolutely necessary to use the interface. 
> Two options satisfying this have been proposed:
> 
> - mapping grab&drag to another button or combination
> - handling selection through a modal interface (click beginning, click 
> end)

Ok, I'll live with B2 for drag for now.

> >>So, to make a link, you select the first end and transclude it to 
> >>your PP canvas, move to the second end, and drag it onto the first 
> >>end, making the link.
> >
> >Uhh, dragging something onto a small area, or right next to it is 
> >a bit difficult.
> 
> Hm, if you link only one sentence or so, true. OTOH, you can always 
> zoom in.

How do you zoom the lower focus?

> >>All these are very useful, but not absolutely essential for using 
> >>FenPDF. -- The context menu will appear after you *released* the 
> >>right mouse button, so that we can have--
> >
> >>- Right drag: Drag-to-move the focused article or PP canvas.
> >
> >URGH! No way. This will be confusing. If it's context menu, then
> >that what it will be but right away when pressing it, not after 
> >release.
> >Too different from normal menus otherwise.
> 
> Not unprecedenced. KDE also shows the context menu when the button is 
> released, not when it's pressed.
> 
> The overloading is unusual, but there are always tradeoffs. I think 
> this is the better one than your modal interface proposal, which is 
> also definitely not the way PUIs normally do it.

Hmm, ok. For now.

> >>By default, the lower focus should take up approx. 1/4 of the 
> >>screen, I think. Up for experimenting.
> >
> >Feels cramped to me. There's more room horizontally than vertically.
> >
> >Needs to be easy to make current focus full-screen for *reading*.
> >For articles, we need two modes: reading & browsing.
> >
> >Reading is without fisheye &c.
> 
> I think I'd prefer reading with *small* fisheye, actually.
> 
> Anyway, so how about the panel gets small when we click around in the 
> upper focus, and big when we click around in the panel.

Sounds like it can easily get in the way...

        Tuomas