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

[Laura L. Downey]

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