[kepler-dev] [Bug 1845] - user input for port type should not be case sensitive
Shawn Bowers
sbowers at ucdavis.edu
Mon Dec 19 11:59:32 PST 2005
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.
It's seems like a really small point ... but maybe I am wrong: You
seem to be saying that because people aren't experienced with java, c,
c++, fortran, etc., but understand the notion of data types, they
won't understand that data types can be case-sensitive.
>
> 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.
I was looking for a concrete use case, i.e., some discussion of real
examples. You said a user might *want* to do this ... but I want to
see specifically *why* they would and some details concerning (1) when
technically this makes sense (to change a data type), and (2) a
concrete use case under which something like this is needed
.... w.r.t. the user base you are thinking of.
I think in Kepler there is significant confusion about who actually
are the users we are targeting ... and this situation has plagued us
for a long time now.
-shawn
>
> 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
>
More information about the Kepler-dev
mailing list