On 23/10/2008, at 7:21 AM, Stéphane Ducasse wrote:
can you explain the icons
The left arrow, which comes in three forms - up, down and up&down,
indicates declared-in-super/subclass. It is not overloaded with any
other meaning. To the left of that is space for a green '+' that
indicates 'is an extension', which is also used in the instance/class
list.
The 'x' indicates a method containing a halt. Normally, shifting the
left side of the label is a bad idea because it makes scanning the
list more difficult - it forces the user to explicitly read the label
- but in the case of a halt that doesn't matter as much because it is
both transient and operationally very significant. Except in the case
of the method that looks for #halt, because it contains the symbol
without actually *being* a halt method. I am considering adding a
marker-method or pragma to allow you to control those few (reflective)
methods that have this problem i.e. a manual semantic annotation.
The right boxed forms are: comes-from-trait, is-unfulfilled-trait-
requirement and is-trait-method-conflict. One of my focusses is
including better support for traits in the UI. I think the comes-from-
trait is too strong in relation to it's meaning.
The right downwards arrow means is-abstract e.g.
#subclassResponsibility.
The right red star means '#needsWork or #flag:'. Those icons
horizontally accumulate to the right, so multiple icons can co-exist.
Note that red always means 'attention required', and how much the red
stands out is in proportion to the nature of the issue. But I always
pair color with a shape change to deal with color-blindness - a poor
example is in VW's SUnit fail/success markers.
I use an ellipsis for labels that are truncated by virtue of having
icons to the right. I also have a hover mechanism that shows the full
label in-place when you hover over it iff it is truncated, either with
an explicit ellipsis or simply because it is too wide for the list.
Also note that the column widths can be adjusted independently, and
don't have to start an equal width. Some columns will always have icon
spaces, some not.
I did these before I gave in and bought a copy of Fireworks, so I was
limited in what I could do shape wise without manually pixel painting
e.g AA embosses. Anyone who's done that knows what a fiddly PITA it
is. I thing a circular badge (for the trait markers) would be less
jarring in general, although it's important to maintain a consistent
aesthetic in that sense across the entire product, and circular forms
commit you to a reduced area for the semantic payload. Furthermore
there is a significant pragmatic benefit to using simple rectlinear
icons that can be done well a) with simple tools and b) by many
developers, because it allows contributors to produce icons for
integratable components that don't look out of place. Check out the
class type icons in VW for an example of how not to do it. For a
system that is *meant* to be extended by the user, this is IMO an
important consideration.
This is very much a work in progress.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
It is no measure of health to be well adjusted to a profoundly sick
society.
-- Jiddu Krishnamurti
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
