Layout design document

Design document for Wikipedia layout skins.

Broad aims

The current Wikipedia skin tries to accomplish too much: it has to cater for both casual readers, beginner editors, frequent editors, and admins.

Hence this project aims to design a new suite of layout templates for Wikipedia, each geared to a particular purpose:

clear and easy to read for casual visitors
easy to access editing functions for editors
a veritable cornucopia of utility links for "hardened" editors and admins

A key element of this project is the eventual implementation of Smarty, a PHP template system, that will make it much easier for designers to work on Wikipedia design.

A templating engine usually is a performance disadvantage (less caching, skin lookups), doing it just with xhtml & css would be a nice technical achievement. -- Gwicke 19:57, 4 Jan 2004 (UTC)

we can't move up to xhtml until the PHP code is fixed to correctly format P blocks, and we stop allowing raw HTML in wiki text. I did consider having just one HTML page laid out in different ways with stylesheets, but not all skins will want the same number of links, some might not display the logo, etc. Might be possible (if we didn't have to consider bad browsers), but wasteful of bandwidth to download things only to hide them. Getting rid of the special printable version is a start :) -- Tarquin 18:33, 4 Jan 2004 (UTC)

I imagine the missing closing p-tag issue to be solvable without too much trouble, I haven't digged in the code though.
Some pages' content propably won't validate (it doesn't now either), but i don't think this is a big problem. Another possibility to try could be Tidy in the save routine. It can most propably be told to ignore the wiki tags, the output afterward would be valid xhtml. I use this in Plone (with the Epoz editor).
I think the bandwidth savings of leaving out some li text links are neglible- especially with mod_gzip in use by default. -- Gwicke 13:57, 5 Jan 2004 (UTC)

Alas, nobody dares touch the parser code. :( I plan on making templates validate at least, so that part is ready for eventual XHTML. -- Tarquin 16:20, 5 Jan 2004 (UTC)

General design principles

The look of the thing

the page should be readable at 640x480 resolution, and also at a browser window width of ten words per line in the article
key elements of the page should be prominent:
- article title: a newcomer to the site should immediately be able to confirm that they are on the correct page
- language links: WikiMedia currently displays these horizontally, between the article title and the article content. As the number of Wikipedia languages grows, this list will become cumbersome. Hiding it in a drop-down menu of some sort is one possibility, but for the default skin at least, this is not a good idea.
- new message alert
article content should be as near to the top of the page as possible for clarity and for low resolution screens

The nuts and bolts of it

article content should be as near to the top of the HTML source for screen readers and non-CSS browsers
all templates should common architectural elements if possible. More below.
all templates should offer common hooks for user preferences and special pages. These should work by adding a class to HTML elements. This would include things such as:
- background colour for meta-pages
- right or left sidebar
- fixed sidebar
within sidebars and footers:
- use H2 element for any headers (such as "Site links")
- Use li elements for link lists

can we be sure to hide bullets for all browsers? -- Tarquin 16:20, 5 Jan 2004 (UTC)

Well, there will be bullets in lynx, but anything with css is fine. The tabs in plone are lis too- they can be laid out horizontally. For non-css browsers a bullet representation is pretty good i think. In Plone the navigation box on the left side is not yet in lis, but that will be done soon. Gwicke 13:33, 6 Jan 2004 (UTC)

ok. I'll change the templates made so far. -- Tarquin 16:37, 6 Jan 2004 (UTC)

certain templates will be allowed to drop functionality for old or broken browsers, as long as this is clearly indicated in the User Preferences, and as long as there is a real need for it. These might include nifty widgets such as drop-down CSS menus.

DOM tree and hooks

Each template should have the same basic page architecture, and the same hooks for user preferences and per-page display features. See Layout design document/Page architecture for technical details.

Stylesheet architecture

Each page will now have 3 stylesheets attached:

global stylesheet - media=screen
print stylesheet - media=print
current skin stylesheet - media=screen

Print stylesheet

Since both the global stylesheet and the current skin stylesheet are set only for screen media, the print stylesheet doesn't have to do extra work undoing colour and layout changes. It merely has to:

hide online elements using class tags inserted into elements
show piped URLs -- this can be done with CSS but only works on CSS2-compliant browsers (ie, not IE). The other option is to display the URL of piped URLs in all cases, but hide it for screen with CSS
make some minor cosmetic tweaks to make sure the article title and the "From Wikipedia..." line are nicely spaced out.

Global stylesheet

This stylesheet would hold style rules common to all skins.

What would go in this:

System:

set the background colour according to whether the article is "encyclopedia" or "meta". These are set with classes in the BODY element - see Layout design document/Page architecture

Content:

image styles; for standardised captions & easier image floating
styling for section editing links, which are currently styled inline
set the EM element to display as italic, the STRONG as bold

Preferences:

styling for A element: whether links are underlined
styling for A element: editlinks and stub links, etc
Justify paragraphs

A element

Current classes used by mediawiki:

a.stub: stub marker
a.new: edit links
a.internal: wiki links that are neither of the above

a.external: external links

Prototype Skins

See skins

Discussion

Hiding the article title

In Wikipedia, the main page has no title, and its tab says "Main Page" instead of "Article" how might I do this?

--Mattsb 14:28, 12 February 2007 (UTC)[reply]

Drop down menus

These (drop downs) can be done with a ul/li list, degrading nicely for older browsers. I can supply the css (again from wikipedia:Plone ;-). -- Gwicke 14:25, 5 Jan 2004 (UTC)

That's the sort of thing I was thinking of. Brion said he'd like a skin that shows ALL links without any dynamic hiding & revealing. Not sure how to fit everything in...!!! I made a rough demo with LI and css: http://wiki.beyondunreal.com/misc/wp/colosseum-1.html but it doesn't yet work with IE. -- Tarquin 16:37, 6 Jan 2004 (UTC)

That looks nice- very clean. If possible it would be nice to split the different link groups into separate lists so that they can be reordered and shuffled around the page with css. I like Plone's interface metaphors- tabs on top and so on. I've just uploaded a quick hack/ plone rip-off at http://wp.aulinx.de/. Gwicke 21:17, 6 Jan 2004 (UTC)

I'm thinking about moving the language dropdown to the left column- if the 'unwritten' languages are included it would be very long, too long before the content. Could be combined with the search box, they are both very active elements. A select might be better to understand (with special colour for unwritten languages and written ones first), but it would either also depend on js or there would need to be a redirector script on the server that takes the regular post data. The li dropdown will allways work because it's just links. Hmm. Or at the bottom of the main page- that's not a bad idea after all, with a link from the top. Could be included in the green 'page' metaphor then. Gwicke 22:51, 6 Jan 2004 (UTC)

Wow! That looks really cool! -- Tarquin 10:25, 7 Jan 2004 (UTC)

Thanks ;-) In 5.0 the tabs are not as pretty, maybe it would be worth to add a special rule to the IEfixes stylesheet.
I think we should concentrate on providing flexible xhtml that is laid out for a well-designed, somewhat consistent UI. Then we could make up a competition for the best stylesheets and get some designers on board. A few posts to css newsgroups, the css portals (zengarden, alistapart, mezzoblue,...) might be enough. There should be some eager designers out there ;-) Gwicke 14:43, 7 Jan 2004 (UTC)

