Differences between revisions 2 and 23 (spanning 21 versions)
Revision 2 as of 2007-11-17 22:23:37
Size: 30040
Comment: change attached portal DebianWiki -> Community
Revision 23 as of 2014-02-09 16:39:02
Size: 31309
Editor: ?SimonPaillard
Comment: Move under webmaster
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||||<tablestyle="width: 100%; border: 0px hidden">||<style="border: 0px hidden">||
||<style="border: 0px hidden">[:FrontPage:Front page] > ["Community"] > Website discussion||<style="text-align: right; border: 0px hidden"> ||<style="text-align: right;border: 0px hidden">||
||<style="border: 0px hidden">~-''Translation(s): none''-~||
## page was renamed from DebianWebsiteDiscussion
||||<tablewidth="100%" tablestyle="border: 0px hidden ;"style="text-align: center;"> ||<style="border: 0px hidden ;"> ||
 .
||<style="border: 0px hidden ;">[[FrontPage|Front page]] > [[Community]] > Website discussion ||<style="border: 0px hidden ; text-align: right;"> ||<style="border: 0px hidden ; text-align: right;"> ||
 .
||<style="border: 0px hidden ;">~-''Translation(s): none''-~ ||
Line 5: Line 8:
DebianWebSiteProject was work on ALL Debian websites layouts, not just the Wiki

Page started with the content of a [http://lists.debian.org/debian-www/2005/06/msg00144.html mail to the debian-www mailing list]. Feel free to restructure. Move extensive comments and ideas to other pages, please.
 . DebianWebSiteProject is working on ALL Debian websites layouts, not just the Wiki
Page started with the content of a [[http://lists.debian.org/debian-www/2005/06/msg00144.html|mail to the debian-www mailing list]]. Feel free to restructure. Move extensive comments and ideas to other pages, please.
Line 11: Line 13:
[[TableOfContents()]] <<TableOfContents>>
Line 14: Line 16:
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. 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.
Line 18: Line 20:
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.
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.
Line 29: Line 25:

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.
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.
Line 39: Line 31:
Line 43: Line 36:
Line 46: Line 38:
Line 53: Line 46:
  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: 
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:
Line 68: Line 52:
 * 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.  

* 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.
Line 74: Line 57:
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?)
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?)
Line 84: Line 65:
Line 86: Line 66:
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...)
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...)
Line 113: Line 90:
Line 115: Line 91:
Line 137: Line 114:
There are CMS that write the fully clickable navigational path in text below 
"top bar" and above "main content". 
There are CMS that write the fully clickable navigational path in text below
"top bar" and above "main content".
Line 143: Line 120:
If this navigational path is right aligned, then the next options could be listed  If this navigational path is right aligned, then the next options could be listed
Line 159: Line 136:
                                                         
Line 165: Line 141:

Line 190: Line 164:
Line 192: Line 165:
 *[1] Navigation design tutorial http://www.d.umn.edu/itss/support/Training/Online/webdesign/navigation.html
 *[2] Testing Web Page Design Concepts for Usability http://ausweb.scu.edu.au/aw03/papers/alexander4/paper.html
 *[3] Usability Testing of Advanced Homepage Concepts http://www.useit.com/papers/sun/1997/concepts.html
 *[4] useit.com: usable information technology http://www.useit.com
 *[5] Breadcrumb Navigation Increasingly Useful http://www.useit.com/alertbox/breadcrumbs.html
 *[6] Human navigation concepts http://www.indiana.edu/~iirg/ARTICLES/NAVIGATION/navigationdoc.html
 *[7] Good Web Site Navigation - Reaching The Information Instantly http://www.mardiros.net/good-navigation.html
 *[8] Innovative design concepts http://idcwebs.com/portfolio.htm
 *[9] Navigation design http://www.wpdfd.com/wpdsymb.htm
 *[10] Why Primary Navigation Must Die http://www.bohmann.dk/articles/why_primary_navigation_must_die.html
 *[11] Designing site navigation http://www.webreference.com/dlab/9705/misc.html
 * [1] Navigation design tutorial http://www.d.umn.edu/itss/support/Training/Online/webdesign/navigation.html
 * [2] Testing Web Page Design Concepts for Usability http://ausweb.scu.edu.au/aw03/papers/alexander4/paper.html
 * [3] Usability Testing of Advanced Homepage Concepts http://www.useit.com/papers/sun/1997/concepts.html
 * [4] useit.com: usable information technology http://www.useit.com
 * [5] Breadcrumb Navigation Increasingly Useful http://www.useit.com/alertbox/breadcrumbs.html
 * [6] Human navigation concepts http://www.indiana.edu/~iirg/ARTICLES/NAVIGATION/navigationdoc.html
 * [7] Good Web Site Navigation - Reaching The Information Instantly http://www.mardiros.net/good-navigation.html
 * [8] Innovative design concepts http://idcwebs.com/portfolio.htm
 * [9] Navigation design http://www.wpdfd.com/wpdsymb.htm
 * [10] Why Primary Navigation Must Die http://www.bohmann.dk/articles/why_primary_navigation_must_die.html
 * [11] Designing site navigation http://www.webreference.com/dlab/9705/misc.html
 * [12] Research based Web Design & Usability Guidelines http://www.usability.gov/pdfs/guidelines.html
