Re: [boost] Experimental audience-targeted regression results

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-06-19 01:35:36

[2003-06-18] Aleksey Gurtovoy wrote:

>.... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
>available from here:
>
> * user summary page -
>http://boost.sourceforge.net/regression-logs/user_summary_page.html
> * developer summary page -
>http://boost.sourceforge.net/regression-logs/developer_summary_page.html
>
>Please comment!

On content...

The summary at the library level is good. But it has one drawback. If I
looked at that table as a user, I would give up in short order to use Boost
at all. It just looks like it's mostly broken. So having what is essentially
a binary indicator is misleading. Parhaps an indication of how much works
and doesn't is more informative to a user (and developer). Knowing the
difference between 1 failure vs. 50 failures is most times more important.
After all many times as a user I may not need the funcitonality that is
failing. And having just a works/fails discourages further investigation as
to what parts do and don't work.

The results page makes more sense to me than the summary page. Having the
seemingly binary indicator here is OK.

On HTML/style...

You really need to work on the HTML. The result pages do strange overlapping
text in some browsers. If you expect the background and text colors to be a
certain way, PLEASE put that in the HTML. My non-white default background
makes the pages look less than flattering.

...Indicators of various kinds:

Don't use background colors as indicators. It just obscure any possible
information that the text is trying to indicate. And to say nothing about
color-blind contention. Stick to using background colors to delineate
sections, or in place of rulers (as in table borders).

If you see the need to use an indicator other than text stick to using
shapes. For example you could replace the red/green indicators with X and +
icons, respectively. Using color on the icons then has the same effect you
have now but without the clutter, and without overly relying on color.

Be more informative in the text indicators. Using "OK" and "OK*" as
different indicators just looses any meaning that each may have on their
own. They both look just the same to me. Suggestion use "Supported" and
"Partial". 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". Pick something that conveys
the intended meaning better. In this case: "Unsupported"/"Fails" seems more
appropriate IMO.

The developer summary has one serious problem. You have two OK indicators
for different things. The dark green OK is just wrong. If a test is supposed
to not-succeed having it succeed is a failure. Or is there some other
meaning you intended? Here I would stick to the more familiar terms, by now,
of "Pass"/"Fail".

In the developer detailed page... again fail/fail/pass/pass need different
text indicators. How about; Fail, Pass, and Unexpected. The expected failure
and success would become the single Pass. Which leaves Fail and Unexpected
for unexpected failure and unexpected success.

...Table headers/side bars:

Unless the number of libraries get's really large, there's no point in
having the column labels at the bottom of the table. Repeating the
library/toolset column on the right is more debatable as to it's need.
Splitting the table in half, when needed, and either arranging them side by
side or one after the other might be an option. The center alignment on the
library/toolset labels is distracting, it just makes reading it harder,
especially if you are trying to scan for a specific name. That alignment
also applies to the cell content. Sticking to the language standards
(English) for this makes it easier on the reader.

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq