[kepler-dev] kepler nightly builds
Matt Jones
jones at nceas.ucsb.edu
Thu Mar 17 12:00:02 PST 2005
Thanks, Bertram,
Resounding agreement from me. I've interjected a few comments inline.
Matt
Bertram Ludaescher wrote:
>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)
>- ...
>
>
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.
>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")
>
>
we definitely need a "highlight" capability that can be used to indicate
that an actor is executing. The other changing icons that represent
load or other states might make things too busy. We don't do much with
links -- they might be a good way to indicate the 'intensity' of data
flows by changing the width of the link proportionally with bytes/sec or
something. In general, we can probably make better visual use of the
links than we do.
>- 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.
>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 ;-)
>
>
All good points.
>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.
>
>
I fully agree. The developers are not end users, but they probably have
the best insight into the range of issues that could be represented in
the the visual design. So I think the kepler group can help to scope
the design in addition to getting the end user input that is clearly needed.
>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?
>
>
Lets start a wiki page to handle overall UI redesign issues, that in
turn can link to more detailed pages on specific design changes as we
work them out. The wiki is much more effective to handling overviews so
we should use it for that, but we do also need to use bugzilla for
tracking tasks from conception to completion. The wiki of course can
point at the bugs for areas to link between the systems.
>I like the idea of "one stop shopping". Neither the mailing list, nor
>bugzilla seem convenient for these larger issues.
>
>
Agreed. The mailing list in some ways is the least useful because it
doesn't archive the concensus in a very effective way. So I think email
comments should get integrated into the evolving wiki pages as the
conversation progresses, possibly by the main person responsible for the
wiki page (e.g, see the documentation system page for an example of this).
Ciao,
Matt
>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
> > > -------------------------------------------------------------------
> >
>
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>
More information about the Kepler-dev
mailing list