[kepler-dev] kepler nightly builds
Bertram Ludaescher
ludaesch at ucdavis.edu
Thu Mar 17 09:10:50 PST 2005
Hi Laura:
Some comments on icons etc interspersed below -- and then some more
general comments, dealing with other, possibly even more burning
usability issues...
Laura L. Downey writes:
> 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)
Those are all good findings and should be fixed. We have to keep in
mind though that (unlike probably in Ptolemy II) in Kepler we never
had come up with a uniform icon style. So there has been chaos all
along ;-) So we need some guidelines, principles, and conventions on
how to design and "decorate" icons. I am a big believer in "form
follows function". After earlier experiences with some icon designs I
found that *naming* actors is actually a really good way to have a
simple and consistent way of doing it (although it's a bit counter to
the idea of an icon I admit). But the "XSLT" actor and the family of
"SRB" actors (Sput, Sget, ..) and many others are best represented by
icons displaying that name (XSLT, Sput, etc)
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)
- ...
then there are many different "properties" of actors which might
sometimes affect the rendering (or create an adornment) -- examples:
- a "traffic light" (red, yellow, green) indicating the "activity
level" (stalled, firing slowly, firing quickly; traffic light "off"
could mean not invoked yet) of an actor (should work in particular
well with PN director which currently does not allow animated
execution")
- 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)
there are also a bunch of other usability issues that should be considered:
- shouldn't double-clicking a composite actor do a "look inside"?
- what goes where in the right-click menus
- panning (again): scroll-bars where introduced by Kepler but are not
as nice as the original (and still present) panning window. The
compromize was: "scroll-bars are widely known.. even if not that
useful in this case". My preference: the "Adobe hand": widely known
*and* more useful than the scrollbars ;-)
But here are my most important points:
1. This dicussion should include the Kepler (and Ptolemy) developers
as well, in addition to end users. Just focussing on a narrow group of
so-called "end users" is a little bit like designing the usability of
the Space Shuttle cockpit by asking New York Cab drivers where they
prefer the emergency light placed ;-) We need to include in this
discussion the folks that continuosly evolve the technology and who
think about improving current features and introducing new ones. No
doubt: we must talk to end users and find out what's not working well
(a number of things) and maybe it's even the first priority. But the
process should also be informed by the ones who currently build
complex workflows in order to be maximally useful.
2. There are many usability things to consider that go beyond icons
and I know some are already been worked on. More of those deeper
issues can probably be tackled, again by including the developers
teams. For example, we are thinking about introducing special
"director-like" objects that factor out global aspects of a
workflow. For example a "black box" (a la flight recorder) for logging
workflow execution w/o having to wire each and every channel (but some
configurability of actors and/or the black box should be possible,
e.g., different verbosity levels of logging, etc). Or what about
color-coding "design actors" that cannot be executed (should be
"dashed boxes" maybe?) but that can be used for design workflows.
Kepler/SMS is currently working on how to include semantic types into
Kepler. We would like to use the static unit system developed by
Rowland as a case study. There are some usability issues with that
one, so analysing and improving that one would help SMS in getting it
(almost?) right on the first time.
Then there are UI issues such as: do we need buttons for:
- static Ptolemy type checking?
- static semantic type checking?
- static scheduling (e.g SDF style)?
- static grid scheduling?
- turning on/off all port names?
- turning on/off all port types?
- color-coding "problematic links" (untyped vs incorrectly typed vs
type safe ones)
- ..
So there is much to do.
My suggestion would be to use this mailing list and/or (possibly more
effective) the Kepler wiki page. For example we could have under the
Kepler Hot Topics area, one page focusing on usability issues.
What does everyone think?
I like the idea of "one stop shopping". Neither the mailing list, nor
bugzilla seem convenient for these larger issues.
cheers
Bertram
>
> 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