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

Laura L. Downey ldowney at lternet.edu
Mon Dec 19 12:15:18 PST 2005


See comments below.

Laura

====================================
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.

Shawn:
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.

[LLD>] No I'm saying that the way people think is not literal like computers
but that the concept of specifying data in a different format is not hard to
grasp.  And of course if you sat there and told a user, double and Double
are two different things they would get it, but probably wonder why they are
two different things.  But their expectation is that Double and double mean
the same thing -- just like in regular English language.  Does this make it
any more clear? I have no more words. :-)

BTW, I think you are being a real computer scientist here Shawn. ;-)


Shawn:
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.
[LLD>] No real argument here.  I asked the same question when I first got
here and it is one of the reasons I've been doing the user profiling is to
get more of a handle on this.  I've begun to think of the users broken down
into how they will use Kepler based on their technical expertise so we will
have:
1. users that run existing models (scientists with no programming)
2. users that run existing models with other data (scientists with no
programming)
3. users that make minor modifications to models, like adjusting a few data
types, or substituting a different algorithm (scientists with no programming
but get the concept of data formats or just hooking up a different algorithm
in the middle of a workflow)
4. users that create simple models (understand the basics of how to put
things together but maybe only have minimal programming skills)
5. users that create complex models which can include building custom actors
(and these will be the programmers)

-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