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

Laura L. Downey ldowney at lternet.edu
Tue Dec 20 07:13:44 PST 2005


Just as a note of clarification, I wonder if there was a bit of confusion
here as to the way I worded things about the case insensitivity (which is
basically moot now).  If so, my apologies for any confusion.

I never meant that something behind the scenes (the expression language)
should be changed to case insensitive, only was talking about user input
which I expected the system could "convert" etc without changing any of the
underlying expression language.

Anyway, we have solved the basic issue with a combo box of standard types
recognized by the system and we can say that if we decide to allow user
input of a custom type, it can be case sensitive, because at the point the
user is "creating" something, not trying to guess how the system might want
some input to match.  I'll add that to the bug.

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: Edward A. Lee [mailto:eal at eecs.berkeley.edu] 
Sent: Monday, December 19, 2005 9:21 PM
To: Laura L. Downey
Cc: 'Shawn Bowers'; kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] [Bug 1845] - user input for port type should not
be case sensitive


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  




More information about the Kepler-dev mailing list