[seek-dev] Re: [kepler-dev] scrollbar additions to kepler
Bertram Ludaescher
ludaesch at sdsc.edu
Wed Jul 28 08:32:15 PDT 2004
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
More information about the Seek-dev
mailing list