Front page > Community > Website discussion

Translation(s): none

Page started with the content of a mail to the debian-www mailing list. Feel free to restructure. Move extensive comments and ideas to other pages, please.

I will list now some topics I would want to discuss about with the intent to find some development goals we can agree and work on. It probably includes some topics others don't find important and lacks many others. Feel free to extend the list and question topics included.


Over the last few years the Debian website has seen many additions (like all the CDDs) and punctual improvements (e.g. improved wnpp scripts, more CSS oriented HTML structure). However, I think that the website actually needs a structural reconsideration, i.e. we should improve the possibility to actually find the stuff that is available and make the page more accessible for people not as knowledgeable in how Debian is organised and working as many of us are.

From my discussions with other developers and users on conferences and IRC I got the impression that many agree with this assessment. Hopefully we can motivate some of them to participate in addressing their concerns :)

This mail is an attempt to get us doing some more organised, targeted and ambitious development of the website in general. I know there are many people working on the website, but I have the feeling that we sometimes lack the necessary coordination and discussion to address certain issues.

However, if you strongly object to the thoughts above, I would welcome to hear your concerns. The rest of this mail makes the assumption that you don't object.

Review current usage patterns

Get hold of the apache logs for the webserver, and do a click analysis. At the very least, the most popular destinations (after eliminating the spiders) can point to what people currently are looking for. By grouping the access based on the IP and temporal proximity (like, access to pages separated by a few days are likely to belong to different sessions). This is likely to provide far more solid data to supplement user questionnaires mentioned in the next topic.

Ways through the site / user specific information

The big question is: How do I get from the homepage to the information I seek? The information I seek, my knowledge about Debian and therefor the answer to this question will probably differ much between Debian users and Debian contributors and developers. Generally speaking I don't know many Debian users that aren't also contributors or developers so I can say little about their problems and if the current web page addresses their needs. But I have feedback from various developers (some very experienced ones) that they don't find information they seek or even don't know that certain information exists. If I take a look at the ''devel'' index page I can't say I don't see their problem. It became very crowded with the time and is probably in need of restructuring it and splitting it up a bit.

- Possible ideas:


We have very different ways of getting and distribute news:

Sometimes there seems to be some confusion which news needs to get through which channel. Examples are news about services. When a ftp mirror or a web mirror has an outage, probably few people care, they just move to the next one. Some services are only of interest for developers and not so much for end-users (e.g. PTS or QA), a mail over -devel-announce is clearly enough then. However, things like packages.d.o or the BTS are probably used by way more people and news about these services probably brought to their attention. But are they important enough for -announce or should we perhaps include selected posts from -devel-announce on the web page?

- Possible ideas:

classes of news should get distributed

sub projects) and give the user a overview over all available ones, perhaps even offer a aggregator page where they can select them and get them presented as HTML.

Search is currently non-functional. Do we want to have a full text search again or should we leave this job to google? Do we want specialised search engines instead (e.g. for ?DSAs or a combined search engine for several services like PTS, BTS. p.d.o, etc?)

 Google can allow some amount of restriction, so that might be a way
 to go.  We definitely need some sort of search engine on site, even
 if it is just a wrapped Google -- as it is, we look very
 unprofessional and unfriendly. -- ClaireConnelly

Navigational Structure

Is the navigation bar we have at the top enough? Do we want more sidebar menus like we have on the frontpage and on the vote pages? This overlaps with the topic "Ways through the site". (I have to admit I mainly navigate with my address bar through the website by just going directly where I want to go...)

 It would definitely be nice to rethink the structure of the site.  I
 generally navigate through well-designed sites via location bar once
 I've learned my way around (and I definitely always do,, etc.), but it would be good to
 have some logical structure in place, and navigation to match that

 One good option is to have a set of master navigation links (like the
 ones running across the top of the page), with a second set of links
 for navigating within a subsection of the site.  That's pretty easy
 to do with scripting and CSS these days.

 I'll second that - IMHO the top bar should reference the main subdomains e.g. Packages,
 Bugs, Wiki etc.  Maybe it could be styled as tabs?  Each subdomain then gets a sidebar which provides for fine-grained navigation.  -- DavidClaughton

 One must, IMHO, is getting rid of the mixed case ["URLs"].  I'm forever
 being bitten by  -- ClaireConnelly


 IMHO a navigation menu on each page is a must. These days, users expect
 such menus, and tend to get lost quickly in the large number of pages on
 the website. I see this regularly on debian-cd when people ask questions
 which are trivial to answer from the web pages. :-/

 I guess that a hierarchical structure of all pages will become very large
 for the Debian website. For this reason, the standard behaviour of a nav.
 menu will not work. That behaviour is to "open" sub-trees of the menu
 until the entire path from the root to the currently visited page is
 visible. The resulting displayed tree would be too large for www.d.o, so
 it probably makes sense to subdivide the site into major parts (e.g.
 getting Debian, documentation, devel) and to have a separate menu tree
 for each.

 I agree with ClaireConnelly that a master navigation bar would be useful -
 additionally, it can provide entry points to the different major parts of
 the website.  -- RichardAtterer

