[kepler-dev] kepler nightly builds
ludaesch at ucdavis.edu
Thu Mar 17 13:29:46 PST 2005
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
More information about the Kepler-dev