From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-06-19 12:45:11
[2003-06-19] Aleksey Gurtovoy wrote:
>Rene Rivera wrote:
>> [2003-06-18] Aleksey Gurtovoy wrote:
>> having what is essentially a binary indicator is misleading.
>As long as it reports things correctly, it's not.
I'll only say that I agree with Peter's comments on this point.
>> ...Indicators of various kinds:
>> Don't use background colors as indicators. It just obscure any
>> possible information that the text is trying to indicate.
>The first thing I would say is that this and most of other points below
>are highly subjective. I would appreciate if we discuss them in a less
>imperative tone ;).
Sorry I wasn't trying to sound imperative :-\ But I also thought I wasn't
mentioning anything other than established fact. My comments are things
you'll find in most HTML and typography design books.
>Basically, there is a single (and simple!) idea that both motivates
>using of background colors and suggests the particular scheme, that is,
>that you should be able to determine the status of things by just
>glancing over them. You don't have to read (and, ideally, to scroll
>anything). It's especially important and wanted for the CVS health
>(developer) report, which normally should be a full green field.
>We are not pioneers here - see Built Bot
>(http://twistedmatrix.com/~warner.twistd/) or Mozilla reports, - nor we
>think we are picking up a bad practice.
You don't need background color to do what you intend. I looked at the above
pointer and I think the use of background colors in that sample are also
But I guess this is a put up or shut up ;-) So here's a reformulation, style
wise, of the user summaray page which I think shows the same information in
a considerably more readable form without loosing the ability to glance at
>> Be more informative in the text indicators. Using "OK" and "OK*" as
>> different indicators just looses any meaning that each may have on
>> thei own. They both look just the same to me. Suggestion use "Supported"
>> and "Partial".
>They are close to be the same from a user standpoint, but I like your
>suggestion. Only those are too long :(.
Can't think of a shorter synomyn, but with carefull use of a smaller font it
can work. (see the above link)
>> Even though you did use different terms for the non-working indicator
>> in the user page, the ones you chose are again equivalent; "doesn't work"
>> has the same meaning as "broken".
>IMO it doesn't, and the legend tries to explain the difference.
It's not enough for the legend to explain it. As far as Eglish usage is
concerned they are synonyms.
>> Pick something that conveys the intended meaning better. In this case:
>> "Unsupported"/"Fails" seems more appropriate IMO.
>Not bad, too, but again, too long. It's important to keep the table
>compact. Any other suggestions?
Fail is short enough. Don't know of an alternative for Unsupported, yet ;-)
Perhaps an abbreviation would be sufficient; Unsup. ??
>> The developer summary has one serious problem. You have two OK
>> indicators for different things. The dark green OK is just wrong.
>Nope, it's not :).
OK ;-) I'll just have to try and understand what it really means. But the
fact that it's not obvious should be a clue as to it's ineffectiveness.
>> Unless the number of libraries get's really large, there's no point in
>> having the column labels at the bottom of the table.
>It's already large enough to not fit into my screen. Even if you have
>a huge monitor, it doesn't hurt having those, does it?
OK, understood. Using the more standard header repetition at regular
intercals seems like a possibility. Again see the link.
>> That alignment also applies to the cell content. Sticking to the language
>> standards (English) for this makes it easier on the reader.
>Strongly disagree, here. I definitely want to see the status centered.
Well you'll have to tell me if it works on the version I made ;-)
-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk