Re: [Gzz] The FenPDF interface

[Tuomas Lukka]

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"

> - Select an area (for linking or transclusion)

Area of what? Area of canvas also, or only article?

> - Make a link

Between what? Do we want xu links now or not? I think possibly
transclusion + pp links would be ok

> - Make a transclusion
> 
> Moving inside the focused article or canvas can be done in two ways: 
> By clicking where you want to go, or by dragging the article/canvas to 
> the position where you want it to be. The latter 'feels' much better; 
> to some degree this is be due to timing: moving to a point close to 
> the focus takes a very long time when clicking there.

The timing is adjustable: we could measure the distance and
make the motion faster in that case.

But I like dragging. Or quake-view, i.e. mouse cursor is *always*
in the center.

> Actions we can use
> ==================
> 
> - Left click
> - Left drag
> - Right/middle click/drag
> - Modifier key + click/drag
> - Shortcut key

(+ of course lego controller)

> Everything except left click and left drag is unusual to many people.

Right click is often used for "context-sensitive 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.

> 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. 2 is "paste" in X.

> Proposed interface
> ==================
> 
> First of all, I think while reading you want to be able to keep track 
> of different parts of different articles. This could be done with 
> having multiple cursors (foci) in different parts of the screen. But 
> then you'd want to be able to store different arrangements of them and 
> so on, and it would get messy.
> 
> So, I propose that at every time, you have your main focus, "what 
> you're reading right now," and a PP canvas for
> 
> - bookmarks
> - notes
> - arranging transclusions into Memex-like trails etc

Yes. This sounds good.

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

Um, you haven't defined a data model yet: do we have pieces of canvases
contained in a canvas? Or just links / transclusions?

> The main (upper) 
> focus can be an article or PP canvas; the secondary focus ("panel") is 
> always a PP canvas. You would have the following kinds of objects on 
> screen:
> 
> - Articles (in upper focus)
> - PP canvases (in upper and lower focus)
> - Buoys of an article or PP canvas
> - Nodes on a PP canvas: Text, transclusion from article
> - Selections on the article shown in the upper focus
> 
> 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. Maybe canvas
links should actually be not between content but geometrical locations.

> Proposed bindings
> =================
> 
> - 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?

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

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

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

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

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

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

        Tuomas