From Fedora Project Wiki

(inserting my username call)
Line 1: Line 1:
 +
== The great nesting debate ==
 +
 +
=== Against ===
 +
 
{{admon/caution| On nesting |
 
{{admon/caution| On nesting |
I disagree with nesting except for pure utility pages. Nesting makes indexes on category pages such as [[:Category:Fonts_SIG|this one]] very difficult and user-unfriendly. There are other ways to mark a page belongs to a group (such as categorization or [[:Template:CompactHeader|branding]]). - [[User:Nim|nim]]}}
+
I disagree with nesting except for pure utility pages. Nesting makes indexes on category pages very difficult and user-unfriendly. There are other ways to mark a page belongs to a group (such as categorization or [[:Template:CompactHeader|branding]]).}}
  
== The great nesting debate ==
+
* [[:Category:Fonts_SIG|good]] index with human-friendly article names and not nesting
 +
* [[:Category:Packaging_SIGs|bad]] index with nesting, human-hostile article names and bad sorting
 +
 
 +
--
 +
[[User:Nim|nim]]
 +
 
 +
=== For ===
  
 
I don't disagree with the sentiment; I'm not clear myself what is right/wrong/best/worst.  There is a lot of entrenched thinking that supports nesting, and to move away from that we need to address those ideas and needs.  My biggest concerns are:
 
I don't disagree with the sentiment; I'm not clear myself what is right/wrong/best/worst.  There is a lot of entrenched thinking that supports nesting, and to move away from that we need to address those ideas and needs.  My biggest concerns are:
Line 14: Line 24:
 
Nesting is in place for a lot of sections, and since it isn't breaking search/indexing, we're at least going to need to take this in stages.  It all comes down to the strength of the argument.
 
Nesting is in place for a lot of sections, and since it isn't breaking search/indexing, we're at least going to need to take this in stages.  It all comes down to the strength of the argument.
  
 +
--
 
[[User:Kwade|quaid]]
 
[[User:Kwade|quaid]]
 +
 +
=== Against #2 ===
 +
 +
# Collision of names:
 +
## this is what disambiguation pages and categories are for
 +
## are you kidding? Wikipedia is the greatest mix of multiple audiences on the internet, we're several orders more single-focused
 +
## If you have a guide for end-users and a guide for contributors, just name one « User guide » and the other « Contributor guide ». That's more clear for everyone involved, including google
 +
# naming structure should not be similar to nesting without the visual clues. One of the main advantages of no-nesting is you can choose titles in natural text, not some random collation of keywords that's difficult to pronounce, remember and discover
 +
# nesting … 
 +
## isn't breaking search/indexing: you've not looked at the morass our category indexes are.
 +
## is in place for a lot of sections … need to take this in stages. Taking it in stages means having clear targets so you can stage the pages you modify (and touch each of them once). Taking it in stages does not mean having to pass many times on each and every wiki page, changing one bit at a time.
 +
 +
--
 +
[[User:Nim|nim]]

Revision as of 09:40, 29 June 2008

The great nesting debate

Against

Stop (medium size).png
On nesting
I disagree with nesting except for pure utility pages. Nesting makes indexes on category pages very difficult and user-unfriendly. There are other ways to mark a page belongs to a group (such as categorization or branding).
  • good index with human-friendly article names and not nesting
  • bad index with nesting, human-hostile article names and bad sorting

-- nim

For

I don't disagree with the sentiment; I'm not clear myself what is right/wrong/best/worst. There is a lot of entrenched thinking that supports nesting, and to move away from that we need to address those ideas and needs. My biggest concerns are:

  1. Collision of names in the flat namespace as different subprojects have similar needs
    • In a single-audience (e.g. "encyclopedia readers" for Wikipedia) this is less of a concern; with multiple audiences, confusion can arise. For example, is the User_Guide for the end-user audience or the contributor audience? User of what? Etc.
  2. Naming structure is similary to nesting without the visual cues

Nesting is in place for a lot of sections, and since it isn't breaking search/indexing, we're at least going to need to take this in stages. It all comes down to the strength of the argument.

-- quaid

Against #2

  1. Collision of names:
    1. this is what disambiguation pages and categories are for
    2. are you kidding? Wikipedia is the greatest mix of multiple audiences on the internet, we're several orders more single-focused
    3. If you have a guide for end-users and a guide for contributors, just name one « User guide » and the other « Contributor guide ». That's more clear for everyone involved, including google
  2. naming structure should not be similar to nesting without the visual clues. One of the main advantages of no-nesting is you can choose titles in natural text, not some random collation of keywords that's difficult to pronounce, remember and discover
  3. nesting …
    1. isn't breaking search/indexing: you've not looked at the morass our category indexes are.
    2. is in place for a lot of sections … need to take this in stages. Taking it in stages means having clear targets so you can stage the pages you modify (and touch each of them once). Taking it in stages does not mean having to pass many times on each and every wiki page, changing one bit at a time.

-- nim