[kepler-dev] Data Source Design Flaw; was: Icons in the *DataSource actors
Laura L. Downey
ldowney at lternet.edu
Tue Jan 10 08:06:20 PST 2006
I think this is an excellent point Bertram. I didn't realize that we have
other actors that will have similar issues. As with a similar technical
methodology for dealing with the issues raised here, we should have a
similar way the interface communicates with the user for these actors with
different states or instantiation etc.
I'm not sure what you all are suggesting about adding a button somewhere,
but we could certainly add a menu item to deal with this and of course it
could be in the right click menu too and only available in context if
someone clicks on an actor that needs instruction to get data, instantiate,
get port signatures etc.
This sounds like a good candidate to discuss at the Kepler dev meeting in
Feb.
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 Bertram
Ludaescher
Sent: Tuesday, January 10, 2006 8:41 AM
To: Jing Tao
Cc: 'Kepler-Dev'
Subject: [kepler-dev] Data Source Design Flaw;was: Icons in the *DataSource
actors
Dan, Jing:
Your discussion (and resolution) is an important one. As has been
noted before, the current/previous behavior of immediately downloading
data sources as they are dragged and dropped on the canvas is a design
flaw, since it prevents management of large data sources via the EML
source actor.
Despite your discussions have shed light on the matter and improved
the previous situation, I'm not sure the problem has been completely
resolved. At least, I think we should document the different "stages"
and phases that exist with EML sources. Similar phases could be
adopted with other sources.
The overall problem is that at *design time*, a WF designer might not
want (or have) access to remote data/metadata. Of course the challenge
is that if no such info is available, we cannot know the ports and
thus such an actor is not that helpful during design either.
Nevertheless, a staged approach seems useful. Maybe we need a button
somewhere to "instantiate" or "get (port) signature" or sth similar
for a certain type of actors. The EML source actor is one example.
The Web service actor is a similar example (its signature is known
only after retrieving the WSDL).
I think we should generalize and elevate this behavior to a general
method how we deal with such "morphing" actors (i.e., which change
their port signature/interface as the go from "uninstantiated" to
"instantiated" ..)
Bertram
>>> On Mon, 9 Jan 2006 17:06:49 -0800 (PST)
>>> Jing Tao <tao at nceas.ucsb.edu> wrote:
JT>
JT> Hi, Dan:
JT> This is possible solution. But it maybe make this button response time
too
JT> long if there is no cache for the metadata.
JT>
JT> In eml datasource actor, attributeChange method will trigger metadata
JT> download(no matter you open a existed workflow or drag a search result
to
JT> cavas) and when metadata download finished the metadata will be parsed
by
JT> eml parser. During the parsing, the data url will be digisted and
JT> downloaded into local system. So my suggestion is attributeChange only
JT> trigger metacat downloading, but not parse it. The parsing process will
be
JT> moved to initialize method. After that, when you open a workflow, only
JT> metadata download, but data download will happend in execution.
JT>
JT> Jing
JT>
JT>
JT>
JT> Jing Tao
JT> National Center for Ecological
JT> Analysis and Synthesis (NCEAS)
JT> 735 State St. Suite 204
JT> Santa Barbara, CA 93101
JT>
JT> On Mon, 9 Jan 2006, Dan Higgins wrote:
JT>
>> Date: Mon, 09 Jan 2006 15:23:12 -0800
>> From: Dan Higgins <higgins at nceas.ucsb.edu>
>> To: Jing Tao <tao at nceas.ucsb.edu>
>> Cc: Matthew Brooke <brooke at nceas.ucsb.edu>,
>> 'Kepler-Dev' <kepler-dev at ecoinformatics.org>
>> Subject: Re: [kepler-dev] Icons in the *DataSource actors
>>
>> Jing,
>> Good Point.
>>
>> Maybe we could have the 'GetMetadata' button method download the metadata
>> if it has not been cached?
>>
>> Dan
>>
>> Jing Tao wrote:
>>
>>> Hi, Dan:
>>>
>>> I agree with you that move the data download process from
attributeChange
>>> to initialize will speed up the opening of workflow. But I have a
comment
>>> about this:
>>>
>>> Note that we also need to consider what happens when someone loads
>>> an existing workflow with datasource actors for the first time.
>>> Currently, the data and metadata is downloaded when such an existing
>>> workflow is first opened, just as if it was dragged from the actor list.
>>> In this case, we wouldn't even need to get the metadata immediately
>>> since all the ports should be described in the associated MOML. So maybe
>>> we can put off all the downloading until workflow execution.
>>>
>>>
>>> I think we still need metadata immeidately in this senario, otherwise
the
>>> "Get Metadata" button in datasource actor will fail.
>>>
>>> Jing
>>>
>>>
>>>
>>>
>>>
>>> Dan
>>>
>>> ---
>>>
>>> Matthew Brooke wrote:
>>>
>>>>> Laura (also Kevin & Dan) -
>>>>>
>>>>> Sorry - the states that I know about are 'busy' (currently red),
'ready'
>>>>> (currently yellow) and 'error' (currently pink). Not sure if there are
>>>>> any more.
>>>>>
>>>>> I also think I recall seeing a discussion on IRC or by email about
>>>>> having the datasources *not* get their data before the workflow is run
-
>>>>> was that conversation between Dan and Kevin? Can either of you guys
>>>>> summarize what you decided?
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>> Laura L. Downey wrote:
>>>>>
>>>>>
>>>>>> Before I make a recommendation I'd like to understand what "states"
>>>>>> these
>>>>>> icons have to display?
>>>>>>
>>>>>> And it does seem a bit unusual to me to have processes doing
something
>>>>>> when
>>>>>> the user hasn't instructed the workflow to execute. But I'm not
>>>>>> familiar
>>>>>> with these specific actors or the specific workflow you are
referencing.
>>>>>>
>>>>>> Is it some kind of polling thing?
>>>>>>
>>>>>> On a general note, I pretty much agree with Matthew's suggestion of
>>>>>> having
>>>>>> the icons fit in with the general scheme then doing something else to
>>>>>> indicate state changes (highlighting, superimposing, putting some
symbol
>>>>>> above or below that indicates state change etc.) There are a variety
of
>>>>>> ways we might do this.
>>>>>>
>>>>>> 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 Matthew
>>>>>> Brooke
>>>>>> Sent: Monday, January 09, 2006 2:16 PM
>>>>>> To: Kevin Ruland; kepler-dev at ecoinformatics.org
>>>>>> Subject: Re: [kepler-dev] Icons in the *DataSource actors
>>>>>>
>>>>>>
>>>>>> Kevin -
>>>>>>
>>>>>> I'd noticed (and ignored ;-) the eml200datasource actor; I agree with
>>>>>> you that it's not visually compatible with the new icon scheme, and
had
>>>>>> meant to discuss it with Laura.
>>>>>>
>>>>>> I'm wondering if a better way to do this would be to use an assigned
>>>>>> icon that doesn't change, but then the actor superimpose something on
>>>>>> top of it that gives the user some feedback on status/progress
(instead
>>>>>> of switching out the entire icon or changing its color).
>>>>>>
>>>>>> This way, the background icon would always "fit" with the color
scheme,
>>>>>> and if the icons change in future, we probably won't need to change
>>>>>> anything specifically for these actors, since they are superimposing
>>>>>> their "status message" on top of the icon.
>>>>>>
>>>>>> Laura - do you have any comments?
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kevin Ruland wrote:
>>>>>>
>>>>>>
>>>>>>> Matthew, et al
>>>>>>>
>>>>>>> Both Eml200DataSource and DarwinCoreDataSource actors have hard
coded
>>>>>>> icons. They are not exactly using the same code but it looks like
one
>>>>>>> was cribbed from the other. They set the folder shape, then make
calls
>>>>>>> to control color/text changes to indicate state.
>>>>>>>
>>>>>>> Since the icon system is/has gone through a major overhaul, I would
>>>>>>> like
>>>>>>> to discuss how we can get compatible icons for these actors. I
think
>>>>>>> it
>>>>>>> is still good for them to be able to control some indication of
state
>>>>>>> since they do perform background tasks even when the workflow is not
>>>>>>> running.
>>>>>>>
>>>>>>> BTW - by "compatible" I mean in the visual sense. These icons are
very
>>>>>>> boxy and the colors are much too vibrant -- they would look horrible
>>>>>>> with the new icons.
>>>>>>>
>>>>>>> Kevin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>
>>>
>>
>>
>>
>>
JT> _______________________________________________
JT> Kepler-dev mailing list
JT> Kepler-dev at ecoinformatics.org
JT> 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