Re: [Gzz] The FenPDF interface

[Benja Fallenstein]

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?

> > - 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.

> > 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.

> > 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.

> > Now, everything that can be done with dragging the paper can be done 
> > with clicking on points. Not as conveniently, yes; but if we improve 
> > the timing, I think it won't be horrible. Therefore, I think left drag 
> > should be selection, and drag-to-move-paper should be another 
> > button/combination.
>
> I don't like this; I want some way of dragging, without anything
> more complicated than a mouse button, preferably 1 or 3.

I mean "button or combination."

> > I propose that the PP canvas is a resizable region at the bottom of 
> > the screen, a bit like a panel but generally larger. 
>
> And curved so that there's more of it at the corners than in the middle? ;)

Could be.

> 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

> > 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.

> > - Left click on point of article or PP canvas: focus it
> > - Left click on PP canvas buoy: If attached to upper focus, make it 
> > the upper focus; if attached to lower focus, make it the lower focus
>
> What, there are buoys of the lower focus, too?

Sure! Why would there not be? (How would you otherwise move between 
different PP canvases in the lower focus?)

> > - 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)

> > - IMPORTANT: Left drag the current selection, a buoy, or a PP node 
> > (text or transclusion): If dragged onto a PP canvas, transclude; if 
> > dragged onto another buoy/PP node/selection, make link.
> >
> > While dragging, a connective line is shown from the origin of the drag 
> > to the position of the mouse cursor. Additionally, a translucent copy 
> > of the dragged area is shown under the mouse cursor, *except* if the 
> > mouse cursor is over a second buoy/PP node/selection. This is to show 
> > that if the thing is dragged here, a link will be made, not a 
> > transclusion.
>
> ??? Need image

Is the one I gave you IRL sufficient? :-) Maybe we can scan it.

> > 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.

> > 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.

> > - Middle drag or left+right drag (for two button mice): Zoom / adjust 
> > fisheye.
> >
> > - Mouse wheel or Shift-any drag (for wheelless mice): Adjust relative 
> > size of lower/upper focus. Wheeling up makes the lower focus bigger; 
> > wheeling down makes the upper focus bigger. (In other words, it's like 
> > you're moving the imaginary line separating the two.)
>
> Hmm, these are ok; not sure if they should be reversed from this though...

You mean zoom on wheel, middle drag to change focus size? Ok with me, if 
the precision of the mouse wheel is enough for us.

> > 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.

- Benja