[kepler-dev] kepler nightly builds

Laura L. Downey ldowney at lternet.edu
Thu Mar 10 08:11:25 PST 2005


Hi Bertram, 

Good comments.  Several of them I believe I have already addressed to some
extent.  When I first began reviewing Kepler from a human factors
perspective I noted a number of visual language issues:

Lots of bright colors drawing the eye
Lots of meaning for colors
Lots of various shapes
Sometimes color was the only clue (no redundancy)
Certain level of busy-ness happening in the workflow objects
Different sizes
Not enough contrast between workflow objects and background
Mixture of 2-D vs. 3-D representations
No real color scheme or cohesive visual language
Lots of royal blue writing (blue fuzzes around the edges and is harder to
read)

Most of these I talked about at the KU meeting last October where I proposed
a re-vamping of the visual language.  My goal was/is to develop a cohesive
visual language and to address all of these design issues dealing with
contrast, color meaning, icon representation, encoding etc.

One common mistake that is often made is to try and encode too many things
into a symbol or to use too many symbols or colors to represent too many
different things.

I completely agree with you that we need a high level set of categories for
symbol representation because there is no way people are going to remember
50 different symbols and we don't want to introduce more visual complexity
and clutter.  The icon/actor labels will represent the finer grained meaning
of an icon so the symbol can be generic.  Right now after talking with Dan
and Chad earlier this year and also Deana, I've come up with about 12 high
level categories -- that may need to be tweaked some.  I also agree about
the local vs. remote issue and have been thinking of a few simple ways to do
that without introducing more color or encoding schemes -- but just some
simple indicator like an asterisk next to the name.

Good HF principles indicate no more than about 6-7 different color meanings
so there is no way we could use color as a major differentiator (nor would
we want to because color should never be the only differentiator).  As fas
as meanings go, we will already be using red for stop, blue-green for
run/go, yellow/orange for highlighting, black for single (ports), white for
multiples (ports), and I'm proposing the actors will have the same color
with a different high level symbol on them.

I've been working with the graphic designer now for about 6 weeks and we are
almost done preparing a set of proposals.  I really wanted to be able to
present this stuff to the team all at one time and in a finished state and
the original plan was to do so in May but now that has been pushed back to
the Kepler developer's meeting in June.  

However, since people seem interested in the details, in the interim, I've
put the composite Matt was referring to in CVS in the usability directory.
It isn't complete but it will give you a general idea of what will be
proposed.  It is just a made up workflow to show some symbols.  The file is
named:  KEPLER_v6_BrightTeal_TealDi.png.  BTW, the plan is/has always been
to get input and feedback from the team before any final decisions are made.

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: Bertram Ludaescher [mailto:ludaesch at ucdavis.edu] 
Sent: Thursday, March 10, 2005 7:30 AM
To: Matt Jones
Cc: ldowney at lternet.edu; Kepler-Dev
Subject: Re: [kepler-dev] kepler nightly builds


Matt, Laura:

I didn't see the "composite" that is being referred to below. 

We had been discussed the need for a "systematic" Kepler "icon-style"
quite a while back, but didn't actually do it...

My suggestion would be to use the various "dimensions" of icons:
- icon shape 
- icon borderline color (and borderline thickness)
- icon "inner color"
- icon "inner text" or "sub-icon" (e.g. the file reader/write has a
"folder subicon")

.. in a systematic (and yes, intuitive of course ;-) way to indicate
what type of actor we are looking at. However, this design needs to be
informed also by a high-level classification of actor types. 
Unlike the recently introduced a "dynamic actor classification" (the
actor search tab extensions by Shawn and Chad), here we want a
somewhat static world view.. so we should think carefully what the
actor dimensions are.

Ptolemy had some classifications such as "source" vs "sink" (e.g
displays).

We might have distinctions between:
- interactive (browserUI) vs. non-interactive actors (a big difference)
- local vs. remote executing actors (e.g. web service and SSH2 are
remote while most others are local; some you don't know
(command-line))
- high-level classifications are also useful, e.g.,
-- data analysis actors (all R functions!?) vs.
-- visualization actors (e.g. imported from SciRUN) vs.
-- database style query actors (JDBC/SQL queries, XQuery actors, XPath
actor)
-- datatranslation actors (XSLT)