There are CMS that write the fully clickable navigational path in text below
"top bar"  and above "main content".
This feature is called "breadcrumbs" and as an example
Debian > About > What does Free mean? > Free SW Definition
Using this feature below "top bar" and expanding NEXT deep navigational
options at left or right bar, could be interesting for a big site like Debian.
If this navigational path is right aligned, then the next options could be listed
at some right box/bar with a "fluid" consistent "L" design.
It is a kind of page contextual menu on the right side.
This idea could be implemented in text, suitable for screen readers.
Breadcrumbs should show the site hierarchy, not the user's history.

@ Debian Project                                   Search_box   |
                              Home > 1.3 > 2.1 > 3.8 > 4.2      |
--------------------------------------------------------- * 5.1 |
                                                         |* 5.2 |
                                                         |* 5.3 |
                                                         |* 5.4 |

Use hierarchy breadcrumbs instead of "normal" tree menu, for arbitrarly
 deep huge sites like Debian Project (8 thousand pages).
The * items are the contextual nav options for a given page.
@ Debian Project                                   Search_box   |
Home   |
> 1.3  |
> 2.1  |
> 3.8  |
> 4.2  |
 * 5.1 |
 * 5.2 |
 * 5.3 |
 * 5.4 |

I would not be too keen on splitting the navigation into a top bar and a  column; I also prefer the navigation bar to be a column, mostly as I find drop-down navigation menus to feel clumsy. I would reserve a top bar for site-wide non-navigational elements (e.g.  user preferences link, choose mirror control, language control, etc.).
-- Mentor

The web site is logically divided into separate areas (for example, mailing lists, bugs, vote). While I think navigation aids (say, side navigation bars, headers, and footers) need to be thought through for each of the major sub topics, but it would be nice if similar structures were in place to lend a feeling of homogeneity to the site.

Please, read [1], [10] and [11] (paragraph 7), containing some interesting points for big and deep sites like


Is WML good or do we need something else like a CMS? My answer is 'no', but there may be other opinions...

 In between WML and a CMS would be something like Ruby on Rails or (my
 favorite) HTML::Mason, which would allow us to provide various tools
 (image handling, glossary-style link shortcuts) and impose a standard
 layout while allowing changed content to appear immediately.  (We
 could also have separate staging/development/production servers, of
 course, which is probably a sane thing for any major changes).  Going
 with one of these solutions also supports the addition of a CMS on
 top of them later on. -- ClaireConnelly

I think it might be useful to expand on this topic as it comes up so often on the lists, so I created CMSProsAndCons -- ?DavidClaughton

What about something like ikiwiki? That would give us many of the advantages of a CMS, but it would continue to store files in a revision control system rather than a database. ikiwiki could easily support the kinds of themes proposed in the various mockups, including the sidebar. ikiwiki could trivially provide RSS and Atom feeds for pages. With the aggregate plugin, it could incorporate news from other sources, such as mailing list posts (given an RSS feed of the posts, which several archives provide).

Ikiwiki can easily emulate WML system for the News entries. It provides a po plugin to translate markdown pages (but that plugin has a couple of limitations for the moment), and supports content negociation. WML commands like <if-stable-release release="squeeze"> could be emulated by the use of git branches. --CharlesPlessy

Should we perhaps migrate from CVS to SVN (or something else)? There are certainly advantages but also problems during the migration which need to be considered.

 My personal experience moving from CVS to SVN was that it was
 relatively painless except that I did the initial move before I'd
 read the Subversion book.  I made the mistake of assuming that the
 default setup for SVN would handle MIME types properly.  It doesn't,
 and I ended up with some corrupted (and unrecoverable from the SVN
 side) PDF documents and images.  It's definitely important to have
 MIME-type handling set up before doing a move. -- ClaireConnelly

