[seek-dev] Re: [kepler-dev] scrollbar additions to kepler
Bertram Ludaescher
ludaesch at sdsc.edu
Wed Jul 28 06:57:55 PDT 2004
>>>>> "RS" == Rod Spears <rods at ku.edu> writes:
RS>
RS> The "best" is...
RS> Knowing thy user and what they "expect", usability is about expectation.
RS>
RS> For Bertram, the items below are the "best" for him, although as one
RS> might expect, they would be the "worst" for me in particular ;-)
really? I'm surprised -- I thought those were universal ;-))
Bertram
RS>
RS> Rod
RS>
RS>
RS> Bertram Ludaescher wrote:
RS>
>> 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
>>
>>
RS>
RS> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
RS> <html>
RS> <head>
RS> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
RS> <title></title>
RS> </head>
RS> <body bgcolor="#ffffff" text="#000000">
RS> The "best" is...<br>
RS> <br>
RS> Knowing thy user and what they "expect", usability is about expectation.<br>
RS> <br>
RS> For Bertram, the items below are the "best" for him, although as one
RS> might expect, they would be the "worst" for me in particular <span
RS> class="moz-smiley-s3"><span> ;-) </span></span><br>
RS> <br>
RS> Rod<br>
RS> <br>
RS> <br>
RS> Bertram Ludaescher wrote:
RS> <blockquote cite="mid16647.5845.998152.271555 at multivac.sdsc.edu"
RS> type="cite">
RS> <pre wrap="">I wonder how much effort it would be to have the different
RS> panning/scrolling modes be customizable user preferences.
RS>
RS> Also, there is plenty of evidence in the world that the "best"
RS> solution not always is the most widespread -- also sometimes "best" is
RS> a parameter of the user community, etc.
RS>
RS> To give a concrete example of my (strange) definition of "best":
RS>
RS> - best editor: (X)Emacs
RS> - best way to navigate and "say what you mean": keyboard
RS> (although I must say that I find Vergil quite nice!)
RS> - best XML syntax: Prolog syntax
RS> - best text processing system: LaTeX
RS> - best functional prog. language: Haskell
RS>
RS> just my $0.02 ;-)
RS>
RS> Bertram
RS>
RS>
RS> </pre>
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <pre wrap="">"CB" == Chad Berkley <a class="moz-txt-link-rfc2396E" href="mailto:berkley at nceas.ucsb.edu"><berkley at nceas.ucsb.edu></a> writes:
RS> </pre>
RS> </blockquote>
RS> </blockquote>
RS> </blockquote>
RS> </blockquote>
RS> </blockquote>
RS> <pre wrap=""><!---->CB>
RS> CB> Edward A Lee wrote:
RS> </pre>
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <pre wrap="">I'm a bit confused about the basic motivation here...
RS>
RS> A while ago, we had quite a bit of internal discussion about how
RS> to handle navigation, and we ruled out scrollbars because they
RS> make less sense for an infinite canvas... How do you intend
RS> the scrollbars to work? How do you choose the boundaries?
RS> </pre>
RS> </blockquote>
RS> </blockquote>
RS> <pre wrap=""><!---->CB>
RS> CB> In this prototype that i've been working on, i've been choosing the
RS> CB> boundaries to be the actual size of the model and resizing the
RS> CB> scrollbars dynamically as the size of the model increases. The canvas
RS> CB> is still infinite, but the viewport resizes (via the scrollbars) to
RS> CB> accomodate the model. Do you see a problem with this approach? The
RS> CB> other way I've seen applications do this is just to set the scrollbar
RS> CB> max to a very large value and position both the vert and horiz bars in
RS> CB> the middle of the range. It effectively makes the canvas finite, but is
RS> CB> anyone really going to create a model that's 2 miles x 3 miles? If they
RS> CB> did, I think we would accuse them of bad programming practice :)
RS> CB>
RS> </pre>
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <pre wrap="">The other question is about why you want scrollbars in the first place.
RS> Is it mainly to create a familiar feeling, or is there really
RS> a functionality issue? They take some of the real estate
RS> away from the drawing area... Maybe if you give the users some
RS> time with the panner they will get used to it and decide they
RS> like it after all...
RS> </pre>
RS> </blockquote>
RS> </blockquote>
RS> <pre wrap=""><!---->CB>
RS> CB> It seems like everytime we sit someone down with this they comment about
RS> CB> the lack of scrollbars for navigating the canvas. I personally have no
RS> CB> problem with the panner, but it's still nice to have a choice of how you
RS> CB> want to navigate the canvas. If you just want to move the view down a
RS> CB> little bit, it's much easier to click the down arrow on the scrollbar
RS> CB> than to move the panner a touch. The panner can be too touchy for
RS> CB> moving the view small amounts due to it's low resolution compared to the
RS> CB> canvas.
RS> CB>
RS> CB> Another idea is that instead of having the traditional scrollbar with a
RS> CB> slider, we could just use a set of 4 arrows to micomanage the canvas.
RS> CB> That way, if you want to nudge the canvas around the viewport by a few
RS> CB> pixels, you could just click the arrows instead of using the panner.
RS> CB> Without the scroll slider, the canvas would effectively remain infinite.
RS> CB>
RS> </pre>
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <pre wrap="">Photoshop, IMHO, is not a UI to emulate... But in any case, it
RS> always has a finite canvas size, so this is less of an issue.
RS> I think our infinite canvas is really much nicer for our purposes,
RS> since limiting to a "page size" makes no sense in our case.
RS> </pre>
RS> </blockquote>
RS> </blockquote>
RS> <pre wrap=""><!---->CB>
RS> CB> Photoshop and Illustrator both have a finite canvas, but that canvas can
RS> CB> be very big. I find the scrollbars to be very effective for navigation
RS> CB> on the canvas, especially when combined with the hand tool. Note that
RS> CB> you can quickly change to the handtool in Illustrator by holding down
RS> CB> the spacebar, which is quite convenient.
RS> CB>
RS> </pre>
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <pre wrap="">I agree with Steve that the major pitfall with the hand is
RS> that you have to set a "hand mode" for the UI to use it.
RS> It seems the prevailing "religion" in UI circles is that
RS> modal behavior is a bad thing... and it is a nuisance to
RS> have to be switching back and forth between modes...
RS> If you can find a way to do without modes (and within
RS> the Mac's one-button limitation), then that would be great.
RS> </pre>
RS> </blockquote>
RS> </blockquote>
RS> <pre wrap=""><!---->CB>
RS> CB> Personally, I don't see what the big deal is. I've been using modal
RS> CB> GUIs for a long time and have never had a problem with choosing a
RS> CB> navigation tool instead of a drawing tool. That said, I consider myself
RS> CB> an advanced user with most programs like this (i.e. Photoshop and
RS> CB> Illustrator). I'll try to figure out a way to do this...possibly with
RS> CB> a keyboard shortcut or something.
RS> CB>
RS> CB> chad
RS> CB>
RS> </pre>
RS> <blockquote type="cite">
RS> <blockquote type="cite">
RS> <pre wrap="">Edward
RS>
RS>
RS>
RS> At 10:47 AM 7/27/2004 -0700, Chad Berkley wrote:
RS>
RS> </pre>
RS> <blockquote type="cite">
RS> <pre wrap="">Hi,
RS>
RS> I've been working the last 4 days to add scrollbars to the vergil
RS> canvas. I've had limited success and I've run into a couple problems.
RS> I wanted to see what others thought of this before I continue.
RS>
RS> There are two different places where this functionality can be added.
RS> The first one (and probably the technically correct place) is in the
RS> Diva library. Diva is the library ptolemy uses to provide all of the
RS> graph editing functionality. Diva also provides the panner (the
RS> widget in the bottom left that allows you to move around the
RS> workspace). The second place this functionality can be added is to
RS> the Vergil gui classes.
RS>
RS> Placing the code in diva is probably the best way to do this because
RS> then it would integrate seamlessly into the current view and allow the
RS> scrollbars to interact with the panner. Changing Diva to do this is
RS> not trivial. Diva has it's own layer system built around AWT with
RS> some Swing components. Also, if we change diva, it's going to be much
RS> harder to make this a "pluggable" change without making some
RS> architectural change to diva itself.
RS>
RS> Placing the code in the BasicGraphFrame class of vergil is the most
RS> straight forward way to do it because the vergil gui uses all swing
RS> components and places diva widgets inside the swing components. This
RS> is the way I have partially implemented the scrollbars now (using a
RS> JScrollPane). There are several problems with this. First of all,
RS> getting the scrollbars to interact with the panner correctly seems
RS> mostly impossible. Basically, i have to remove the panner or else
RS> things get chaotic real quick. If the user moves the workspace via
RS> the panner, there is no event to catch when this happens, so the
RS> scrollbars can't be updated accordingly. I've also had to make major
RS> changes to the zoom code. The two advantages of doing it this way are
RS> that it's easier to code since one can work with only swing components
RS> and i think it will be easier to make this a pluggable change since
RS> some people have said they don't want scrollbars on the canvas.
RS>
RS> Another thing I thought of the other day while working with photoshop
RS> (which has scrollbars on it's canvas), is that we could add a "hand"
RS> tool which would serve one of the purposes of the panner (to let you
RS> move around the workspace). I like the panner and don't really want
RS> to get rid of it anyway. I think the panner, scrollbars and a
RS> potential hand tool would work well together. It's just a matter of
RS> figuring out the best way to do it. Ptolemy folks: how hard do you
RS> think it would be to add this to Diva?
RS>
RS> thoughts?
RS>
RS> chad
RS> _______________________________________________
RS> kepler-dev mailing list
RS> <a class="moz-txt-link-abbreviated" href="mailto:kepler-dev at ecoinformatics.org">kepler-dev at ecoinformatics.org</a>
RS> <a class="moz-txt-link-freetext" href="http://www.ecoinformatics.org/mailman/listinfo/kepler-dev">http://www.ecoinformatics.org/mailman/listinfo/kepler-dev</a>
RS> </pre>
RS> </blockquote>
RS> <pre wrap="">
RS> ------------
RS> Edward A. Lee, Professor
RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
RS> phone: 510-642-0455, fax: 510-642-2739
RS> <a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>, <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
RS> </pre>
RS> </blockquote>
RS> </blockquote>
RS> <pre wrap=""><!---->CB> _______________________________________________
RS> CB> kepler-dev mailing list
RS> CB> <a class="moz-txt-link-abbreviated" href="mailto:kepler-dev at ecoinformatics.org">kepler-dev at ecoinformatics.org</a>
RS> CB> <a class="moz-txt-link-freetext" href="http://www.ecoinformatics.org/mailman/listinfo/kepler-dev">http://www.ecoinformatics.org/mailman/listinfo/kepler-dev</a>
RS> _______________________________________________
RS> seek-dev mailing list
RS> <a class="moz-txt-link-abbreviated" href="mailto:seek-dev at ecoinformatics.org">seek-dev at ecoinformatics.org</a>
RS> <a class="moz-txt-link-freetext" href="http://www.ecoinformatics.org/mailman/listinfo/seek-dev">http://www.ecoinformatics.org/mailman/listinfo/seek-dev</a>
RS> </pre>
RS> </blockquote>
RS> <br>
RS> </body>
RS> </html>
More information about the Seek-dev
mailing list