[seek-dev] Re: [kepler-dev] scrollbar additions to kepler

Ferdinando Villa ferdinando.villa at uvm.edu
Wed Jul 28 06:52:22 PDT 2004


Despite agreeing with Bertram's list at least 80% (that Prolog bit...),
let's not forget that the key to widespread adoption has never been
configurability... it's the instant likeability/intuitiveness of the
product (closely related to simplicity and the absence of things like
green boxes with no visual purpose or trees of objects with strange
names). It's just like with people - except that software rarely gets a
second chance... ok, people neither...

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
> >   
-- 
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