[seek-dev] Re: [kepler-dev] scrollbar additions to kepler
Deana D. Pennington
dpennington at lternet.edu
Wed Jul 28 10:30:12 PDT 2004
my mistake...scratch that comment
Quoting Chad Berkley <berkley at nceas.ucsb.edu>:
> Kepler already has a zoom function. There are 4 buttons on the
> toolbar...zoom in, zoom out, zoom fit and zoom reset.
>
> chad
>
> 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
> _______________________________________________
> 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)
More information about the Seek-dev
mailing list