[seek-dev] Re: [kepler-dev] scrollbar additions to kepler
Deana D. Pennington
dpennington at lternet.edu
Wed Jul 28 08:56:36 PDT 2004
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)
More information about the Seek-dev
mailing list