[seek-dev] Re: [kepler-dev] scrollbar additions to kepler
Ferdinando Villa
ferdinando.villa at uvm.edu
Wed Jul 28 09:59:32 PDT 2004
Although my UI preferences are similar to Bertram's, in my second life
as an exhibiting photographer I could do without scrollbars in
Photoshop, but I could never do without the spacebar trick mentioned by
Chad to pan around large images... best way I've ever experienced to
navigate a canvas.
And speaking of zooming, maybe people should have another look at
Piccolo (http://www.cs.umd.edu/hcil/piccolo/) and the whole zooming
interface paradigm in general... seems reasonably easy to implement into
an existing canvas.
On Wed, 2004-07-28 at 11:56, Deana D. Pennington wrote:
> 2 cents from a user...
>
> I have used pans in some limited contexts (ENVI, remote sensing app), and like
> them. I think people will like them once they get used to them. There does
> need to be a way to move the screen in small increments, which is frustrating
> with pan. ENVI uses a scroll bar, and I find the combo very effective.
>
> One other thing i kept finding myself wishing for with kepler was a zoom in/out,
> to contol how much of the model showed on the canvas.
>
> Deana
>
>
> Quoting Bertram Ludaescher <ludaesch at sdsc.edu>:
>
> >
> > two more cents:
> >
> > $0.01: the "hand" (a la Adoobe Acrobat) and the Ptolemy panning
> > window:
> > aren't they quite similar in their functionality and behavior?
> >
> > $0.01: I don't like scrollbars usually (but I like panning and the
> > hand), but I got used to this, *sigh*. An interesting idea relating to
> > Edward's question: maybe one could have "logarithmic" or "hyperbolic"
> > scrollbars instead of linear ones.. (I recall having seen hyperbolic
> > menues somewhere)
> >
> > Bertram
> >
> > >>>>> "FV" == Ferdinando Villa <ferdinando.villa at uvm.edu> writes:
> > FV>
> > FV> Despite agreeing with Bertram's list at least 80% (that Prolog
> > bit...),
> > FV> let's not forget that the key to widespread adoption has never
> > been
> > FV> configurability... it's the instant likeability/intuitiveness of
> > the
> > FV> product (closely related to simplicity and the absence of things
> > like
> > FV> green boxes with no visual purpose or trees of objects with
> > strange
> > FV> names). It's just like with people - except that software rarely
> > gets a
> > FV> second chance... ok, people neither...
> > FV>
> > FV> On Wed, 2004-07-28 at 09:01, Rod Spears wrote:
> > >> The "best" is...
> > >>
> > >> Knowing thy user and what they "expect", usability is about
> > >> expectation.
> > >>
> > >> For Bertram, the items below are the "best" for him, although as
> > one
> > >> might expect, they would be the "worst" for me in particular ;-)
> > >>
> > >> Rod
> > >>
> > >>
> > >> Bertram Ludaescher wrote:
> > >> > I wonder how much effort it would be to have the different
> > >> > panning/scrolling modes be customizable user preferences.
> > >> >
> > >> > Also, there is plenty of evidence in the world that the "best"
> > >> > solution not always is the most widespread -- also sometimes "best"
> > is
> > >> > a parameter of the user community, etc.
> > >> >
> > >> > To give a concrete example of my (strange) definition of "best":
> > >> >
> > >> > - best editor: (X)Emacs
> > >> > - best way to navigate and "say what you mean": keyboard
> > >> > (although I must say that I find Vergil quite nice!)
> > >> > - best XML syntax: Prolog syntax
> > >> > - best text processing system: LaTeX
> > >> > - best functional prog. language: Haskell
> > >> >
> > >> > just my $0.02 ;-)
> > >> >
> > >> > Bertram
> > >> >
> > >> >
> > >> >
> > >> > > > > > > "CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
> > >> > > > > > >
> > >> > CB>
> > >> > CB> Edward A Lee wrote:
> > >> >
> > >> > > > I'm a bit confused about the basic motivation here...
> > >> > > >
> > >> > > > A while ago, we had quite a bit of internal discussion about
> > how
> > >> > > > to handle navigation, and we ruled out scrollbars because
> > they
> > >> > > > make less sense for an infinite canvas... How do you intend
> > >> > > > the scrollbars to work? How do you choose the boundaries?
> > >> > > >
> > >> > CB>
> > >> > CB> In this prototype that i've been working on, i've been choosing
> > the
> > >> > CB> boundaries to be the actual size of the model and resizing the
> >
> > >> > CB> scrollbars dynamically as the size of the model increases. The
> > canvas
> > >> > CB> is still infinite, but the viewport resizes (via the
> > scrollbars) to
> > >> > CB> accomodate the model. Do you see a problem with this approach?
> > The
> > >> > CB> other way I've seen applications do this is just to set the
> > scrollbar
> > >> > CB> max to a very large value and position both the vert and horiz
> > bars in
> > >> > CB> the middle of the range. It effectively makes the canvas
> > finite, but is
> > >> > CB> anyone really going to create a model that's 2 miles x 3 miles?
> > If they
> > >> > CB> did, I think we would accuse them of bad programming practice
> > :)
> > >> > CB>
> > >> >
> > >> > > > The other question is about why you want scrollbars in the
> > first place.
> > >> > > > Is it mainly to create a familiar feeling, or is there really
> > >> > > > a functionality issue? They take some of the real estate
> > >> > > > away from the drawing area... Maybe if you give the users
> > some
> > >> > > > time with the panner they will get used to it and decide they
> > >> > > > like it after all...
> > >> > > >
> > >> > CB>
> > >> > CB> It seems like everytime we sit someone down with this they
> > comment about
> > >> > CB> the lack of scrollbars for navigating the canvas. I personally
> > have no
> > >> > CB> problem with the panner, but it's still nice to have a choice
> > of how you
> > >> > CB> want to navigate the canvas. If you just want to move the view
> > down a
> > >> > CB> little bit, it's much easier to click the down arrow on the
> > scrollbar
> > >> > CB> than to move the panner a touch. The panner can be too touchy
> > for
> > >> > CB> moving the view small amounts due to it's low resolution
> > compared to the
> > >> > CB> canvas.
> > >> > CB>
> > >> > CB> Another idea is that instead of having the traditional
> > scrollbar with a
> > >> > CB> slider, we could just use a set of 4 arrows to micomanage the
> > canvas.
> > >> > CB> That way, if you want to nudge the canvas around the viewport
> > by a few
> > >> > CB> pixels, you could just click the arrows instead of using the
> > panner.
> > >> > CB> Without the scroll slider, the canvas would effectively remain
> > infinite.
> > >> > CB>
> > >> >
> > >> > > > Photoshop, IMHO, is not a UI to emulate... But in any case,
> > it
> > >> > > > always has a finite canvas size, so this is less of an issue.
> > >> > > > I think our infinite canvas is really much nicer for our
> > purposes,
> > >> > > > since limiting to a "page size" makes no sense in our case.
> > >> > > >
> > >> > CB>
> > >> > CB> Photoshop and Illustrator both have a finite canvas, but that
> > canvas can
> > >> > CB> be very big. I find the scrollbars to be very effective for
> > navigation
> > >> > CB> on the canvas, especially when combined with the hand tool.
> > Note that
> > >> > CB> you can quickly change to the handtool in Illustrator by
> > holding down
> > >> > CB> the spacebar, which is quite convenient.
> > >> > CB>
> > >> >
> > >> > > > I agree with Steve that the major pitfall with the hand is
> > >> > > > that you have to set a "hand mode" for the UI to use it.
> > >> > > > It seems the prevailing "religion" in UI circles is that
> > >> > > > modal behavior is a bad thing... and it is a nuisance to
> > >> > > > have to be switching back and forth between modes...
> > >> > > > If you can find a way to do without modes (and within
> > >> > > > the Mac's one-button limitation), then that would be great.
> > >> > > >
> > >> > CB>
> > >> > CB> Personally, I don't see what the big deal is. I've been using
> > modal
> > >> > CB> GUIs for a long time and have never had a problem with choosing
> > a
> > >> > CB> navigation tool instead of a drawing tool. That said, I
> > consider myself
> > >> > CB> an advanced user with most programs like this (i.e. Photoshop
> > and
> > >> > CB> Illustrator). I'll try to figure out a way to do
> > this...possibly with
> > >> > CB> a keyboard shortcut or something.
> > >> > CB>
> > >> > CB> chad
> > >> > CB>
> > >> >
> > >> > > > Edward
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > At 10:47 AM 7/27/2004 -0700, Chad Berkley wrote:
> > >> > > >
> > >> > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > I've been working the last 4 days to add scrollbars to the
> > vergil
> > >> > > > > canvas. I've had limited success and I've run into a couple
> > problems.
> > >> > > > > I wanted to see what others thought of this before I
> > continue.
> > >> > > > >
> > >> > > > > There are two different places where this functionality can
> > be added.
> > >> > > > > The first one (and probably the technically correct place) is
> > in the
> > >> > > > > Diva library. Diva is the library ptolemy uses to provide
> > all of the
> > >> > > > > graph editing functionality. Diva also provides the panner
> > (the
> > >> > > > > widget in the bottom left that allows you to move around the
> >
> > >> > > > > workspace). The second place this functionality can be added
> > is to
> > >> > > > > the Vergil gui classes.
> > >> > > > >
> > >> > > > > Placing the code in diva is probably the best way to do this
> > because
> > >> > > > > then it would integrate seamlessly into the current view and
> > allow the
> > >> > > > > scrollbars to interact with the panner. Changing Diva to do
> > this is
> > >> > > > > not trivial. Diva has it's own layer system built around AWT
> > with
> > >> > > > > some Swing components. Also, if we change diva, it's going
> > to be much
> > >> > > > > harder to make this a "pluggable" change without making some
> >
> > >> > > > > architectural change to diva itself.
> > >> > > > >
> > >> > > > > Placing the code in the BasicGraphFrame class of vergil is
> > the most
> > >> > > > > straight forward way to do it because the vergil gui uses all
> > swing
> > >> > > > > components and places diva widgets inside the swing
> > components. This
> > >> > > > > is the way I have partially implemented the scrollbars now
> > (using a
> > >> > > > > JScrollPane). There are several problems with this. First
> > of all,
> > >> > > > > getting the scrollbars to interact with the panner correctly
> > seems
> > >> > > > > mostly impossible. Basically, i have to remove the panner or
> > else
> > >> > > > > things get chaotic real quick. If the user moves the
> > workspace via
> > >> > > > > the panner, there is no event to catch when this happens, so
> > the
> > >> > > > > scrollbars can't be updated accordingly. I've also had to
> > make major
> > >> > > > > changes to the zoom code. The two advantages of doing it
> > this way are
> > >> > > > > that it's easier to code since one can work with only swing
> > components
> > >> > > > > and i think it will be easier to make this a pluggable change
> > since
> > >> > > > > some people have said they don't want scrollbars on the
> > canvas.
> > >> > > > >
> > >> > > > > Another thing I thought of the other day while working with
> > photoshop
> > >> > > > > (which has scrollbars on it's canvas), is that we could add a
> > "hand"
> > >> > > > > tool which would serve one of the purposes of the panner (to
> > let you
> > >> > > > > move around the workspace). I like the panner and don't
> > really want
> > >> > > > > to get rid of it anyway. I think the panner, scrollbars and
> > a
> > >> > > > > potential hand tool would work well together. It's just a
> > matter of
> > >> > > > > figuring out the best way to do it. Ptolemy folks: how hard
> > do you
> > >> > > > > think it would be to add this to Diva?
> > >> > > > >
> > >> > > > > thoughts?
> > >> > > > >
> > >> > > > > chad
> > >> > > > > _______________________________________________
> > >> > > > > kepler-dev mailing list
> > >> > > > > kepler-dev at ecoinformatics.org
> > >> > > > > http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> > >> > > > >
> > >> > > > ------------
> > >> > > > Edward A. Lee, Professor
> > >> > > > 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> > >> > > > phone: 510-642-0455, fax: 510-642-2739
> > >> > > > eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> > >> > > >
> > >> > CB> _______________________________________________
> > >> > CB> kepler-dev mailing list
> > >> > CB> kepler-dev at ecoinformatics.org
> > >> > CB> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> > >> > _______________________________________________
> > >> > seek-dev mailing list
> > >> > seek-dev at ecoinformatics.org
> > >> > http://www.ecoinformatics.org/mailman/listinfo/seek-dev
> > >> >
> > FV> --
> > FV> Ferdinando Villa, Ph.D., Associate Research Professor,
> > Ecoinformatics
> > FV> Gund Institute for Ecological Economics and Dept of Botany, Univ. of
> > Vermont
> > FV> http://ecoinformatics.uvm.edu
> > _______________________________________________
> > kepler-dev mailing list
> > kepler-dev at ecoinformatics.org
> > http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> >
>
>
>
> **************************
> Dr. Deana D. Pennington
> Long-term Ecological Research Network Office
>
> UNM Biology Department
> MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM 87131-0001
>
> 505-272-7288 (office)
> 505 272-7080 (fax)
> _______________________________________________
> seek-dev mailing list
> seek-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
--
Ferdinando Villa, Ph.D., Associate Research Professor, Ecoinformatics
Gund Institute for Ecological Economics and Dept of Botany, Univ. of Vermont
http://ecoinformatics.uvm.edu
More information about the Seek-dev
mailing list