ESP Wiki is looking for moderators and active contributors!

Template talk:Navbox

Problems and issues

Might be worth moving the discussion of problems and solutions here? That way, it doesn't get parsed every time the template is served.

Some random thoughts:

Maybe trying to get all these pages into one menu is over-ambitious. Remember, there is a Category system which achieves the sledgehammer stuff of indexing everything added to it.

HTML will never be able to do drop-down menus on its own. However, CSS3 should be able to handle them. I'm not sure how far it has progressed, but I expect the popular browsers will have some functionality by now. It might be worth trying to see if they can cope.

steelpillow 16:32, 15 May 2010 (UTC)

Makes sense. Done. Ciaran 14:07, 17 May 2010 (UTC)

Problems

Looks awful without javascript

If you turn off javascript, this displays with all sections open i.e. a list of 200+ links at the top of the article.

Updating requires too much manual work

We need a script that will check which pages are not in any of the boxes. The obvious way to do this is to maintain a table of all the articles and which boxes they're in. Checking could be done at any time by downloading the list of current articles and running the script to check which current articles aren't in the table. Then we add those. Then review the table. Then another script would generate Template:navbox based on the table.

When solving this problem, it would be great if we could also auto-generate most of the Main Page and Category tree.

Archive of previous problems, solved

Breaks the "What links here" functionality

For example: Special:WhatLinksHere/Greece - but only three of those pages really intentionally link to Greece.

FIXED. Or at least, I have the fix. If we use external links instead of internal links, this problem is avoided. A follow-on problem is that the external links look different, but this can be solved in MediaWiki:Common.css by using:
#bodyContent a.external[href ^="http://en.swpat.org/wiki/"]
This can be used to apply a style only to external links that point to en.swpat.org, so we can make them look like internal links (which they are). Ciaran 14:04, 18 August 2010 (UTC)
FIXED (FULLY) I've done that now, the external links idea and a CSS style to stop those links looking like external links. Ciaran 09:15, 22 November 2010 (EST)

Possible solutions and technical improvement

  1. Use an <iframe> ? They're not allowed currently, but maybe that tag can be enabled.
  2. Does MediaWiki use templates for the HTML files, for which we could patch it (and remember to apply the patch each time we upgrade the software, and check for breakage)?
  3. Borrow the javascript detection code that MediaWiki uses to display the edit buttons (bold, italic, link... at th top of the edit box) and then use the <noscript> tag to display a list of ~6 overview articles instead of the box whenever the page is viewed without javascript.
  4. Could we set the "[show]" plus the contents of the boxes to "invisible", and then add some javascript to override this property? That way non-javascript browsers would avoid getting the big wide 200-item list, and javascript-enabled browsers would continue to get what they get today. Anyone want to try this?
  5. If there are some key links you want "always to hand", these can be added to the sitewide navigation menu - that's what it is for, and where most visitors will expect to find them. steelpillow 13:50, 3 June 2010 (UTC)
  6. Add your suggestions!

Systems and javascript

I am not in favour of creating two different in-depth navigation systems - one for those who use javascript and one for those who do not - it means every update has to be done twice. Looking at the recent upgrade to Wikipedia, the less we fiddle with anything the fewer GUI issues will arise when upgrading. Mediawiki's "big wide 200-item list" system is called "Categories". The CategoryTree extension (as used on Wikipedia) makes the sub-category list expandable: each sub-cat having a + icon which, when clicked, expands to list any sub-sub-cats. If any of these has further sub-cats, it too can be expanded to create an in-page category tree. OK the sub-category page lists are not visible too in-page, but they are only a click away. It uses AJAX, i.e. it still needs javascript enabled, but at least the system remains usable for users without js - rather than clutter the page with 200 links, as the navboxes do, it leaves the user with the basic click-through experience. Maybe this, plus enhancing the category page template and shrinking the nav menu links to a handful of category pages, might be a way forward. steelpillow 13:50, 3 June 2010 (UTC) Short in-page navbox menus can still be used where appropriate, as long as collapsibility is used with caution. steelpillow 13:55, 3 June 2010 (UTC)

Two navigation systems is my current plan, but reason it's progressing so slowly is that I'm trying to make a system that won't have the problem of updating things multiple times. I want to keep the current "no intermediary page" navigation mode of navbox. It's possible that I'm overestimating the importance of this, but from looking at the page view spikes when we get mentioned on Slashdot etc., and then seeing how few people bother looking at any other page on the wiki, I want to work on making it as easy as possible for people to see the other page names.
My thinking is, if we're to have two systems, they should give the users two different ways to search. With categories, there's no (visual) space constraints, and you can find an article by multiple paths. With the navbox, I want each article to be in only one place (well, with a handful of exceptions).
To fix the AJAX problem, I'm wondering now if I could write a new plug-in based on the CategoryTree plug-in... Ciaran 13:42, 8 June 2010 (UTC)

Typo

Bilksi -> Bilski

Thanks for that. steelpillow 11:40, 23 May 2010 (UTC)