Drop down menus should never ever be used in the standard skin. It look cools, but that stuff should go to a user-created skin. --Maio 00:45, 22 Feb 2004 (UTC)

DIV attribute

My idea is for all templates to have the same basic DIVs, so they can have a common print stylesheet. Could you take a look at the scaffold document I made? Should we provide more elements? I know the Zen Garden page has a large number of DIVs for CSS to hook into. -- Tarquin 18:56, 7 Jan 2004 (UTC)

Our templates are very similar now (changed a lot today), the main difference is the number of wrapper divs with ids to hook into. They don't really add bulk but provide a lot of styling flexibility. Imo the most important thing is to decide on a meaningful, intuitive grouping of link elements. Every group should get its own wrapper id. We should propably decide on a default order of elements- the tabs are an example. I like these three link groups:

User tools- preferences- log in/ log out etc, usually top-right corner.
Page-related links (edit, history, talk...)- i like the tab way. Pretty intuitive, emphasizes the 'one page, different views' metaphor.
Global links and information boxes ('portlets') in the sidebar, propably search and languages. Including complex information into every page might have too many performance implications, maybe only feasible with ESI.

Some other thoughts:

The language selection is different, we have to decide on it- i think your solution (in the sidebar) is better. The alternative would be at the bottom of the content area, potentially styled as tabs. That would break the page metaphor, though. Selecting a different language changed the interface language as well, not just the content. So something in the quickbar/linkbar. Li or select?
For the advanced users access keys are a good thing without cluttering the interface with redundant links (as in the default skin now).