Translations rely on CVS revision numbers, directly obtained from the repository. Git can emulate CVS keyword expansion, so if we first convert the translation scripts to use $Revision:$, a migration to git may be easy. -- CharlesPlessy

Technical requirements

By ?RichardAtterer. A regular problem with the current website is that "XYZ cannot be done because we cannot assume that all mirrors of the Debian website support this".

I propose that we demand the following from our mirrors:

   Problems with Apache 2 are modules in Sarge, which are different
   to the release version of Apache 2. Things written for Sarge's
   modperl may not be compatible to modperl 2.0 release. So this
   may be an additional problem. -- JuttaWrage

Other topics?

Anything else we should talk about?

I got something: some parts of the debian web "estate" look quite different from the rest, most notably the cdimage stuff. this is weird and will confuse user (did i leave the debian "proper"?) perhaps these could be modified to look the same as the main debian pages -- robert

   I am not sure, what is meant here. Can you please explain it a bit
   more, Robert? Or is that solved by changing the Layout of the CD
   pages? -- JuttaWrage

Well, just take a look at these pages: , , , or any bug report at The colours are different from The sitemap has a light blue background, and it introduces black and yellow tabs. Those are quite unique on www.d.o. The bug-reports could use a header with the logo and a bit of the pinkish colour that is so prominent on the other pages. I'm not always sure if I'm looking at an official debian page. -- ?TijnSchuurmans

Old content

I've started a CategoryObsolete for pages that should be deleted because part of the old wiki and not relevant anymore. -- TheAnarcat 2006-05-15 02:04:37

Interwiki map requests

I think we should map foo to [done as of 2007-09, see Bug:foo. FranklinPiat] so that old links still work. DebianPackage is also used extensively [also done as of 2007-09, see DebPkg:foo. FranklinPiat] . More generally, the old InterWikiMap should be imported. Note that I fixed all references to ?WardsWiki and that we should import only the entries that are not already there under a different name. -- TheAnarcat 2006-05-14 23:43:38

This is done now. I am changing the InterWiki links to the currently active versions. -- DavidAndel. Migration is now completed -- 2007-09 FranklinPiat


I'm really ashamed to bring this up, but maybe Debian could consider a change to MediaWiki? I guess I'll get flamed for this, but I actually think it's a much nicer interface (eye candy and usage-wise).

If you compare with e.g., the Gentoo wiki, the Gentoo wiki has a much higher activity than the Debian wiki has, and I think the userbase does not explain this (I'd expect Debian to be just as large).

Very sorry to bring this up, be gentle with the flaming of me now!

Answer is a 4 months old wiki started after the DSA volunteered to host an official Debian wiki instead of having Michael Ivey host using Kwiki. The switch to Moin happened at the same time. When the wiki was still run with Kwiki, I think I was the most insistent person to request a move to MediaWiki. Kwiki is a really poor engine, so migrating to Moin already improved things more than they would be improved now by switching to MediaWiki. When the migration occured, Moin was in a little bit better position to be used by DSA than MediaWiki, Moin was in Debian since a long time while MediaWiki was only ITP-ed. When the migration was complete though, MediaWiki was already in Sid, so it must not have been a big factor for the DSA. My guess is that the DSA chose Moin since it's in Python while MediaWiki is in PHP (I don't see anything else explaining why an engine so clearly inferior to MediaWiki in terms of usability would have been chosen).

If you still think that moving to MediaWiki is worth it and there is a chance that DSA agrees and implements that, there are other pages about migrating to MediaWiki (e.g. HelpMoveDebianWikiToMediaWiki or DebianWiki/Engine) where this discussion should be more appropriate. This page can probably be deleted.

small note to wikis

moinmoin seems currently (2007) the most feature rich and flexible wiki technology available, and it will stay so for some time. its biggest advantage is the graphical editor, but also its simpler wiki syntax and theming make it much easier to use for a beginner. from an administration point of view it is also much simpler. just try to get personal moin run on your pc in 5 min and synchronize with a real moin on the web which has wiki sync enabled. -- ThurnerRupert 2007-06-13 07:35:13


This Wiki software that we're using right now, and/or the way it is set up, is just horribly unfriendly compared to MediaWiki. I admit I could be biased, having made tens of thousands of edits on Wikipedia under MediaWiki, but other than a gazillion functional user interfaces fixes that it could greatly benefit from, it could also benefit from mediawiki stuff such as namespaces, slashes in URLs, no CamelCase (ugh), categorization that is distinct from the rest of the pages, or Special:Whatlinkshere (list of links to the page), or edit links on sections... heck, this discussion page as such seems strange to me, with people using subsections for responses rather than indentation... --Joy

