[kepler-dev] [Bug 1845] - user input for port type should not be case sensitive

Mon Dec 19 20:20:49 PST 2005

I agree with Laura that the basic issue is to provide some guidance
to the user, and providing a combobox does that...

That said, I don't think we really need the state designations
to be case insensitive... I would prefer we not do that just
to maintain consistency with the expression language, where
case matters... Throughout Ptolemy II, case matters...
It's better to be consistent than to be right
(just witness our current president ;-).

Edward

At 12:47 PM 12/19/2005 -0700, Laura L. Downey wrote:
>No I don't think it contradicts things at all Shawn.  I think people can
>understand the concept of data formats without knowing how to write a
>program in Java.
>
>I don't know any other way to say it.  You asked for some examples and I
>gave you some off the top of my head.
>
>But even so, the issue is basically solved with providing a combo box with a
>standard set of data types recognized by the system and the ability to enter
>a custom data type.
>
>Laura L. Downey
>Senior Usability Engineer
>LTER Network Office
>Department of Biology, MSC03 2020
>1 University of New Mexico
>Albuquerque, NM  87131-0001
>505.277.3157 phone
>505.277-2541 fax
>ldowney at lternet.edu
>
>
>-----Original Message-----
>From: Shawn Bowers [mailto:sbowers at ucdavis.edu]
>Sent: Monday, December 19, 2005 12:43 PM
>To: Laura L. Downey
>Cc: kepler-dev at ecoinformatics.org
>Subject: Re: [kepler-dev] [Bug 1845] - user input for port type should not
>be case sensitive
>
>Laura L. Downey wrote:
> > I think there are plenty of scientists that grasp the concept of a data
>type
> > and may want to change a port from one data type to another to reuse an
> > actor or may want to specify one particular data type on a port that takes
> > various kinds of data types.  And I don't know that they need extensive
> > programming experience to do this.  Certainly though people writing and
> > creating actors from scratch or significantly modifying complex composites
> > will need considerable programming experience.
>
>Doesn't this contradict what you said before?  I'm not getting a clear
>picture of what the use case is ... and what level of expertise we are
>or aren't assuming.
>
>Also, why would someone need to change the data types and when would that
>make sense?
>
>-shawn
>
>
>
>
> >
> > Also there will be tutorials on building simple workflows in which
> > scientists with little or no programming experience will be following
> > instructions and will specify data types.
> >
> > Laura L. Downey
> > Senior Usability Engineer
> > LTER Network Office
> > Department of Biology, MSC03 2020
> > 1 University of New Mexico
> > Albuquerque, NM  87131-0001
> > 505.277.3157 phone
> > 505.277-2541 fax
> > ldowney at lternet.edu
> >
> >
> > -----Original Message-----
> > From: Shawn Bowers [mailto:sbowers at ucdavis.edu]
> > Sent: Monday, December 19, 2005 12:19 PM
> > To: Laura L. Downey
> > Cc: 'Edward A. Lee'; kepler-dev at ecoinformatics.org
> > Subject: Re: [kepler-dev] [Bug 1845] - user input for port type should not
> > be case sensitive
> >
> >
> > Laura,
> >
> > I'm a bit confused here in terms of who you are referring to as
> > the Kepler "users".
> >
> > Why would someone without any programming experience, etc., be
> > specifying actor input/output data types? Are you thinking of
> > a particular use case?
> >
> > -shawn
> >
> > Laura L. Downey wrote:
> >> The original issue was a user typing "Double" and then not knowing that
> > the
> >> system wanted "double" so they had no clue whatsoever what was wrong with
> >> their entry since there was no indication what the system expected.
> >>
> >> A major portion of our Kepler users are not programmers and coders so
>they
> >> aren't going to be thinking in terms of C, Java, Fortran etc. and most
> >> likely not in the exact literal sense.  If for example I as a user want
>to
> >> use the standard shortcut mmemonic for navigating large drop down boxes
> > and
> >> I type D or d, usually that mnemonic will take me to the first occurrence
> > of
> >> D or d, the capitalization is not the focus, but the letter itself is.
> > The
> >> word might be listed as double or Double but all I know is I wanted to
> >> choose the "double" type regardless of a capital D or not.
> >>
> >> But I think most of that is moot now anyway.  I think with the addition
>of
> >> the combo box, and a set of standard items to choose from, we've
>basically
> >> dealt with most of the problem here.
> >>
> >> As an aside, in usability we have these discussions all the time on how
>to
> >> do sort orders in tables and lists etc so they make sense to the users.
> > One
> >> of the things some usability people do is make everything either all
> >> uppercase, all lowercase, or initial caps so then users don't have to
> > figure
> >> out how to navigate a list based on literal interpretations and the way
> >> computers interpret a D or a d for example.
> >>
> >> Laura L. Downey
> >> Senior Usability Engineer
> >> LTER Network Office
> >> Department of Biology, MSC03 2020
> >> 1 University of New Mexico
> >> Albuquerque, NM  87131-0001
> >> 505.277.3157 phone
> >> 505.277-2541 fax
> >> ldowney at lternet.edu
> >>
> >>
> >> -----Original Message-----
> >> From: kepler-dev-bounces at ecoinformatics.org
> >> [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Edward A. Lee
> >> Sent: Monday, December 19, 2005 11:39 AM
> >> To: kepler-dev at ecoinformatics.org
> >> Subject: Re: [kepler-dev] [Bug 1845] - user input for port type should
>not
> >> be case sensitive
> >>
> >>
> >> Types are specified in Ptolemy II as "prototypes". That is, a type
> >> is given by giving an expression that resolves to the type.
> >> Hence, "double" is actually a variable named "double" with value
> >> 0.0.  The expression evaluator will confirm this...
> >>
> >> The expression language in Ptolemy II is case sensitive.
> >> As in Java, C++, and every other programming language since Fortran,
> >> variable names are case sensitive. Foo is not the same variable as
> >> foo.
> >>
> >> So if you really want "double" and "Double" to evaluate to the same
> >> thing, the right way to do this is to define two variables.
> >>
> >> As a general rule, giving users multiple ways to specify the same
> >> thing is not necessarily good.  It makes it hard for people to read
> >> each other's work. If I always use "double", then I will be puzzled
> >> when I see a workflow that uses "DOUBLE", and I will wonder if it
> >> means something different...  So I'm not sure I understand
> >> the basic philosophy here...
> >>
> >> Edward
> >>
> >> At 08:06 AM 12/19/2005 -0800, bugzilla-daemon at ecoinformatics.org wrote:
> >>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1845
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ------- Additional Comments From ldowney at lternet.edu  2005-12-19 08:06
> >> -------
> >>> The issue here involves a couple of different things.
> >>>
> >>> 1.  when first tested, the user had to exactly type something in for the
> >>> system to recognize it.  That is way too much burden on the user.  I
>very
> >
> >>> much
> >>> doubt there are many users that really want to assign string and STRING
> > to
> >> be
> >>> two different types! :-)
> >>>
> >>> 2.  the second issue is that a set of common data types should be
>offered
> >> to
> >>> the user so they don't have to type at all if they are choosing a
> > standard
> >>> type.
> >>>
> >>> 3.  it should really be a combo box so a user can indeed add/specify a
> > type
> >>> that is not part of the standard set (I can't remember where but I wrote
> > a
> >>> bug
> >>> that talked about using combo boxes where possible in whatever situation
> > we
> >>> had that there was generally a standard set of choices but also allows
> > for
> >>> customization by the user.  And if a user created a new type for example
> >>> called String, then for that user String should subsequently show up as
>a
> >>> choice.  We could also consider allowing users to "globally" add new
> > types
> >> so
> >>> they are available for other users.)
> >>> _______________________________________________
> >>> Kepler-dev mailing list
> >>> Kepler-dev at ecoinformatics.org
> >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> ------------
> >> Edward A. Lee
> >> Professor, Chair of the EE Division, Associate Chair of EECS
> >> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> >> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> >> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> >>
> >> _______________________________________________
> >> Kepler-dev mailing list
> >> Kepler-dev at ecoinformatics.org
> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >>
> >> _______________________________________________
> >> Kepler-dev mailing list
> >> Kepler-dev at ecoinformatics.org
> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >
>
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  