[kepler-dev] Icons in the *DataSource actors

Laura L. Downey ldowney at lternet.edu
Mon Jan 9 14:22:55 PST 2006


If the downloading takes some huge amount of time then blinking may not be a
good idea.  And of course we don't want 20 different things blinking at the
same time either.  People don't hate blinking per se, they hate unnecessary
or decorative continual blinking and animation on web pages and in
applications.  But blinking is used quite a lot as an attention getter in
lots of military applications and things like FAA apps (I worked on several
FAA apps and there are specific design guidelines for when to use blinking
and what rate etc.).  It is also used to indicate downloading and processing
is occurring.  Progress bars are used for this also.

All that said, we have other design choices here.  I was just thinking that
blinking would be the easiest and quickest to code things if we weren't
talking about huge download times, and blinking an existing icon without
having to add other visual elements is a quick solution.  Blinking or
animation is certainly used to indicate that processing is occurring.  It
just needs to be used correctly and in the right situations.

If download times take too long, then we can use other methods like the
superimposing or adding of other symbols/text adjacent to the data sources
etc.

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: Dan Higgins [mailto:higgins at nceas.ucsb.edu] 
Sent: Monday, January 09, 2006 3:10 PM
To: Laura L. Downey
Cc: 'Matthew Brooke'; 'Kepler-Dev'
Subject: Re: [kepler-dev] Icons in the *DataSource actors

Laura,
    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.

Dan

---

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?
>
>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
>>>
>>>
>>>      
>>>
>
>  
>





More information about the Kepler-dev mailing list