I should also mention - this thing doesn't allow me to remember my login credentials in the browser. While this could be considered a security feature, and is probably possible to work around using greasemonkey or whatever, it's also really annoying :) --Joy

it together with my comment. :) --GerfriedFuchs

Another thing is that we don't seem to have administrator users here. I don't know if this is the fault of our current installation (maybe we just don't have a way of listing them? :) or a generic problem, but MediaWiki has that, and admins are able to ban spammers etc. --Joy


I have just discovered this wiki and have made contributions to several pages. I think it is great to have such a wiki and I wish it every success.

Since I am completely new to this wiki, and wikis in general, I cannot say anything about the software. However, I strongly dislike the CamelCase convention. Apart from the fact that it does not deal appropriately with names such as DHCPServer (it does not seem to link it properly), it looks ugly and I am afraid it will prevent this wiki from becoming a first class source of information about Linux in general. I think these style issues are important and I find myself browsing for other Linux wikis that have a more professional/serious/stylish name convention and possibly layout in general, despite the fact that I am an enthusiastic Debian user.

PS: I have figured out after some trial and error that it is actually possible to use proper titles, e.g. 'DHCP Server', if linking them with quoted words in square brackets. I think this should be the default and should be suggested on pages such as [HelpOnPageCreation] or [WikiName], so that the wiki might slowly converge to a more professional layout. (Of course, it would be much better if all titles could be converged automatically in one go.)

-- -- ?LaurenzWiskott 2007-09-11 17:55:30

Copyright file disappeared

The copyright file, referenced here and there in this wiki, is not available anymore. Anyone still has the original version? I can't find it on or google. -- TheAnarcat 2006-08-14 08:32:59

The copright file is available here:

Website layout

Do we need a new one? Or do we need slight modifications to the old one? How does one find a new layout? Developing a new layout also depends on other discussions like "Navigational Structure".

If you have a proposal, you can add it on LayoutProposal

 I would love to see a more modern, CSS-based site, but that's more a
 question of aesthetics than structure. -- ClaireConnelly


 A more modern layout would be nice. Personal opinion: The site could use
 a few more graphical elements to make it easier to understand. For example,
 if all pages which are related to the www.d.o website maintenance show the
 same small image, this makes it immediately obvious to visitors that they
 are in the "website maintenance section". Wikipedia is a nice example of a
 site which uses a minimum amount of graphics to great effect.
 -- RichardAtterer

 There are several problems with layout changes:
   * We need a set of colours not conflicting with each other
   * We need a site wide style for tables and not everyone wanting
     his or her own style
   * many pages have extern sources and are created by scripts which
     are used elsewhere, too. Side effects can occur
 -- JuttaWrage

This page's goal is to act both as a roadmap and a specification for the website layout.

Step 1: identify needs

We want:

One of the first things to do is identify the websites we would like to use the new layout:

Possible others:

Step 2: analyse the current backends

Not all websites use the same technologies. We have statically generated pages, a Python wiki, a WML site... They are not necessarily as “themeable” as we wish, and changing their look may require various hacking skills.

Step 3: analyse the current layouts

The nature of the contents may impose restrictions on the final layout. For instance, a fixed-width layout is not suitable for Planet which can have very wide content (such as images) that we do not control.

Step 4: create mockups for all sites we wish to change

A single mockup for the front page will probably not be enough. We'll need design mockups for at least the following pages:

Layout proposal

This wiki page is an attempt to collect all the layout proposals for Feel free to add your proposal and your name here. Do not add comments on the proposals. Links only (at least for the time being) :)

Before adding your proposal here, please read WebsiteLayout.

You could also take a look at WebDesignToDo.

Proposals -- by: ?SimonPaillard -- by: ?SimonPaillard -- by: Lancer Lancer is no longer reachable. -- by: GustavoFranco - Runa is working on a mockup update. -- by: KalleSoderman -- by: ?KevinDodge png mockup at -- by: Umang -- Can be achieved with patch for debian.css


What about ? My interest is mainly in consultants. (Luk)

See also WebDesignPackagesToDo for todo list with issues specific to

Todo list for the web design of www.d.o

Suggestions and ideas