[kepler-dev] [Bug 1845] - user input for port type should not be case sensitive
Shawn Bowers
sbowers at ucdavis.edu
Mon Dec 19 12:23:41 PST 2005
Laura L. Downey wrote:
> [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. ;-)
:-)
I think we have to be careful here, because there hasn't been enough
thought into why someone would want to do this. I don't think it will
make sense technically in most cases -- and those cases where it does,
the system can automate the type changes as needed (this is what
Ptolemy already does ...)
In terms of the user classification below, I think this is a great
start. We (the entire kepler project -- I'm not picking on you here)
need to be more specific about what the various user groups are, what
level of skill/training they will require, and what functionality each
should have ... which will directly influence the "intuitiveness" of
any graphical user interface we construct. This might be a good topic
to hammer out at the next Kepler meeting.
-shawn
> 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