DebianWebSiteProject is working on ALL Debian websites layouts, not just the Wiki
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.
- Review current usage patterns
- Ways through the site / user specific information
- Navigational Structure
- Old content
- Interwiki map requests
- Copyright file disappeared
- Website layout
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:
Get feedback from users (-user mailing lists?) to identify problems
Restructure and split up ''devel'' to make it easier to find stuff
- Brainstorm a set of use cases for the web site, perhaps in conjunction with scenario development of such uses.
- Separate out click trail analysis into different topic/areas, and use that to derive rudimentary use cases for the users
We have very different ways of getting and distribute news:
- DWN (available from website) (RSS?)
- debian-announce (available from website/frontpage)
- debian-devel-announce (not available from website)
- debian-security-announce (available from website/frontpage) (RSS)
- news specific to sub projects (available from the websites of these projects)
- archive changes (additions and removals) (RSS/RSS?)
- blogs/Planet Debian (RSS)
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:
- develop a written policy for how and where certain
classes of news should get distributed
offer RSS feeds for all news (especially for the CDDs and other
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.debian.org 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
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 lists.debian.org, packages.debian.org, etc.), but it would be good to have some logical structure in place, and navigation to match that structure.
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 www.debian.org/News. -- 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 ,  and  (paragraph 7), containing some interesting points for big and deep sites like debian.org.
Navigation design Resources
 Navigation design tutorial http://www.d.umn.edu/itss/support/Training/Online/webdesign/navigation.html
 Testing Web Page Design Concepts for Usability http://ausweb.scu.edu.au/aw03/papers/alexander4/paper.html
 Usability Testing of Advanced Homepage Concepts http://www.useit.com/papers/sun/1997/concepts.html
 useit.com: usable information technology http://www.useit.com
 Breadcrumb Navigation Increasingly Useful http://www.useit.com/alertbox/breadcrumbs.html
 Human navigation concepts http://www.indiana.edu/~iirg/ARTICLES/NAVIGATION/navigationdoc.html
 Good Web Site Navigation - Reaching The Information Instantly http://www.mardiros.net/good-navigation.html
 Innovative design concepts http://idcwebs.com/portfolio.htm
 Navigation design http://www.wpdfd.com/wpdsymb.htm
 Why Primary Navigation Must Die http://www.bohmann.dk/articles/why_primary_navigation_must_die.html
 Designing site navigation http://www.webreference.com/dlab/9705/misc.html
 Research based Web Design & Usability Guidelines http://www.usability.gov/pdfs/guidelines.html
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
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
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:
- Use Apache 2.x. The main site can then offer for mirroring an Apache config file along with the actual pages. This allows us e.g. to create HTTP redirects when we remove pages. Apache 2 also has better support for language selection (HTTP content negotiation)... so obviously www.debian.org continues to use 1.3 until this day. ;-P
- Provide PHP (or other server-side scripting) support. Currently, lots of useful stuff is on people.d.o/~someone for this reason, on pages which don't follow the layout of the main site, are difficult to fix if there are problems, etc. Additionally, server-side scripting could be used to fix the language selection for those people who have problems with it; a cookie can override the browser's language setting.
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
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: http://live.debian.net/ , http://db.debian.org/ , http://www.debian.org/sitemap , or any bug report at bugs.debian.org. The colours are different from http://www.debian.org. 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
Interwiki map requests
I think we should map foo to http://bugs.debian.org/foo [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
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!
wiki.debian.org is a 4 months old wiki started after the DSA volunteered to host an official Debian wiki instead of having Michael Ivey host wiki.debian.net 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 guess this comment was done when wiki.d.o still used twiki/kwiki? Slahses in URLs are cheap, there's no need for CamelCase in moin, categorization is there, the Whatlinkshere is also available - moin just doesn't offer the subpage edits which can get pretty tedious, especially with a page like this. --GerfriedFuchs
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
- Propably also a comment from pre-moin times? If so feel free to remove
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 archive.org or google. -- TheAnarcat 2006-08-14 08:32:59
The copright file is available here: http://web.archive.org/web/20050415001944/http://wiki.debian.net/copyright.html
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
- global navigation for major Debian websites
- unified look and feel
carefully study the W3C Accessibility Initiative guidelines http://www.w3.org/WAI/
- don't make the Layout dependent on graphics too much, they usually just increase the load time and don't help handicaped people
- don't forget that our webpages should be accessible by blind people with screenreaders and textbased browsers and colour blind people
- don't use browser tricks to gain something specific. We don't want to encourage the use of any specific browser
One of the first things to do is identify the websites we would like to use the new layout:
http://www.debian.org/ (main website)
http://planet.debian.org/ (Planet Debian)
http://bugs.debian.org/ (bug tracking system)
http://lists.debian.org/ (mailing-lists archives)
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.
managed using CVS, only the webwml group can access it
MoinMoin wiki, has theme support
- managed by Mako, any developer can access the CVS
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.
- has a top navigation bar with major sections
- has a left-hand menu with internal links
- has a bottom list of translated pages
- consists of a single, very long page
- has a right-hand menu with the list of all blogs/developers
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:
http://www.debian.org/ (front page)
http://planet.debian.org/ (Planet Debian)
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=apache (bug list in the BTS)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367963 (bug entry in the BTS)
This wiki page is an attempt to collect all the layout proposals for http://www.debian.org. 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.
http://www.witch.westfalen.de/debian/screenshots/lancer/ -- by: Lancer Lancer is no longer reachable.
http://stratusandtheswirl.blogspot.com/2007/04/debianorg-website-meets-mentors-layout.html -- by: GustavoFranco - Runa is working on a mockup update.
What about http://www.debian.org/devel/website/todo ? My interest is mainly in consultants. (Luk)
Todo list for the web design of www.d.o
- replace the remaining "layout tables":
- /CD/vendors.wml (dl instead?) - CD pages use CSS now, for the Vendor list itself we still need a solution
Cites and quoted blocks (see Web Content Accessibility Guidelines 2.0 - Text Markup):
- tag quoted blocks as Blockquotes and make css for them
- replace layout blockquotes by divs ot something else
- make all other cites using Q-Tags
- CITE-Tag is used for emphasizing in constitution.1.1 - search others and replace by EM-tag
- search for other things that may be related to accessibility
- better document debian.css, make cleaner, more consistent structure
- convert all pages to only use HTML 4.01 strict instead of transitional (mostly done, two outdated and some chinese pages left)
Suggestions and ideas
- include acronym tags in the wml (suggested by Jutta)
- please start unifying the different looks on debian and debian-related pages, especially on the cd pages. it is pretty confusing for regular users because they might get the impression they left the debian proper when being directed there (suggested by robert lemmen) - mostly done (Jutta)
- Create a set of site wide Access Keys
Cooperate, create a contest with the people at http://www.opendesigns.org/