[kepler-dev] kepler nightly builds

[Shawn Bowers]

Two comments/questions interspersed below.

Matt Jones wrote:
>> What would help is some coloring scheme to indicate different
>> functions (as outlined previously). In fact actor annotations could be
>> used to automatically derive some icon display styles. Here are again
>> a few different types of actors:
>> - data transport (Sput, Sget, GridFTP, ...)
>> - data transformation (XSLT, Perl, ..)
>> - querying (SQL, XQuery, ...)
>> - statistical functions (R family of actors)
>> - display family of actors
>> - scientific visualization actors (big time rendering stuff)
>> - ...  
>>
> I think a functional classification of the actor icons is a great idea.  
> The classification into categories that Chad did might be a good first 
> start.  However, I also agree with Laura that *too much* variability in 
> the icons becomes cluttered, so we need a happy middle.  So, it strikes 
> me that 1) all icons should share a base visual design (e.g., the 
> rounded green rectangle), and that each functional class will have a 
> standard decoration that is meaningful to the class (e.g., all display 
> actors might have an unobtrusive monitor).  The hard question is whether 
> each distinct actor should have its own even further specialized icon.  
> For example, the XY plot actor might have a scatterplot on the monitor, 
> while the Display actor might have a representation of "text".  This 
> could easily be too busy, so I think Laura will need to give her best 
> estimate of where the break point between 'too abstract' and 'too busy' 
> really falls, and we can iterate of some opinions on that.  One downside 
> of the generic structures for the icons is that we can't do some of the 
> specialized views as in the boolean switch actor where the ports into 
> and out of the actor integrate into the icon itself.  But the 
> consistency of the icons is mor eimportant I think.

What exactly is the problem with the current icons? It seems like folks 
are saying they are "too busy" or that a workflow can get too 
"cluttered" ... but what does that mean?  I guess to me it isn't really 
clear that there are any problems with the icons now -- other than there 
isn't a general style or "skin" for the icons. But, is that really a 
high priority item? Maybe someone could clarify this.

One problem I see with not using color (i.e., every icon has the same 
color) is that it starts to look really boring and becomes hard to 
differentiate icons.  For example, what if every NFL or NBA team had the 
same colors, but just different symbols?  ... or every icon in windows 
was the same color ...

>> - ports could be color coded (and larger), color indicating the type
>> of data going through a port (that's a whole bigger discussion). But
>> the idea is that the color code would indicate what ports can *in
>> principle* be connected, based on the data type of the port (there are
>> some tricky technical issues, not least the polymorphic type system)
>>  
>>
> i htink you're probably right, but we need some concrete examples of 
> semantic data types to get an idea of how this would work.  If the port 
> annotations result in hundreds or thousands of possible port colors then 
> this clearly won't work.  If on the other hand there are some basic 
> types (say, < 10 total states), the visual port icon change might work.

I don't think "semantic data types" are what Bertram is referring to 
here. The ptolemy type system is fairly complex, but has only a fixed 
set of type constructors -- including basic types like ints and strings, 
and complex types like records/arrays and lists.  So, you might look 
over the Ptolemy type system to get an idea of the "states" available.

By semantic data types, i think you are meaning "semantic types" and for 
those you'd need to look at ontologies developed, or the current 
workflows developed to get an idea of those.


Shawn