[seek-dev] Re: [kepler-dev] scrollbar additions to kepler
Chad Berkley
berkley at nceas.ucsb.edu
Wed Jul 28 10:14:42 PDT 2004
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
More information about the Seek-dev
mailing list