[kepler-dev] Icons in the *DataSource actors

Dan Higgins higgins at nceas.ucsb.edu
Mon Jan 9 14:09:36 PST 2006

    I am not sure that 'blinking' is a good idea. You know that any 
blinking on a web page is 'hated' by many people. We already have 
workflows with 10 data sources. They take a long time to finish 
downloading. Having 10 blinking icons would be very distracting.



Laura L. Downey wrote:

>Ah okay, now I understand what you meant about the states changing.  I
>haven't seen the "error" condition so don't know what that looks like.  But
>my natural assumption would have been red would indicate an error condition
>and currently red just indicates "getting data but not done."
>The easiest and quickest solution might be to just "blink" the data source
>icon (the manilla folder) until the data was downloaded then it becomes
>solid and non-blinking upon completion of data downloading.  And if an error
>occurred we could superimpose an X or some other simple sign on top of a
>non-blinking data source -- I wouldn't want to obscure the label though so
>the user could still see what the name of the data set/file was they were
>unsuccessful at retrieving.
>This solution could work in either option of the current design where data
>is downloaded when it is dragged from the left pane or if we go with the
>option of data not downloading until the workflow executes, the same
>blinking could apply.  The highlighting of which actor the workflow is
>currently executing could still be shown with the blinking orange highlight.
>In the case of the datasource and the highlight both blinking they would
>just need to be in sync so as not to create some crazy alternate blinking
>that would bother people.
>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: Matthew Brooke [mailto:brooke at nceas.ucsb.edu] 
>Sent: Monday, January 09, 2006 2:41 PM
>To: Laura L. Downey
>Cc: 'Kevin Ruland'; 'Kepler-Dev'
>Subject: Re: [kepler-dev] Icons in the *DataSource actors
>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?
>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
>>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?
>>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 
>>>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.

More information about the Kepler-dev mailing list