Line 205: Line 178:
Is WML good or do we need something else like a CMS? My answer is 'no',
but there may be other opinions...
Is WML good or do we need something else like a CMS? My answer is 'no', but there may be other opinions...
Line 217: Line 190:

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 [http://ikiwiki.info 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).

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.
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 [[http://ikiwiki.info|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.
Line 242: Line 208:
Translations rely on CVS revision numbers, directly obtained from the repository. [[http://progit.org/book/ch7-2.html#keyword_expansion|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
Line 247: Line 214:
Line 249: Line 217:

{{{ 
   Problems with Apache 2 are modules in Sarge, which are different 
{{{
   Problems with Apache 2 are modules in Sarge, which are different
Line 256: Line 223:
   
Line 260: Line 226:
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 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
Line 270: Line 233:

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
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
Line 277: Line 236:

I've started a CategoryObsolete for pages that should be deleted because part of the old wiki and not relevant anymore. -- TheAnarcat [[DateTime(2006-05-15T02:04:37Z)]]
I've started a CategoryObsolete for pages that should be deleted because part of the old wiki and not relevant anymore. -- TheAnarcat <<DateTime(2006-05-15T02:04:37Z)>>
Line 281: Line 239:

I think we should map DebianBug: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 [[DateTime(2006-05-14T23:43:38Z)]]

This is done now. I am changing the InterWiki links to the currently active versions. -- DavidAndel.
Migration is now completed -- 2007-09 FranklinPiat
I think we should map DebianBug: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 <<DateTime(2006-05-14T23:43:38Z)>>

This is done now. I am changing the InterWiki links to the currently active versions. -- DavidAndel. Migration is now completed -- 2007-09 FranklinPiat
Line 295: Line 251:
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 DebianWikiEngine) where this discussion should be more appropriate. This page can probably be deleted.
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).

 . Sorry to sound dull, but what makes it "so clearly inferior to MediaWiki"? --GerfriedFuchs
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.
Line 301: Line 257:
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 [[DateTime(2007-06-13T07:35:13Z)]] 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 <<DateTime(2007-06-13T07:35:13Z)>>
Line 304: Line 260:
Line 307: Line 262:
 . 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
Line 309: Line 265:
 . Propably also a comment from pre-moin times? If so feel free to remove
it together with my comment. :) --GerfriedFuchs
Line 311: Line 270:
 . Moin can have GroupPages and assign special ACL posibilities to such users. Not sure if it's used, though. --GerfriedFuchs
Line 312: Line 272:

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. 
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.
Line 319: Line 278:
-- -- LaurenzWiskott [[DateTime(2007-09-11T17:55:30Z)]] -- -- LaurenzWiskott <<DateTime(2007-09-11T17:55:30Z)>>
Line 322: Line 281:

The
[http://wiki.debian.net/copyright.html copyright file], referenced [:About:here] and [:DebianWikiIsNotGFDL: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 [[DateTime(2006-08-14T08:32:59Z)]]
The [[http://wiki.debian.net/copyright.html|copyright file]], referenced [[About|here]] and [[DebianWikiIsNotGFDL|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 <<DateTime(2006-08-14T08:32:59Z)>>
Line 327: Line 285:
<<Anchor(website-layout)>>
Line 328: Line 288:

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"]
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
Line 339: Line 296:
Line 341: Line 297:
Line 350: Line 307:
Line 354: Line 310:
   * We need a site wide style for tables and not everyone wanting     * We need a site wide style for tables and not everyone wanting
Line 360: Line 316:

Line 365: Line 319:
Line 367: Line 320:
Line 370: Line 324:
  * carefully study the W3C Accessibility Initiative guidelines http://www.w3.org/WAI/
Line 374: Line 329:
Line 376: Line 330:
Line 381: Line 336:
Line 383: Line 337:
Line 387: Line 342:
Line 389: Line 343:
Line 393: Line 346:
  * managed using CVS, only the `webwml` group can access it
  * managed using CVS, only the {{{webwml}}} group can access it
Line 396: Line 348:
  * MoinMoin wiki, has theme support
  * MoinMoin wiki, has theme support
Line 399: Line 350:
  * uses PlanetPlanet
  * managed by Mako, any developer can access the CVS
  * uses PlanetPlanet
  * managed by Mako, any developer can access the CVS
Line 403: Line 353:
Line 405: Line 354:
Line 409: Line 357:
  * has a top navigation bar with major sections
   * has a left-hand menu with internal links
   * has a bottom list of translated pages
  * has a top navigation bar with major sections
  * has a left-hand menu with internal links
  * has a bottom list of translated pages
Line 414: Line 361:
  * consists of a single, very long page
  * has a right-hand menu with the list of all blogs/developers
  * consists of a single, very long page
  * has a right-hand menu with the list of all blogs/developers
Line 418: Line 364:
Line 420: Line 365:
Line 422: Line 366:
Line 427: Line 372:
<<Anchor(layout-proposal)>>
Line 429: Line 375:
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) :) 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) :)
Line 436: Line 382:
[http://teubr.eu.org/~spaillar/debian/design/debian.html] -- ''by: SimonPaillard''

[http://teubr.eu.org/~spaillar/debian/design2/] -- ''by: SimonPaillard''

[http://www.witch.westfalen.de/debian/screenshots/lancer/] -- ''by: Lancer''
Lancer is no longer reachable.

[http://james.isafreelancer.com/debian/] -- ''by: James Herrington''

[http://stratusandtheswirl.blogspot.com/2007/04/debianorg-website-meets-mentors-layout.html] -- ''by: GustavoFranco'' - Runa is working on a mockup update.

[http://kjs.homeip.net/projects/debian/] -- ''by: KalleSoderman''

[http://kjs.homeip.net/projects/debian/bling/] -- ''not quite as light. by: Kalle Soderman''

[http://img255.imageshack.us/my.php?image=testoa8.png] -- ''by: Shutdownrunner'' (sorry for comment)Well, it's not exactly a layout proposal, but rather a question. Could debian website contain a large image that would point to some current important event? sth like gnome.org or ubuntu.com. I know it looks like plagiarism (unsusccessful unfortunately) of [http://ubuntu.com] It was meant to.

[http://encoresoup.com/project/debmonk_qlinks] -- ''by: DavidClaughton'' (based on GustavoFranco's Debian Monkeys script).
http://teubr.eu.org/~spaillar/debian/design/debian.html -- ''by: SimonPaillard''

http://teubr.eu.org/~spaillar/debian/design2/ -- ''by: SimonPaillard''

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.

[[http://www.kalleswork.net/projects/debian/|http://www.kalleswork.net/projects/debian/]] -- ''by: KalleSoderman''

http://svn.rivalsource.net/pub/debian-minimal -- ''by: KevinDodge'' png mockup at http://www.debianart.org/cchost/?ccm=/media/files/kevind23/401

http://www.umang.ath.cx/debianwww/ -- ''by: [[UmangVarma|Umang]]'' -- Can be achieved with [[http://www.umang.ath.cx/debianwww/debian-www-css.patch|patch for debian.css]]

<<Anchor(design-todo)>>
Line 458: Line 401:
See also WebDesignPackagesToDo for todo list with issues specific to
http://packages.debian.org/
See also WebDesignPackagesToDo for todo list with issues specific to http://packages.debian.org/
Line 463: Line 405:
  * /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 [http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20040903/#inline 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
  * /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 [[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20040903/#inline|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
Line 472: Line 414:
Line 478: Line 419:
 * Cooperate, create a contest with the people at http://www.opendesigns.org/

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.

Introduction

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

News

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

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

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
 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 [1], [10] and [11] (paragraph 7), containing some interesting points for big and deep sites like debian.org.

Infrastructure

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:

  • 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

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: 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

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 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

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

Mediawiki?

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

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

software

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

  • Moin can have ?GroupPages and assign special ACL posibilities to such users. Not sure if it's used, though. --GerfriedFuchs

Style

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

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:

  • global navigation for major Debian websites
  • unified look and feel
  • accessibility:
    • 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
    • avoid ?JavaScript wherever possible, especially if it would be the only way to get something done and not only a small addon

    • 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:

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.

  • http://www.debian.org/

    • has a top navigation bar with major sections
    • has a left-hand menu with internal links
    • has a bottom list of translated pages
  • http://planet.debian.org/

    • 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:

Layout proposal

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.

Proposals

http://teubr.eu.org/~spaillar/debian/design/debian.html -- by: ?SimonPaillard

http://teubr.eu.org/~spaillar/debian/design2/ -- by: ?SimonPaillard

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.

http://www.kalleswork.net/projects/debian/ -- by: KalleSoderman

http://svn.rivalsource.net/pub/debian-minimal -- by: ?KevinDodge png mockup at http://www.debianart.org/cchost/?ccm=/media/files/kevind23/401

http://www.umang.ath.cx/debianwww/ -- by: Umang -- Can be achieved with patch for debian.css

WebDesignToDo

What about http://www.debian.org/devel/website/todo ? My interest is mainly in consultants. (Luk)

See also WebDesignPackagesToDo for todo list with issues specific to http://packages.debian.org/

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)
  • include Javascript solution to make IE happy and mostly compliant (Jutta)
  • Create a set of site wide Access Keys
  • Cooperate, create a contest with the people at http://www.opendesigns.org/