Page indicators
There are page status indicators to show the overall results for modules that have tests, but also status indicators for modules that should have tests. Page indicators have an initial icon, which is colored after the result, and a string. The coloring should follow the usual red – yellow – green color scheme for tests, and preferably by styling. The string should also say what the page indicator is about, that is “Pickle”, and the final state it is in, that is failed – pending – pass. There can also be other states.
Page indicators are done in Github: jeblad/Pickle/includes/Indicator.
It is important that the state is conveyed both as a symbol with a color cue and as a string with a description. (W3C – Techniques for WCAG 2.0: G14: Ensuring that information conveyed by color differences is also available in text) The coloring of the symbol should only be used as a speed cue, not as the only source of information about the state. This is not merely because of usability concerns, it is also to give very clear and very strong signals to those using the module.
The mechanism for filtering out modules with public methods, and only marking those, is delayed for now.
Symbols
The actual symbol and styling has only been through a very rudimentary design process. They should probably employ the colors used by other such testing frameworks, thereby the red, yellow, and green. They should also use a variation over the help-link already in use, thereby the encircled symbol. Note that they are not a predicate (help link), they are interjection (pickle link), and as such we shift from a question mark and to an exclamation mark or something similar.
The coloring for some symbols are somewhat heavy, and could be adjusted. All are available on Commons in c:Category: Spec, and it would be interesting if someone would create alternate designs. The whole link can be styled, so other schemes can be discussed too. Coloring behind the whole link was tested, but found to create too much visual distraction.
;
Failed
: The icon for failed state is a cross mark within a circle. A cross mark is typically used for something negative and dismissed. The rim of the circle can be styled, and will typically be colored red with a tint matching the skin.
;
Unknown
: The icon for unknown state is a triple dot mark within a circle. A triple dot mark (or hellip) is typically used for something non-conclusive and unknown. The rim of the circle can be styled, and will typically be colored yellow with a tint matching the skin.
;
Passed
: The icon for passed state is a check mark within a circle. A check mark is typically used for something positive and accepted. The rim of the circle can be styled, and will typically be colored yellow with a tint matching the skin.
Strings
To make it possible for even color blind people to use the interface, and also for those that has no clear understanding of what the coloring means, a string is used both for stating the link in fact goes to the Pickle page and the final state of the pickles. This dual-purpose might create a problem for translators.
The string will express the overall state for the pickles, not the individual ones. Even if there are 100 “passed” results, if there are one “pending” the overall result will be forced to “pending”. A “failed” result will also be forced to “pending”. That means there will be no plural variable, as it is the overall state that is conveyed in the string.
At present the form is very terse, and sounds a bit awkward. It should be decided how we want to express this before they are translated.
{
"pickle-test-text-good": "Good",
"pickle-test-text-pending": "Pending",
"pickle-test-text-failed": "Failing",
"pickle-test-text-missing": "Missing",
"pickle-test-text-unknown": "Unknown"
}
There are three variants that seems obvious, either one has their merits. We could add the state in a parenthesis "Pickle (good)", or spell it out "Pickle is good", or reformulate as "Good pickle". First one focuses on what it is, and then the result. This should probably link just the first part, and append the state as non-linked information. The second sounds better if it is added in templates. Last one focuses more on the actual state than how it is inferred.
It should also be discussed if we want the same messages in a parser function. That would make it possible to add a test status to templates like w:nn:Template:Lua. Other projects use a Lua-module for the same purpose, like w:en:Template:Lua which use w:en:Module:Lua banner. Those templates would probably be better off with a module-based interface.
The messages can be set to disabled.