etc.

I think we should also discuss these issues before coming up with a
final design..

Bertram

Matt Jones writes:
> Thanks, Laura.  This composite looks great.  The icons are all solid
> colors and simple lines, so they should be able to be represented in the
> simplified SVG that ptolemy supports.  Getting them into that format
> might not be easy, however.  Illustrator, for example, makes extensive
> use of SVG 'path' elements and group ('g') elements when writing out
> SVG, which ptolemy doesn't support.  But we can get the developers to
> get that stuff fixed, probably at a minimum creating a conversion
> script.  It looks to me like we should be able to use the same SVG for
> the canvas and the tree because they should scale ok.  I'm moving this
> conversation onto the list so that the other Kepler developers are aware
> of the issues.
> 
> Matt
> 
> Laura L. Downey wrote:
> > Okay, here's one comp that shows the basic color scheme with a few
actors
> > (this is just a made up workflow).  There are still some changes to be
made
> > but this will give the general idea.
> > 
> > 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: Matt Jones [mailto:jones at nceas.ucsb.edu] 
> > Sent: Monday, March 07, 2005 12:21 PM
> > To: Laura L. Downey
> > Subject: Re: illustrator svg settings
> > 
> > composites would be fine.  Like i said before i'd like to glance at what

> > you have anyways.
> > 
> > Matt
> > 
> > Laura L. Downey wrote:
> > 
> >>Oops... guess I'm trying to read too fast these days.  You said gifs are
> >>fine but again I only have composite images -- not any individual stuff.
> >>I've just emailed the graphic designer though to get some.
> >>
> >>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: Matt Jones [mailto:jones at nceas.ucsb.edu] 
> >>Sent: Monday, March 07, 2005 11:56 AM
> >>To: Laura L. Downey
> >>Subject: Re: illustrator svg settings
> >>
> >>Laura,
> >>
> >>Could you send me some example images (gif is fine).  I should be able 
> >>to get a sense of whether they will work using the SVG subset that 
> >>ptolemy supports based on looking at some representative icons.  If they

> >>won't work that way, then I'll think about how to handle this.  Thanks,
> >>
> >>Matt
> >>
> >>Laura L. Downey wrote:
> >>
> >>
> >>>Thanks.  I'll pass these along to the graphic designer.
> >>>
> >>>As I just said on IRC, I'm a bit worked that the few primitives
supported
> >>>won't let use some of the symbology we've developed even though it is
> >>
> >>really
> >>
> >>
> >>>basic.  I don't like complexity in visual language but some detail is
> >>>necessary and bit more than just fundamental shapes etc.  But I'll
guess
> >>>I'll find out when I get the final SVGs and try to display them 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: Matt Jones [mailto:jones at nceas.ucsb.edu] 
> >>>Sent: Monday, March 07, 2005 10:45 AM
> >>>To: ldowney at lternet.edu
> >>>Subject: illustrator svg settings
> >>>
> >>>Laura,
> >>>
> >>>I think these settings will get you a valid svg file.  You can test it 
> >>>by opening it in Batik Squiggle or another SVG app.   You may need to 
> >>>tweak the settings even further, but i'm not sure.  Be sure to test.  I

> >>>think there are also some W3C validation services.
> >>>
> >>>A valid SVG file isn't enough though.  We need to be sure to only use 
> >>>the SVG features that ptolemy supports.  For example, I don't think 
> >>>ptolemy supports gradients.
> >>>
> >>>Matt
> >>
> >>
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> 
> -- 
> -------------------------------------------------------------------
> Matt Jones                                     jones at nceas.ucsb.edu
> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
> National Center for Ecological Analysis and Synthesis (NCEAS)
> University of California Santa Barbara
> Interested in ecological informatics? http://www.ecoinformatics.org
> -------------------------------------------------------------------





More information about the Kepler-dev mailing list