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

[Shawn Bowers]

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