Page layout/format brainstorming

[Stephen Ewen]

I still like having the edit button/tab and history/button tab and article(or draft) button/tab on the top of the article.

That was my gut reaction, too, but then I asked myself,  "Is that because it's really better/more functional--or is it just that I'm so used to it?"

Is there really a difference? 

I think Frederik's second idea - project pages (left), content navigation (top), and page editing tools (right) - is perfect.

[Chris Day]

Yes, we badly want the list of subpages not to be part of the article, but maintained and compiled by the software (if that makes sense), but right now, the only way we have of creating the list of subpages is via a template--which must then appear in the article space.

There is a possible kludge.  Just clear out the left border and have the template float to the left.  Surely there is a way we can code the template such that there is no white space foot print in the article?  I'll try and figure that out. Clearly the subpage tabs would be better hardwired into the media wiki code but a template shifted to them left would be acceptable until we have programmers.

[Robert_W_King]

My only gripe is that there's too much whitespace around the borders of everything.

[Larry Sanger]

Yes, we badly want the list of subpages not to be part of the article, but maintained and compiled by the software (if that makes sense), but right now, the only way we have of creating the list of subpages is via a template--which must then appear in the article space.

There is a possible kludge.  Just clear out the left border and have the template float to the left.  Surely there is a way we can code the template such that there is no white space foot print in the article?  I'll try and figure that out. Clearly the subpage tabs would be better hardwired into the media wiki code but a template shifted to them left would be acceptable until we have programmers.

I welcome any such heroic solution, but I have to say I'm skeptical that it's possible.  Even if we can fix the whitespace problem, then presumably the height of the subpage list will be variable, while I doubt the height of the space "intentionally left blank" in the left sidebar can vary accordingly.

[Mark W Donoghoe]

There is a potentially deal-killing technical problem, however.  The list of subpages is part of the article.  Yes, we badly want the list of subpages not to be part of the article, but maintained and compiled by the software (if that makes sense), but right now, the only way we have of creating the list of subpages is via a template--which must then appear in the article space.  Well, I don't know if this is a deal-killer.  Can anyone say definitively?  We may need to consult a MediaWiki guru.  Or else, we need to get someone to write sidebar subpage display into the software (!).

There is already something within the MediaWiki software which lists all subpages, eg on WP or CZ, so I imagine if you were able to gain access to this code it wouldn't be particularly difficult to transport/change to suit our purposes. Note that it also recognises redirects (indicated by italics in the list), so that function could be adapted to leave these out of the list.

I'd volunteer to do this but I have absolutely zero experience with MediaWiki, and only a small amount in php. I am currently having a look at that function though in case there's no-one more competent...

[Chris Day]

while I doubt the height of the space "intentionally left blank" in the left sidebar can vary accordingly.

You're right there would be no flexability in the left side bar to accomodate variable lengths. But, I had assumed the left would be cleared out.  What would need to remain in the left border? Possibly the tool box, could that go at the very top and leave everything below clear?

[Larry Sanger]

Mark, very interesting.  Folks, see:  http://en.citizendium.org/wiki?title=Special%3APrefixindex&from=Biology&namespace=0   (thanks for the link to Steve)

I think we need to get some MediaWiki gurus in on this.  I'll see what Aaron Schultz has to say.  In fact, I am hoping Aaron can work with Fredrik on this.  I note with appreciation that Aaron and Fredrik (and another tech guy who has over the months helped more than they have, Zach Pruckowski) are all college students in their early 20s or late teens.  This is exactly the class of people who drove the development of MediaWiki in the first place (Magnus Manske leading the charge).  Thank god for young volunteers!!!

One thing I hope we can do is choose the order of subpages, at least for some subpages.  We want the default ones on top and in a predictable order, at the very least, even if the rest are alphabetical.

Chris, that's a good point, I didn't think of that.  Yes, if we can't do this "server side," which would be by far the superior solution, then perhaps we can predict the exact starting point of the subpage list in pixels from the top of the page.  Then we'd just have to solve that pesky whitespace problem...

[Mark W Donoghoe]

I've had a look through the various pages of code over the last half-a-day (it is impressively complex, but you can see how 'customisable' it is once you get your head around it) and what's been described can be done pretty easily from what I see.

As you ask, you could have a changeable list of "default" items (these could be specified in LocalSettings, or with a bit more time, a page like MediaWiki:Sidebar) which always appear at the head of the list in a specified order (regardless of whether they exist or not) and the function could automatically find all of the others and list them alphabetically. I think it would be a bit more difficult - and take away some of the freedom when creating a new type of subpage - to specify the order of the full list... This second method though, would allow you to control the types of subpages that appear in the list to just include those listed here, similarly to how Template:Unused subpages assumes it to be.

Like I said, I could have an attempt at doing this and am reasonably confident I would eventually get it right, but it would no doubt take me a lot longer and my solution a fair bit clumsier than that of someone who has worked with MediaWiki for a while. But let me know if you're after my help.

[Chris Day]

For the quick fix see the CZ talk page at http://en.citizendium.org/wiki/Template_talk:Subpages#Float_in_left_side_bar

Using absolute position (see this edit) I managed to float this subpage template nicely over the side bar (see this screen shot below).  All we have to do now is clear out the side bar.  Note that using ''absolute position'' gets rid of the white space issue.  last time I used ''relative position''.

[Aaron Schulz]

There is already something within the MediaWiki software which lists all subpages, eg on WP or CZ, so I imagine if you were able to gain access to this code it wouldn't be particularly difficult to transport/change to suit our purposes. Note that it also recognises redirects (indicated by italics in the list), so that function could be adapted to leave these out of the list.

I'd volunteer to do this but I have absolutely zero experience with MediaWiki, and only a small amount in php. I am currently having a look at that function though in case there's no-one more competent...