I have a print stylesheet and a presentation stylesheet, and alternate stylesheets for different text sizes. I think we could get rid of the latter because sizes are specified relative to the user's size (sort of, it's not as dumb as font-size:80%- i hate those sites because they rely on IE's default of 16px which is way too big for unstyled html).
Anyway- let's decide on the xhtml structure first, the styles can be done afterwards. -- Gwicke 19:49, 7 Jan 2004 (UTC)

So instead of our current situation of several templates each with a stylesheet, we'd have several templates each with a choice of stylesheet -- and with a common basic DIV architecture, and a single print stylesheet. I made a list of classes for wrapper divs -- classes rather than IDs since a group of links may occur several times, eg in header and footer. I figured for positioning you can either give it an ID as well, or access it with something like "#footer .sitelinks" -- Tarquin 22:31, 7 Jan 2004 (UTC)

I've played around a bit- a reordered mockup (with all links/tools after the content as in your xhtml) is at http://wp.aulinx.de/test/. The tabs seem to be possible to do with absolute positioning, it's still a bit rough but seems to work ok. IE's float model is pretty bad (and IE6 seems to get worse over time), so absolute with ems seems to work out better. Some css effects are hard to do without a wrapper div- beveled boxes for example (example: http://www.vertexwerks.com/tests/sidebox/). So i'm in favor of a few more bytes for <div>s.

For the language selection i'm in favor of a dropdown with a hidden 'submit' button (and automatic submit via js). Then there's no shortage of space and the 'yet unwritten' languages could be included.

I think we should give each ui 'component' such as linkbar, 'portlet' (section/ box in the 'linkbar'), document area etc a unique id. Then we can use classes inside these elements if structural markup isn't sufficient. This is also very useful for moving them around.

What do you think about the ids #portlet-contentViews, #portlet-personalTools and so on? Too long? I like the hierarchical names with hyphens ;-)

-- Gwicke 14:52, 8 Jan 2004 (UTC)

Bear in mind that elements might not always be at the same place in different skins. Check out paddington skin for example -- I've left the language links in the header for that one. So class="langlinks" applies to the element that holds the language links no matter where it is or how many times it occurs. -- Tarquin 19:39, 8 Jan 2004 (UTC)

Hm- i thought we were trying to move to a single xhtml markup that's only styled with css, that's why i did the reshuffling (to move towards the one and only common xhtml file). The only thing changing from skin to skin should be the stylesheet that's included. I was wondering what you meant with the 'several templates each with a choice of stylesheets'- and i interpreted it to be the same wrapper around the functional (content area) templates that have the same markup independent of the skin. If you want to do a different xhtml for each skin, well then we should propably do different skins. But i see a huge opportunity for future skin development, caching (-> ESI), performance, accessibility etc in having one solid structure to build on. One element occuring several times is not possible in a minimalistic xhtml, but we could provide a 'rich' version for this purpose, with duplicate elements to play with added at the end of the file (or similar).

Personally, i'm in favor of not duplicating them- access keys are enough for experienced users (at least for me). Type <alt>-e (Mozilla) or <alt>-e- enter (IE) in my mockups and you'll go straight to the edit page. Same for search (<alt>-s), history (<alt>-h),... Just by setting the accesskey on the link, no js. Tab orders in forms go in the same direction. For beginners the current ui with its element duplication, broken metaphors (if any at all) is not optimal, to me it just looks cluttered. But of course you can't tease everyone with the same. What i would like to avoid though is ending up with five different xhtml files for the same page view. It would be impossible to do a stylesheet that works for all of them.

-- Gwicke 20:39, 8 Jan 2004 (UTC)

One of the problems of single XHTML page with many stylesheets is the dreaded Netscape 4: we need at least a default skin that looks ok in really old crappy browsers. I also wanted to make a default skin that would be simple for the non-technical user. I imagine a like Plone has a very technically-able audience. This is not the case with WP -- if anything, we need to attract more non-geeks and "lusers". Hence the Giza skin I made, which had almost nothing at all in the header. Current users will also want to keep the Phase 3, Cologne Blue and Nostalgia skins: I've redesigned them according to my layout architecture. My suggestion would be to modify the basic scaffold so it has as much in common with the XHTML page as possible; and have the XHTML share the same basic classes for the global print stylesheet to operate on. -- Tarquin 17:41, 9 Jan 2004 (UTC)

Giza's html is very similar to my first design- with the login/logout thing and the edit links both structurally and by appearance above the content and in the top-right corner.

(moved the main part of this comment to Skins).

Re print stylesheet: i don't see a problem in this at all- just some coordination on class names/ids to hide/show.

--Gwicke 20:36, 9 Jan 2004 (UTC)