[kepler-dev] kepler nightly builds

[Bertram Ludaescher]

Shawn Bowers writes:
 > 
 > Two comments/questions interspersed below.
 > 
...
 > 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.

I too tend to agree that the icon styles might be overly hot
debated. There are a bunch of other usability improvements that might
be as important or even more so .. but I guess we have to start somewhere.

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

I think the pendulum has now done a full swing in each direction:
too much color <--> too little color.

I think it should be easy to agree that carefully chosen color-coding
is a good thing. Laura's expertise in this area should help a
lot. Let's see how this evolves..

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

correct. that's what I meant. AVS/Express, SciRUN etc have also things
like that.. not a high priority item either but worth thinking
about.. 

B