[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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