Indeed, the "LIKE" query code from Special:Prefixindex could be "borrowed" for this.

OK, from what I gather, people want to be able to make subpages to an article and have it automatically generate the sidebar list of them (like the template does now sort of). This could be done with an extension. However, I'd suggest that it be set to only recognize certain subpage names (CZ:Subpage_Pilot). Also, LIKE queries tend to rack up overhead, caching of the list might be a good idea (using the cache client, Memcached, whatever CZ set up). That would mean when something happens to a page like Y/X, it would invalidate the cache for page Y.

[Aaron Schulz]

For the quick fix see the CZ talk page at http://en.citizendium.org/wiki/Template_talk:Subpages#Float_in_left_side_bar

I'd avoid using the sidebar like that (where interwiki langauge links go). It would require either using the one crappy hook or hard modifications. Also, that hook is only on monobook skins, so all would have to be hard wired.

The upper right hand corner isn't that bad, the left hand one is certainly filled up already.

[Chris Day]

One thing I hope we can do is choose the order of subpages, at least for some subpages.  We want the default ones on top and in a predictable order, at the very least, even if the rest are alphabetical.

This is one thing i was musing over at http://en.citizendium.org/wiki/Template_talk:Subpage_list

The issue to consider is how to sort the default vs optional subpages, there seem to be two formats to consider.  
1) Subpage buttons always appear in the same relative order (although some may be missing if optional).  Conseqently if there are two default subpages A page and D page, all CZ pages using the template will have buttons for A and D.  But if B and C pages are present for a particular article then the buttons will appear in the order A,B,C and D.
2) Subpages buttons will cluster, default one first, followed by tthe optional buttons. Conseqently if there are two defaults A page and D page, all CZ pages using the template will have buttons for A and D.  But if B and C pages are present for a particular article then the buttons will appear in the order A, D, B and C.

The current subpages template is coded to give the first solution. One advantage is that only values have to be attributed to the designated ''Default'' pages others will be optional automatically.  

For the second option to work all subpages in the "subages list" template must be given an attribute, either "Default" or "Optional". from what you write above it sounds like you would prefer the second option.

With regard to sorting the optional buttons alphabetically the current code is not set up to do that.  And i'm not sure if it is even possible. This could be solved by doing it manually in the subpages list template but would lead to a logictical nightmare when adding new pages.  Unless someone wrote a simple script to regenrate the list each time a new button is added.

[Chris Day]

For the quick fix see the CZ talk page at http://en.citizendium.org/wiki/Template_talk:Subpages#Float_in_left_side_bar

I'd avoid using the sidebar like that (where interwiki langauge links go).

True but the idea would be to strip every thing out of the sidebar.  Plus, we don't currently have language links to worry about.

[Larry Sanger]

For the quick fix see the CZ talk page at http://en.citizendium.org/wiki/Template_talk:Subpages#Float_in_left_side_bar

I'd avoid using the sidebar like that (where interwiki langauge links go).

True but the idea would be to strip every thing out of the sidebar.  Plus, we don't currently have language links to worry about.

Aaron and Chris,

Right, the idea would be (pending a total redesign like Fredric has mapped out) to strip everything out, or in any case have a much stripped-down set of links, always of a set height, so that you can start the subpage links just below that just to test it out.  Chris, I'd say, let's do some experimentation  (can you give me a template + page it's used on that I can test out?), on the off chance that Aaron et al. can't, or aren't motivated to, set up the "server side" subpage links.

BUT if we do have subpage links generated "server side," then we avoid having to add {{subpages}} to thousands of pages...it would just be obviously better.  It's all just done automatically.  Woo hoo!

Here is a first pass at some requirements for "server side"-generated subpage links:

• We should be able to set the order of link display
• Default subpage links should always be displayed, even if the pages don't exist, UNLESS we specify otherwise (displayed with red color, as on the main wiki pages)
• A subpage should appear only if it is on a list of approved types; so, if someone creates [[Biology/HeeHee]], there wouldn't be a "HeeHee" link in the sidebar
• So, there also needs to be a utility to edit the list of subpage types

We've already solved these problems with {{subpages}} and some of the other proposed subpage templates.  If we can have similar functionality without a template, I'm all for it!

[Larry Sanger]

The issue to consider is how to sort the default vs optional subpages, there seem to be two formats to consider.  
1) Subpage buttons always appear in the same relative order (although some may be missing if optional).  Conseqently if there are two default subpages A page and D page, all CZ pages using the template will have buttons for A and D.  But if B and C pages are present for a particular article then the buttons will appear in the order A,B,C and D.
2) Subpages buttons will cluster, default one first, followed by tthe optional buttons. Conseqently if there are two defaults A page and D page, all CZ pages using the template will have buttons for A and D.  But if B and C pages are present for a particular article then the buttons will appear in the order A, D, B and C.

Clearly (2).  That's how {{subpages}} worked when I wrote it, and deliberately so.  Create as much uniformity as possible and you make the website easier to browse.

For the second option to work all subpages in the "subages list" template must be given an attribute, either "Default" or "Optional". from what you write above it sounds like you would prefer the second option.

I haven't studied how you've changed the template (documentation would be nice, but I haven't been good in that dept. myself).  We can simply make the default templates the first n in the list, and then in {{subpages}} make the first n automatically display.

With regard to sorting the optional buttons alphabetically the current code is not set up to do that.  And i'm not sure if it is even possible. This could be solved by doing it manually in the subpages list template but would lead to a logictical nightmare when adding new pages.  Unless someone wrote a simple script to regenrate the list each time a new button is added.

I wasn't suggesting that we display subpages alphabetically, just that it might be harder not to so display them.  Of course, coders can do anything with enough labor, but they are constitutionally indisposed to do more than what's necessary...