Re: Subpages overwhelms the content

I agree that this is sub-optimal.  Here's what's going on:

We use semantic media wiki to set various properties on pages that help us
organize the information on them. This includes things like the "Page
Title" (as far as MediaWiki is concerned, the page title is the entire URL
string after "http://docs.webplaform.org/wiki/", so we set our own property
that's the human-readable title which we default to the last bit of the
URL). We also set some properties on pages that allow us to create Semantic
Media Wiki queries that list articles of a certain type.

This system will allow us to generate sub-page listings that have short,
human-convenient titles and only list the articles that are direct
children, not *every single descendant* page. The
http://docs.webplatform.org/wiki/Template:API_Listing template implements
this; the page in question uses it.

Unfortunately, due to the way the import happened, these all-important
properties aren't set on many pages. As soon as a  user makes any edit to
the page using the "Edit" button (as opposed to the "Edit source" button),
the pages will magically get the properties set correctly. Literally,
people could just click Edit, and then immediately click save on an article
and it would work (I call this operation--a save without any substantive
changes--a "touch", after the unix command-line program). The problem is
there are thousands of articles.

For each page, before that happens, they wouldn't show up in the queries
designed to select articles for the "smart" sublisting tables. That would
mean that the smart sublisting tables would be incomplete, and some
existing content would be unreachable.

In the mean-time, we have an option to use the "stupid" sublisting
functionality. This is because in my estimation it's better to have
sublisting tables that are overly comprehensive and annoying to read than
to have ones that simply fail to list many relevant articles. If an article
is not linked from anywhere, it's hard for search engines to find and it
means that users won't even know it's there to have any chance of
editing/improving it.  So if you look at the API_Listing template (or just
hit "Edit" on the page in question), you'll see that the "Print all
subpages rooted here" box is checked. This is what generates the "stupid"
sublist. The hope is that as many of the pages naturally get touched or
edited, we'll get to a place where we can stop using the stupid sublist
functionality and move to the smarter one.

This is a lot of information. Am I making any sense?

--Alex

On Wed, Oct 31, 2012 at 8:01 PM, Jonathan Garbee <jonathan@garbee.me> wrote:

> Ok, I went to check the source of the page and it turns out that the links
> *are* supposed to be just the item.  There is a bug [1] in the system.  We
> are still left with the issue of display though...
>
> -Garbee
>
> [1] https://www.w3.org/Bugs/**Public/show_bug.cgi?id=19793<https://www.w3.org/Bugs/Public/show_bug.cgi?id=19793>
>
>
>
> On 10/31/2012 6:48 AM, Jonathan Garbee wrote:
>
>> I agree.  We need to trim down what is being displayed and that is a
>> great start.
>>
>> Something else with this table, does anyone have any ideas how we can
>> organize it better than just a monolithic table?  It seems quite
>> intimidating.
>>
>> -Garbee
>>
>> On 10/29/2012 8:02 PM, blueflame wrote:
>>
>>> Example page: http://docs.webplatform.org/**wiki/html/elements<http://docs.webplatform.org/wiki/html/elements>
>>>
>>> I suggest that the enormous subpages section either be collapsable or
>>> move to the end of the page. Also, for easier digestion, the current page
>>> does not need to prefix each subpage. Since the user is already on
>>> html/elements/, it's repetition is not necessary. Thoughts?
>>>
>>> -Derek
>>>
>>
>>
>>
>
>