Wikipedia talk:Probox
Prototype 1[edit]
I've uploaded a prototype probox for community consideration.
Specs[edit]
- W
- Width of visible area of entire box
- A
- Border color
- B
- Head background color
- C
- Main background color
- Icon
- 18px x 18px
- Border thickness
- 1px
- Overall padding
- 0.5em
- Content margin
- 0.5em
- Head height
- 2em
- Subhead height
- 1.5em
- Subhead padding
- 0.5em
- Head and Subhead alignment
- centered
- Content alignment
- left
- List decoration
- none
Application[edit]
A general-purpose master template should be constructed with a large number of parameters; this contains all the "clever" code and allows for a range of choices. This master template is instanced by the constructor-editor of a specific-purpose template, who may assign hard values to some parameters. When the specific-purpose template is instanced on a given page, it may also be given parameters; these may be passed to the master template.
Subst: should not be used, either at the time of construction of the special-purpose template or when it is instanced. Changes to the content of the special-purpose template display on all insertions; changes to the master template propagate to all, to maintain the consistent look-and-feel that is the goal of this effort.
Comments[edit]
Proboxes are, by definition, intended for use in workspace -- never in articlespace. The deeper an editor gets into the editing process and the process of forming policy, the more proboxes he sees. The temptation is to say that since none are for show to the public, they can be messy. But at some point, we need a neater workspace.
This prototype makes no allowance for explanatory or introductory text. My feeling is that this need is best served by a standard tag format instead.
W is subject to discussion. I lean toward somewhere in the neighborhood of 200px. I'd rather see some links break to a second line than proboxes swallow entire page widths. On the other hand, there is true value in making W a template parameter with a default, so that actual display width can be adjusted per insertion.
Float as well should admit of a parameter. Default should be float right for all proboxes but a parameter will permit per-insertion adjustment.
I'm not sure I want to see individual icons for every probox. This leads to the cute but not terribly useful pattern set by stubs. I'm not an idiot; I can read the text to see what specific probox is in front of my eyes. It's much more useful for me to see at a glance what general class of probox any given instance belongs to. Policies, proposals, projects, processes, essays, discussions -- I can think of 6 or 7 distinct categories of probox. I'd like to see just 6 or 7 abstract icons, one for each.
There is a difficulty in all web design when specifying pretty box formats. That is, you cannot guarantee displayed font size. I assume a font size of 12 but personally, I have overridden all font specifications in my browser to a size of 14. Add to that, I've set a default expectation of 96 dpi. It is a great misconception to believe that what you see on your screen is very like what others see on theirs.
The second line down, immediately under the Head, is reserved for internal navigation. edit and talk should always be linked here; different projects may suggest other internal links. For an extreme example, see {{cent}}.
The background area of the Head is set against the outer border; the Head is the title of the entire box. Subheads are isolated from the outer border and appear a bit narrower, reflecting their lesser importance. No provision is made for a deeper hierarchy.
List decorations -- bullets -- are unnecessary here. They are often shown in existing proboxes but they just eat up screen real estate without adding much. It would be better to use hanging indents to make clear where one item ends and another begins, in the case that items break across lines. Otherwise, each item should simply begin a new line.
So far, this prototype says nothing about palette colors beyond defining the use of colors A, B, and C. I'll say this much only:
- A must be darker than B; B must be darker than C.
- Both B and C must permit overlying text to be read in all states (text, link, visited, active, hover).
- Colors should not riot or call undue attention to themselves.
- A smallish number of standard palettes must be supplied, so that the instance contructor can select a palette with a single parameter.
Further comment, as usual, is not only invited, but required, to proceed.