Fanlore upgrade on Saturday!

[aethel]

Dear Fanlore editors and readers,

Finally, after months of work, the MediaWiki upgrade is ready to go live! It is scheduled for Saturday, November 24, at 22:00 UTC. (What time is it where I am?) If everything goes according to plan, there should be no downtime, but you will not be able to edit Fanlore for a short time.

Why the upgrade?
MediaWiki is the software Fanlore and many other wikis, including Wikipedia, are built on. Until now Fanlore was using version 1.15, which is woefully out of date, so we are switching to 1.19. Upgrading will allow us to, for example, install new extensions to better fight spam on the site. For more information about different versions of MediaWiki, you can go here.

Why the new skin?
With the new mediawiki version, we decided to switch our default skin from WordPress to Vector. The WordPress skin is no longer under active development and wasn't meant for this MediaWiki version. Continuing to use it would have meant extensive fixes now and in the future, and we decided against it.

Instead, Natalie (from the OTW's Webmasters committee) and Qem (an AO3 tag wrangler) have very kindly volunteered to customize the CSS to recreate an approximation of Fanlore's old WordPress skin. You will see a few differences: the sections in the sidebar are now collapsible, wikilinks are no longer bolded by default, and the talk page link appears on the left side of the screen. Let us know if anything is broken with the new skin.

To save ourselves much effort, we are only supporting our default skin at this time. It's possible to use a different one, but the formatting might be strange.

Other Changes?
We have removed the bugtracker extension (also no longer supported) and OpenID support.

Problems?
If you discover any bugs or issues, please let us know!

Many Thanks
to Emufarmers, the Systems Committee, astirya, Natalie, and Qem

Comments

[espresso_addict]

Very glad the upgrade is now scheduled! Hopefully the spam users will finally be at an end.

Personally I dislike Vector and very much like the current Fanlore skin, so I'm very glad there are going to be some customisations... though collapsible sidebar sections sounds like a plus. Non-bold links will take some getting used to, but might in the end be more flexible and easier to read.

[aethel]

Well, the extra spam measures will need to be added after the upgrade, so we will still need to wait a bit. But this is a step in the right direction!

[espresso_addict]

If anything there looks to be a substantial uptick in spambot-type registrations since ~midnight. I guess the old version was so old the spammers had forgotten how to hack it!

[espresso_addict]

A few thoughts on the Vector style. Infoboxes are left aligned, without a box; is this intentional? The quotations template is lacking a box. (The blue one is ok, the white one has no box.) Is there any way of getting the old base font back? I find this much harder to read at my screen resolution.

ETA: Ah, I seem to have hit it before the new Fanlore-specific stylesheet was installed. Will have another look, but Infoboxes still seem left aligned and box free.

Also, are we sticking with the orange-brown colour on unpatrolled new pages? I don't believe we've previously been using the patrolled function?

ETA2: Visited wikilinks appear black on my screen, and are undifferentiated from text.

[aethel]

I'm not sure why infoboxes are displaying that way. I've reported the issue.

The .not-patrolled{background-color:#ffa} looked useful, so I haven't asked anyone to change it yet. Is it very annoying? I see it only when I'm logged in; I'm not sure if users without gardener privileges would see it.

Visited wikilinks still look blue to me. (Though actually they were purple before.) WordPress automatically bolded all wikilinks, but Vector does not, and some people had asked for this to be fixed. However, if it is unreadable, we can revisit. In my completely non-expert opinion, I think font-weight and color should be a relatively simple fix.

[espresso_addict]

[By the way, I sent these comments and some others to the OTW contact e-mail given in the announcement then noticed things were changing under my feet a lot, and gave up!]

The unpatrolled colour is quite dark on my screen; it would be easier to read the new page titles (newly unbolded) with a much lighter shade. There again, that might be invisible on some people's monitors. I'd say if we are planning to use the patrolled feature, it would be worth finding a shade that works for everyone. But if we're not, then it detracts from page readability. I'm happy either way -- I do new page patrol a fair amount, and would be happy to click 'patrolled', as long as that was only taken to mean 'I eyeballed this and found it was broadly ok' rather than the meaning on en-Wiki (article has been reasonably rigorously checked by someone who has a passing familiarity with the area). It might mean that new pages no gardener/admin has eyeballed would be more likely to get clicked, and multiple people don't all descend on a page that doesn't need any attention.

The visited wikilinks still look black to me, unless I turn the brightness on my laptop way up into headache zone, in which case I can just about make out that they are purplish. Given the small text size and the fact that they are no longer bold, more colour differentiation from text would seem useful. Perhaps just make them the same colour as unvisited links?

I'm easy on whether links should be automatically bolded. Coming from Wikipedia (where they are not), the bold links were a bit of a culture shock (especially as bold italics for eg titles really looks hideous), but I did get used to them over time. Readability guidelines for webpages tend to suggest non-bold links for reading, but the bold links do encourage exploring. If they are left unbolded, then it would be useful to publish stylesheet tweaks so that those who much prefer them bold can adjust. There again, probably 99% of our traffic is from Google, so the great majority of readers will be logged out.

Sorry for the tl;dr: web readability is a bit of a personal hobby horse.

[briar_pipe]

The infoboxes were showing up left-aligned without borders at first, but they've since been fixed. I like the centered placement of the navigation links at the top and the collapsed drop-down menus on the left (less clutter is always easier for my eyes to handle).

The coloring/bolding issue is a bit difficult on my end. Like Espresso Addict, the blue shows on my screen as nearly black, and the purple isn't much better (I'm on a 32-bit display on a Mac, if that makes a difference). I had to bump up the font size to see both unvisited and visited links; only uncreated pages (red) appeared clearly. If there are folks who are upset about the bolding from before, can there be some skin system we could choose from? I'm currently running my cursor over the lines of text to find the links. >.<

Kudos to everyone who worked on the upgrade! You guys are amazing. *\o/*

[espresso_addict]

The end result is a bit ugly, but I've just discovered that you can turn on link underlining under preferences, which at least makes them visible without upping the font size or blasting the brightness through the roof. It's under Preferences: Appearance: Advanced options: link underlining.

[briar_pipe]

Oh, thank you! That works wonders. Long lists are not pretty, but the pages themselves are so much easier to work with. <3

[facetofcathy]

The default design behaves very poorly with even slightly higher than the set font sizes.

A combination of height set in pixels on the heading (keeping the coloured horizontal lines fixed), absolute positioning on some nav elements and padding and margin in pixels--all detriments to fluid pages that allow font and window size scaling--causes these problems. No height should ever be set in pixels on any element that contains content.

On my widescreen display, I can't even get the font size of the text to 16 pixels (the most common browser default font size and the minimum size at which I can read text) without the heading of the page overlapping the orange line.

Larger fonts, required by many users, make the page an unreadable mess. I do not have this problem on Wikipedia, it scales up in font size very gracefully.

And while were at it, why is the base font of the page 12 pixels?

I did some digging, and there are two style sheets that are applied when I view the site.

The original style sheet is setting a font size on body at 1em which is good, and then setting it to 80% of that for the bodyContent div, which is common design practice of the past and contrary to web accessibility standards of today. It is at least fluid and will scale on all devices.

The second style sheet sets the body font to 12px, overriding the 1em, which is really, really dreadfully bad practice. It then sets the bodyContent to 1em, which since the inherited body rule hard codes it to 12 pixels means the result is a base font of 12 pixels and that rule has no actual function or effect. Given this null rule sitting there, I wonder if the 12px size was intent or accident?

Regardless, this hard coded font size is not in any way shape or form the same thing as having a base font of 1em, will not scale properly on all devices and is contrary to web accessibility standards which call for user-defined browser defaults to set the size of an em, and the base font to be set to 1em or 100%.

If the OTW had an accessibility and usability policy, it would be institutionalized practice to validate all CSS and to ensure it meets accessibility guidelines before it goes live, thereby allowing all users to enjoy the OTW's projects fully and completely at all times.

Instead, Fanlore now has an even smaller font size than the AO3, which also fails to meet the guidelines.

Here is a W3C plain language discussion of best practices for font size.

Also, regarding the different background colour some users are seeing (non-patrolled pages) there are easily used tools to check if the colours of text meet colour and contrast guidelines for those pages. this one works will hex codes. All text colours should be tested with all backgrounds, including all link colours.

[aethel]

Thanks for letting us know. I've forwarded your message to relevant parties.

I tried fixing just the 12px body font size, but it threw everything else off.

[facetofcathy]

I played with the Firefox developer tools this morning.

Here is a random page at 18pixel font in the base Vector skin with a screen size emulation of 1280x600:



Here is the same page, same size with the Fanlore-specific revision skin"



At only slightly larger font/smaller viewport, the sidebar links become truncated as it is set to a fixed width in pixels--another very poor practice.

I realize that the base vector skin brings some baggage with it--those absolutely positioned sidebars and headers, for example--but the base skin at least functions up to a decent font size on a screen at least 1000 pixels wide, and I think you should revert to it as default until the revision is genuinely usable.