Talk:Main Page

From GodWiki
Revision as of 03:52, 25 August 2018 by Holy Spirit of Hell (talk | contribs) (New mobile-friendly Main Page: commented on mobile format)
Jump to: navigation, search

This is the talk page for discussing improvements to the Main Page article.
This is not a forum for general discussion about the article's subject.

Article policies
  • Opinionated research if possible
  • Neutral point of view when appropriate
  • Humour
  • Verifiability
  • Be polite
  • Assume good faith
  • No personal attacks
  • Do not bite the newcomers
  • Respond in a mature manner
  • Be welcoming
  • Maintain civility at all times

This page has an archive

Old and/or inactive discussions have been moved to the /Archive subpage.

Mobile layout of main page

I'd be great if this wiki could have a "mobile version" or something, but I don't know how to properly check for that. --ElectroChip (talk) 15:10, 9 May 2017 (UTC)

I agree (as do most users, I think) that the main page has some significant layout problems on mobile (mainly around the grey Welcome to the GodWiki block at the top). Reading FeRDNYC's brief summary below of the challenges of setting layouts can give you some idea why, but the root of the problem is that, with no active admin at the moment, there's nobody right now with the powers required to modernise the site's CSS to be responsive to the dimensions of the window. Anything we do in the meantime will be a kludgy hack that might improve some layout issues, but generally we'll have to choose between the front page looking great on desktop or on mobile, not both.
That said, if anybody wants to take a bash at a rebuild of said grey block, please do! I'd suggest pasting any proposed changes into this talk page first so that we can all compare how they go on our various desktop and mobile screens first :) --Djonni (talk) 09:04, 9 June 2018 (UTC)
See User:FeRDNYC/Sandbox — it's very much a WIP, but in my testing it sizes properly (but not "formats" 100% properly, yet) on mobile devices. The gray-box bulleted items are coded as a single bulleted list, which uses a fairly new (past 3-4 years) CSS column-formatting feature to split itself up according to the available space. So, hopefully it's supported everywhere it needs to be. I already have a plan to clean up the strip of links at the bottom of the gray box, and I'm still working out the balancing of the various sections below the gray box so that they don't get chopped up by the column balancing. -- FeRDNYC (talk) 22:35, 2 August 2018 (UTC)
Never mind the struck-out part, I sorted that out. I removed a couple of items from the horizontal list (the Guidebook and the Categories list), because (a) they're both available in the sidebar, and (b) in the case of the Guidebook, I just feel it's a lot dated, and could really use some updating if we want to point people at it.
That part of the box is formatted as four one-item columns, which reduces a little weirdly as it narrows. (It first goes down to three columns, but since there are only four items it only fills the left two of them, leaving a big empty area to the right. Then it drops to two columns and everything balances again.) But honestly, as a tradeoff for it being readable on all screen sizes I think that's acceptable. Please do weigh in if you have any thoughts, though. -- FeRDNYC (talk) 23:20, 2 August 2018 (UTC)
I admit, I had noticed the edits to your sandbox and had a peek the other day. I'm excited about the changes and progress, and look forward to a modernised main page! :) One note — with the 2 columns reflowing in the lower section, on desktop I am currently seeing "Edition May 14, 2018" orphaned at the top of the second column. I'm not sure if there's any sane way to prevent that behaviour, just worth noting at this stage.
And yes, the Guidebook pages need a huge amount of work. I'd mentally earmarked that... for mañana. --Djonni (talk) 02:12, 3 August 2018 (UTC)
Yeah, that issue is what I was referring to, with my (somewhat redundant, as I balance the balanced balancing) note about "working out the balancing of the various sections below the gray box so that they don't get chopped up by the column balancing." It's not meant to do that — and honestly, if it wasn't doing that I'd probably consider it complete, since with the horizontal list "fixed" well enough it's kind of the only issue left — but currently, it still is doing that. And I suspect is going to keep doing that, as long as I'm (ab)using columns for that part of the layout.
I'll probably have to switch that section from CSS columns to a different layout system, possibly CSS flexbox, to make it keep those DIVs intact. Just as soon as I work out how (or if) I can convince flexbox-or-whatever to auto-adjust to width, the way columns does so nicely. (And without requiring any media queries, which inline styling can't use.) -- FeRDNYC (talk) 02:52, 3 August 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Okay, checkout User:FeRDNYC/Sandbox again, which I think is now ready as a complete reimplementation of the Main Page that works at all display widths, including on mobile. It depends on two new-er technologies, CSS columns and CSS flexbox, but support for both of those was sorted out long enough ago that everything seems to support them now, including the Godville app's browser (at least on Android). So, it should reflow to a comfortable layout everywhere, on screens both wide and narrow. On very narrow screens, note that the Intro to Godwiki section actually places itself before the Featured Article section, an enhancement made possible by flexbox. (The top row is actually a two-item flexbox, flowing in row-reverse order, and the Intro section is the first item in that part of the page.) -- FeRDNYC (talk) 02:07, 6 August 2018 (UTC)

So, all of this nonsense with the new infoboxes makes me realize that I'll need to check how User:FeRDNYC/Sandbox looks in the WPTouch skin, in addition to the other two (Vector/desktop and Minerva/mobile). Not looking forward to that, so I think I'll put it off until another day. -- FeRDNYC (talk) 21:10, 7 August 2018 (UTC)
While on hold on my phone (sigh) I took the time to check this all out and it looks just fine to me. I mean... for given value of fine.
It looks fantastic on desktop and mobile browser (Vector & Minerva) and I think it should go live immediately. The only thing worth considering is to add a note to the bottom with the magic link for WPTouch users. Perhaps:
Enable [ mobile-friendly view].
or something similarly straightforward would be enough? --Djonni (talk) 06:00, 13 August 2018 (UTC)
Yeah, I was thinking I'd look in the CSS for a class that might only be visible in WPTouch, in which case that link could be hidden behind that. There might not be one, but it can't hurt to look. It just means I have to dig through the three governing CSS files, which I haven't done yet.
As far as bringing it live... based on your screenshots (thanks!), I may be able to improve the WPTouch rendering a bit, first. Like, the squished-together lettering of the title is clearly a line-height issue, I should be able to specify a value to get it to stop doing that, so let me see if I can squeeze that in.
I don't know why the random image isn't... like... randoming. Or image-ing. One of those. But I'll try to figure it out. (Just, not very hard, because I care thiiiis 👌 much TBH.) -- FeRDNYC (talk) 06:40, 14 August 2018 (UTC)
OK, significant changes. I fixed the line height for the first two parts of the gray-box header. And, this?
"I was thinking I'd look in the CSS for a class that might only be visible in WPTouch..."
Believe it or not, I found one. Or, a combination of a class and an ID, each of which is hidden in either Vector or Minerva, but neither in WPTouch. So, by abusing those together, I've set it up so that at the far, far bottom of the page, a link to switch to the mobile skin should appear only when the page is viewed with the WPTouch skin.
Haven't really looked at the random image thing all that closely, yet. It seems to be mostly working OK for me, so it's possible nothing's wrong, and you just caught a bad image pull when you took the screenshot. Possible. (Unlikely.) -- FeRDNYC (talk) 09:02, 14 August 2018 (UTC)
Oh, DUH. Actually, there was nothing wrong with the randomimage in your screenshot, it just happened to catch that tiny "fast-forward" type icon, so the caption squished underneath it. Well, that'll happen. (I actually could move the text out of the image caption, now that I've got the page resizing properly, and it wouldn't do that anymore. I'll mull it over. Wouldn't really make too-small image pulls all that much prettier, anyway.)
So, I guess this is maybe ready already, now? Hmm. -- FeRDNYC (talk) 09:05, 14 August 2018 (UTC)
What the hey. Taking live. If it breaks anything I'm sure we'll hear about it. -- FeRDNYC (talk) 05:33, 16 August 2018 (UTC)
I got rid of the text in the random image box entirely, BTW. It's already titled "Random Image", so the caption was really kind of redundant. And it had a tendency to format poorly with different sized images, and/or different sized screens/skins. -- FeRDNYC (talk) 06:40, 17 August 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────My goodness it looks SO good. Haven't checked it in WPTouch (because yech) but certainly on all my devices in both of the other stylesheets it looks outstanding. Though a part of me kinda misses how inaccurately named the Featured Article of the Week was 😋 --Djonni (talk) 17:37, 17 August 2018 (UTC)

Yup, even on yech WPTouch it looks fantastic (and is even more noticeable in contrast to how it was). One thing I've only just realised — on the mobile skins there's no link to Talk:Main Page. It lacks the normal "Discuss" button at the bottom. I'm so used to coming here from recent changes that I'd never even noticed that before. Makes it harder for folks on mobile devices to find this, or even know it's here. #mobileproblems --Djonni (talk) 17:54, 17 August 2018 (UTC)
Heh. "Though a part of me kinda misses how inaccurately named the Featured Article of the Week was" — I'd actually changed that last week, on the old version, so that predates this update.
I had, at some point, noticed that there's no link here from the main page, making it an especially poor place to use for announcements and such. Oh well. I'm developing a very zen ability to just not really care about mobile's foibles, as there are so many. -- FeRDNYC (talk) 20:22, 17 August 2018 (UTC)
I added a note at the bottom of {{Mainpageintro}} about the main page's Discussion area, with a link to it for mobile users. Which makes the Intro box quite a bit longer than the Featured Article box, but... meh. Now we have the option to feature longer portions of the selected article, if we want. -- FeRDNYC (talk) 04:37, 18 August 2018 (UTC)

Many GodWiki pages need to be deleted

There are a lot of junk/clickbait pages that just redirect to the main page. Perhaps a moderator/administrator could look into removing them? --ElectroChip (talk) 16:22, 9 May 2017 (UTC)

There are certainly a lot of dead pages on the Wiki, which sadly right now doesn't have an active administrator other than the actual Godville Admin team who spending all their time hard at work on improving the actual game and its content for us all.
For now, we all can help a hypothetical future administrator do a deep clean of the wiki by adding the {{delete}} template to any page that you think an admin should remove one day. It's probably wise to provide a reason why you feel a page deserves deleting too, by doing something like {{delete|This page violates CP-symmetry and may cause vacuum decay, ending the Universe.}}
All pages that have the {{delete}} template on them appear in Category:Marked for deletion. This list will be one of the first stops, I expect, for any future admin to do a clean-out. (Hello hypothetical future admin, please know, if you're reading this, that we understand the very large pile of work you've been left with and deeply appreciate your hypothetical future work!)--Djonni (talk) 09:04, 9 June 2018 (UTC)
Just as a point of information, the pages that ElectroChip is talking about that "just redirect to the main page" most likely have been deleted, which is why they redirect to the main page -- without adminship, other users can't delete pages, but they can replace spammy/inappropriate page content with a quick #redirect[[Main Page]] to obliterate everything except the page title. I know that BlueStapler, and probably others, have taken the initiative to wipe out page-level spam and vandalism in that way, when necessary.
For truly deletion-worthy articles that just shouldn't be here at all, that's probably a better approach than setting the delete template since, right now, there's simply no expectation that'll ever be responded to.
The delete template still has its purpose, as it's a good way to indicate things like Templates that are no longer useful, or userspace subpages that the user no longer needs (since we can't even delete pages from our own userspace, annoyingly). -- FeRDNYC (talk) 14:43, 1 July 2018 (UTC)
I actually find it a little disorienting when an otherwise blank page simply redirects to the Main Page, particularly on mobile where redirects aren't breadcrumbed. Perhaps it's a preference-driven thing — I'd rather a clear {{delete}} tag on a dead page than an unexplained redirect to an unrelated default page. I also imagine a Hypothetical Future Admin finding a straightforward (if large) list of pages marked for deletion a little simpler than having to also go through the list of pages that redirect to the Main Page, though perhaps I'm too optimistic about the advent of the HFA. I seem to be an HFA Adventist, come to think of it, and act as if I believe that I can immanentize the coming of the HFA by preparing the Godwiki for His or Her manifestation... Hmmm. --Djonni (talk) 03:29, 2 July 2018 (UTC)
I won't dispute that it's disorienting, but how frequently does this really come up, in normal wiki use? Meaning, if you're not someone poking around behind the scenes?
Those articles shouldn't be linked to from anywhere, so the only way they're likely to be found by normal users is in search results. For those users, landing on a {{delete}} page dead-ends them while showing no useful information. They don't care that a page is flagged for deletion. OTOH, being redirected to the main page means they can continue browsing the wiki. For the average user with no interest in the administrivia of the wiki, that's likely the preferable outcome. -- FeRDNYC (talk) 12:29, 3 July 2018 (UTC)

Defunct Guild pages

A very large proportion of dead, short, unlinked, uncategorised pages are stubs that were created for guilds that no longer exist. I'm in two minds about how these pages should be treated, but I have a proposal.

  • I think we should have a new Dead guilds category (as sub-category of Category:Guilds)
  • I think we should have a new {{deadguild}} template that:
    • Uses the {{delete}} template as a basis, with similar design;
    • States that this guild is "not widely known on Godville";
    • Gives a link back to the so it's easy to check if the guild remains dead at any time;
    • Categorises the tagged page as a dead guild, obviously.

That way these pages aren't necessarily marked for deletion as such, but they are ready for a hypothetical future admin (HFA) to do a spring clean if the HFA decides to slough off that particular kind of dead weight. (Hello HFA, thanks again for your hypothetical future work!)

I would likewise propose that a page only be a candidate for tagging with {{deadguild}} if:

  • The URL for the guild states that it is "not widely known on Godville";
  • There have been no edits to the page for... lets say, 6 months? 12 months? This would allow baby guilds to grow enough to have a stat page.

The guild page could easily be checked by editing the candidate page, inserting the template, previewing the edit, and clicking the link in the template before saving your change.

Specifically, as an example:

RIP-gravestone grey.png

This article is for a guild that doesn't appear to exist.

The guild stats page matching this article states that The “Alcyone” guild is not widely known in Godville. If you are a member of this guild, or can confirm that the guild now exists, please remove this template.

Any thoughts on this from anyone? --Djonni (talk) 00:40, 10 June 2018 (UTC)

HTML layout and the width attribute

It's months old, but I'm manually reversing one of Holy Spirit of Hell's good-faith edits to the layout of the main page, because it blew out the width of the page beyond the right edge of the viewport. In doing so, I wanted to drop a quick note about dimensions in HTML layout and the width attribute. (This isn't meant to shame you or call you out, Holy Spirit of Hell, and the whole reason I'm posting this info here, instead of on your talk page or similar, is that I'm sure there are multiple people who could benefit from it.)

Also, let me say that the following is at the very least vastly oversimplified. (Yes, even considering how long it is.) You should really be getting this sort of knowledge from good sources like Mozilla Developer Network (MDN) or even "meh" sources like w3schools, not from me. Hell, I'm sure at least one thing I'm about to say is just plain wrong... I just don't know which one(s)!

Specifying dimensions for layout elements in HTML is generally fraught with peril. But there are different levels of peril:

  • Specifying exact pixel dimensions (e.g. width="640px") is evil and should be avoided at all costs, it's one of the main things that makes pages lay out improperly in mobile browsers, just for starters. (Image dimensions are somewhat of an exception to this, though even there it's problematic if images are placed at fixed sizes with no regard for how they affect the content layout on different size screens.) Point size dimensions (width="10pt") fall into the same category, as points are a fixed-size unit that doesn't scale.
  • Specifying dimensions in em units (width="10em") is slightly better, as ems are related to the font size the content is displayed at, so they'll be autoscaled to match the device's base font size (as long as the font size isn't overridden using a pixel or point size!) Still, while these dimensions autoscale to fit the display size, they're frequently not predictable enough to use for layout. There is also the rem unit (width="10rem") which is relative to the root font size, making it slightly more predictable since it means the same thing everywhere on the page, no matter what font size is set for that content.
  • Specifying dimensions in percentages, if one must specify dimensions at all, is best, and for the most part it's how Godwiki is laid out. But it's important to know what those percentages mean.
    • A percentage width in HTML is interpreted relative to the width of the element's container.
    • For that reason, width="100%" is by far the most commonly-used dimension in HTML layout, and it simply means "expand to fill all of the horizontal space available to me".
    • Percentages less than 100% are used when elements are placed side-by-side within the same container, to adjust how how the available space is allocated among them. Generally, if percentage widths less than 100% are used, they should be specified on multiple elements laid out horizontally, so that they all add up to no more than 100%, and ideally to exactly 100%.
    • Percentages greater than 100% tell an element to grow larger than its container, which is almost never what you want to do and will cause all sorts of problems, from elements overlapping to elements sticking out past the edge of the screen. Browsers will try to correct for some of this (by autosizing child elements to smaller than the >100% container size, for example) but at the very least you'll end up with a jorizontal scroll bar for no good reason.)

So, that's why changing two width="100%" elements to width="110%" and width="90%" will never look as intended. The percentages still add up to the same (200%). The total width of the elements is nearly the same. (If their containers are different widths it won't be exactly the same, though. Observe: 110% of 600px is 660px but 90% of 400px is 360px, so the total width increased from 600+400 = 1000px to 660+360 = 1020px.) But instead of two balanced elements, we've now got one element that doesn't fill its container, and leaves wasted space alongside it, and another element that sticks out of its container and disturbs the layout of the surrounding content. The correct way to adjust the width of width="100%" elements is to find which of their containers define the respective widths (using something other than width="100%", either smaller percentages or specific units) and adjust those dimensions, while leaving the elements in question set to width="100%" as, again, that just means "fill my available space".

Oh, and last but far from least:

  • Best by far is when we can avoid specifying widths at all, and allow HTML to flow the elements automatically. The width of block elements will automatically expand to fit the content they contain, up to the size of their containers. That's usually what we want. width="auto" makes this explicit, and specifying it can be useful if explicit widths were set elsewhere that need to be uninherited. width="auto" is also better than width="100%" because it accounts for things like padding and margins, whereas setting 100% width can force elements into those spacers (or force those spacers beyond the screen borders) under certain circumstances.

-- FeRDNYC (talk) 14:04, 3 December 2017 (UTC)

I'm actually going to amend this, some, to say that when talking about the entire page width (or, the entire content-area width, not counting things like sidebars), percentage widths are also some of the worst things you can use. In those contexts, "real" dimensions like em widths are far better than percentages, because those widths scale intelligently with the screen size, whereas percentage widths don't.

Some of the biggest problems we've had with formatting the wiki to be mobile-friendly have been with content formatted with something like width=60% or whatever. The problem is that the same content is going to take up 60% of the width of any screen it's displayed on — which is probably fine, for a desktop browser, but clearly is going to be a problem in a phone browser.

In fact, it was only by setting the width of {{Diary}} and {{Diaryquest}} to pixel values that I was able to make them readable on mobile browsers. (And I'm experimenting now with changing those widths to em widths, to better scale to different pixel densities.) By the same token, updating the Main Page sections to use em widths instead of width=55% and width=45% was a big part of creating the new mobile-friendly layout. (The other part was formatting them with CSS flexbox, so that they'll automatically rearrange themselves vertically if there isn't enough room on the screen to fit them side-by-side.) -- FeRDNYC (talk) 10:04, 17 August 2018 (UTC)

{{Diary}} and {{Diaryquest}} now both specify their minimum width or width (respectively) as 18em, to better scale with different screen dimensions and pixel densities. That has almost certainly changed the size of your existing boxes, and may even have changed it differently on different screens. Sorry, but OTOH this can also serve as a reminder that the Web is not a desktop publishing platform, and is not intended to be laid out like a magazine. Web content will always be resized and reformatted to serve the needs and interests of the reader, not the author — and this is as it should be. -- FeRDNYC (talk) 15:22, 20 August 2018 (UTC)

New shortcuts for numbers with superscripted ordinal (e.g. 1st)

I just borrowed the {{Ordinal}} template from Wikipedia, and created convenience templates {{1st}} {{2nd}} and {{3rd}} for anyone who wants to write numbers all fancy, like:

Code Output
{{1st}} 1st
5{{2nd}} 52nd
-10{{3rd}} -103rd
{{Ordinal|57}} 57th

NOTE: Please do not use these shortcuts in links or template calls. "1st" is not the same as "1st", and they cannot be interchanged in code, i.e.:

  • The 1st Line of Defense guild article cannot be linked to with [[{{1st}} Line of Defense]].
  • If you wish to get extra-fancy, you can write:
[[1st Line of Defense|{{1st}} Line of Defense]]
which produces: 1st Line of Defense.

Also, be aware that unlike Wikipedia's Ordinal, ours only does superscripts. They're always enabled. -- FeRDNYC (talk) 06:10, 10 July 2018 (UTC)

I've put this neat little template to use in my page's infobox! Very nice :) --Djonni (talk) 08:54, 2 August 2018 (UTC)

First two mobile-friendly infoboxes are live! (Please test!!)

Everyone, the first mobile-friendly Infobox (see "Formatting Infoboxes in the mobile view") is now live. All Pets articles that use a Template:Pet infobox (that would be all of these) will now have an infobox that will adapt to your screen size when viewing the page.

Update: As of 23 July 2018 02:45 (UTC), Template:Town is also upgraded with the mobile-friendly layout , so on any page that uses {{Town}} the infobox should adapt to the screen size automatically. -- FeRDNYC (talk) 02:50, 23 July 2018 (UTC)

I'd like to ask as many users as possible, if they have a chance, to look at as many Pet articles as they can, and on as many types of devices as we can get sampling from. Whether it's a tablet device, any model iPhone or Android phone, heck even an old Palm Pre or whatever. And if you just want to check it out but don't have access to any of those, you can use the Mobile view link at the bottom of any page in the Godwiki to switch into the mobile skin from your desktop browser. In fact, that can be some of the best testing, because then you can change the window size and see how the page responds.

What you should see, if there are no problems, are:

  1. Right off the bat, the infobox is cleaner in ways you probably won't notice, but trust me, it's there. While I was updating the code I corrected a lot of structural errors that were causing lots of extra table rows, double borders, etc. All of that should be gone.
  2. Other than that, in the desktop browser view there should be no visible difference whatsoever.
  3. In the mobile view, what you should see is a page that keeps the normal formatting with the infobox on the right and text flowing to its left, unless the window/screen becomes too narrow, in which case the infobox will center itself on the page and push the text down below it. This should happen pretty seamlessly in a web browser (in mobile view) as you narrow the window.
  4. On a phone, most likely the page will start out with the centered, no-text-alongside infobox, as it's meant to.

Please report any issues you see, either here or on my talk page. I'd like to get the rest of the infoboxes updated next week, if there are no concerns about the Pet articles. -- FeRDNYC (talk) 02:54, 21 July 2018 (UTC)

I just fixed a couple of issues with the {{Pet}} infobox sizing on mobile, one that blew out the frame too wide on narrower devices, the other that made the box too _narrow_ on wider screens (like tablets). -- FeRDNYC (talk) 10:20, 22 July 2018 (UTC)
I checked on your update to the pet template, and on my iPhone 5S, the box is blown out to the left. It does look a lot better, minus the shift to the left -- Holy Spirit of Hell (talk) 01:08, 24 July 2018 (UTC)
Hmm, thanks. I'll take a look. Not immediately showing up on my phone, but I'll poke around with the mobile browser skin, and some device simulators if need be. Did you happen to notice if it was the same on every pet page (or, if you looked at more than one, all of those)? -- FeRDNYC (talk) 03:29, 26 July 2018 (UTC)
Sorry, H.S.H., I can't seem to replicate. I tested the site in Safari on an emulated iPhone 5 and an emulated iPad Air, as well as in both Safari and Firefox on a real iPhone 6S (thank you, BrowserStack free trial!), and in every case the infoboxes looked as expected in both device orientations.
I captured a screenshot of the Terror Bull article on every one of those platforms/browsers I mentioned, in both orientations. There's a gallery post showing all of them here: — can you take a look and let me know if anything there fails to match what you're seeing on your 5S? -- FeRDNYC (talk) 04:28, 26 July 2018 (UTC)
In re-reading your comment, H.S.H, I realized I should maybe define "blown out" as I used it to describe the old infoboxes. The issue with the existing Infobox templates (the ones I haven't updated) is that the wiki mobile skin forces them to 100% width on any smaller-width screens. That can cause the columns of the infobox to become stretched wider than intended in ugly, weird ways. For example, here's the Bully Mammoth article on my Galaxy S6, in landscape orientation: . You can see that there's a large box to the right of the infobox, because the table that contains it is forced to be the entire width of the screen.
With the new infobox changes, that won't happen. (or, it's not supposed to, unless there's a bug in my changes.) Instead, what's supposed to happen is that the box will keep its specified width and just center itself on the page. If you're seeing boxes shifted to the left, but not distorted (improperly sized)... well, I'm not sure what's going on there, since as I said in my previous post I wasn't able to reproduce it in Safari or Firefox on BrowserStack's emulator farm. But, since I wasn't running the Godville app on iOS, it's possible that browser is slightly different. Still, if you can give me more details on the issue you were seeing, I'll try to look into it further. Thanks. -- FeRDNYC (talk) 06:15, 29 July 2018 (UTC)
It's now been a week since Holy Spirit of Hell's report of iPhone issues with the new infoboxes, and still no word back. H.S.H. doesn't appear to have been around the wiki much in that time, though... I guess I'll wait to the end of the week, and then decide how to proceed if I still haven't heard anything. -- FeRDNYC (talk) 01:30, 2 August 2018 (UTC)
GodHoly Spirit of Hell , when you say "on iPhone", are you using the Godville app's built-in browser for viewing the wiki? And, if yes, have you told the built-in browser you want the "desktop" view?
I ask because, for unfathomable reasons, the app's built-in browser's 'desktop' view uses totally unique CSS that is just awful and breaks a lot of basic Wiki formatting. What you describe sounds like standard SNAFU behaviour in that use case. --Djonni (talk) 08:51, 2 August 2018 (UTC)
Apologies for (re)joining the conversation on this late, I've been organising a move to a different hemisphere and it's taken more cognitive budget than I had available on a daily basis. While I'm not finished, I've passed enough milestones that my brain has a little more space again!
Taking a look at the Pets and Towns infoboxes live across a sampling of pages they look good so far on a 6" device (Chrome on Android) and a 5" device (Chrome on Android). All my other mobile devices are packed into storage, sadly!
I'd say it's ready to be rolled out further, pending HSH adding further information above! --Djonni (talk) 08:51, 2 August 2018 (UTC)
Well, no word back from Holy Spirit of Hell after a week and a half. I left a talk page message (only just now), hoping that might get their attention, but I'm inclined to go ahead with this as-is. I'll convert the rest of the infoboxes when time permits, and if we do hear anything back I'll look into it. -- FeRDNYC (talk) 02:15, 6 August 2018 (UTC)
Done, see below. -- FeRDNYC (talk) 11:19, 7 August 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Over on Holy Spirit of Hell's talk page, H.S.H provided this screenshot of the Terror Bull rendering, which is definitely not how it's supposed to look. Still investigating. I've requested a survey of how various other Infobox configurations render on the same device, now that they're all upgraded with the new code, so I can hopefully get a handle on exactly what circumstances lead to that glitch. Hopefully that'll get us closer to figuring out the "why", and then we can work out how to prevent it. -- FeRDNYC (talk) 19:50, 7 August 2018 (UTC)

Ohhhhhhhh, I see what's happening!
The rendering that H.S.H screenshot only occurs if you view the wiki using the desktop skin on a phone-sized mobile device, which isn't really wide enough to render that skin properly. If you view the pages using the mobile skin, they look fine.
One complication seems to be, if you switch to the desktop view in the Godville app mobile browser, it doesn't look like there's any way to get back to the mobile skin! The links that would normally be shown at the bottom of the page aren't there. However, this link should return the browser to the mobile skin: Switch to Mobile Skin.
I'm not sure how to prioritize solving the rendering issue with desktop-skin-on-mobile. My initial inclination is to not really worry about it (and instead focus on getting people switched back to the mobile skin). -- FeRDNYC (talk) 20:11, 7 August 2018 (UTC)
The issue, in a nutshell, is that the Godwiki can be rendered in one of three skins:
  • The standard desktop-browser skin, Vector
  • The mobile skin, Minerva
  • The desktop-site-requested-on-a-mobile-device skin, WPTouch
Without access to edit the site/skin CSS itself, it's generally possible to optimize for one or, at most, two of those, at the risk of causing issues in the third. Which is what we're seeing here. -- FeRDNYC (talk) 20:52, 7 August 2018 (UTC)
This is what I was trying (without much success) to refer to above. That switch to mobile skin link you found/crafted GodFeRDNYC  is pure gold, I and many others have had to delete and reinstall the app to fix that! That deserves its own (pinned) Talk topic here on this page, honestly. That skin (WPTouch) causes lots of layout and formatting problems, all over the place. Hitting switch to desktop on the GodWiki in the GV app's built-in browser effectively breaks the wiki, with no (until now!) way to switch back. --Djonni (talk) 02:21, 9 August 2018 (UTC)

New Template:Equipment

I admit, it's not super necessary, but it just felt weird that we didn't have a Template:Equipment to go with all of the other infoboxes. So, now we do. It's very simplistic, but with 117 articles in Category:Equipment it felt right to start standardizing them. I'll probably try to go through and apply the template to those 117 articles starting next week.

Three items of note:

  1. This template is unique among the infoboxes in that it uses a generic image, if one is not supplied in the template call. (You can see the image on the template page.) However, it's definitely preferable to supply a specific image to override the generic one.
  2. I included the "Durability" stat that I noticed was already listed on many existing Equipment articles, even though TBH I'm not really sure that actually means anything. (Meaning, I suspect that equipment items can be found at any durability level. But, I could be wrong!)
  3. This template uses the new infobox code for mobile browsers.

As always, please report issues, either here or at Template talk:Equipment. -- FeRDNYC (talk) 01:15, 3 August 2018 (UTC)

The absence of an equipment infobox template has occured to me as odd more than once, and I love the default image (both in principle and in the specific choice). I feel like a default image is worth considering for other infoboxes, it's a quick way to add a little polish to stubs. Perhaps the default image field might include a caption with a link to upload a {{PAGENAME}}.jpg...? We've discussed #ifexists being expensive before, and it's probably unwise to include them in template defaults, but it sure would be elegant if a template found an existing PAGENAME.jpg file. Just brainstorming :) --Djonni (talk) 01:58, 3 August 2018 (UTC)
I'd be reluctant to do that (the {{{PAGENAME}}}.jpg thing) for two reasons. No, three. None of which have anything to do with the code performance.
  1. The images might not be JPGs. They might be .PNG files, or GIFs.
  2. It's preferable to let people use their own filenames for uploads.
  3. The previous is especially true when replacing images.
Say someone uploads a Terror Bull.jpg image. That image may be used somewhere in some other article. Now, if someone wants to replace the image in the Terror Bull infobox, the way to do it would be to upload a new image (with a unique filename), and update the template call. If they're given the impression the image "should be" named Terror Bull.jpg, and they upload their new image to overwrite the old one, then it gets changed everywhere, which may not be desirable to anyone who's used that image elsewhere.
I think we could have generic, "default" images for the other infoboxes, but they should be just that: A generic image that's used unless an image filename is specified. Typing a filename into the template call isn't particularly onerous. -- FeRDNYC (talk) 02:38, 3 August 2018 (UTC)
Mmm, you make good points there, particularly about replacing images. Perhaps just something like <small>[[Special:Upload|Upload]] an image.</small> would be enough. And a [[Category:Pictures needed]] might be clever, come to think of it? --Djonni (talk) 08:47, 3 August 2018 (UTC)
I think showing an upload link makes sense — good idea. Right now {{Picture}} only shows a page-edit link, which is only useful if you've already uploaded the file. Guiding people to Special:Upload as the first step in adding photos is probably more useful.
In fact, it might be possible to auto-template the page as {{Picture}}-needed if the default image is used. (Or just whenever the |image= parameter is missing, even in infoboxes that don't have a default image.) Whether or not that will actually work depends on whether the Godwiki css includes some form of the same classes that Wikipedia uses for message boxes, that forces them to the top of the page no matter where they're placed in the article source. Which, come to think of it, I bet it doesn't. ...Still, I can just stick the {{Picture}} template before the infobox code, and it should end up in the right place.
I'll take a swing at adding that (along with a parameter to override it, I guess, just for peace of mind) to some of the infoboxes, starting with {{Equipment}}. And also have them do auto-categorization into a sub-Category:Infobox picture needed on the same criteria. (Although {{Picture}} will auto-categorize the page into the general Category:Pictures needed, so maybe both is overkill.) This way, the modifications to the add-an-image flow (pointing to Special:Upload before / instead-of the edit link) can be made in the {{Picture}} box instead, and they'll benefit all pages it's used on. -- FeRDNYC (talk) 10:55, 3 August 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Yesss, putting {{picture}} at the head of the infobox is a very clever approach. And I don't hate having a special category for infobox pictures, I think that's a good category to have available when one's looking for some quick improvements to make. I personally would say that an infobox without a picture rises to a higher priority than a general stub without a picture, I don't think having it categorised both ways is overkill.

This is one of those times that having already updated the Guidebook would be helpful — {{picture}} could point to an upload-and-edit guide. Maybe it's worth touching that specific part of the guidebook up immediately. Doing.png Not now... (TODO) --Djonni (talk) 05:35, 4 August 2018 (UTC)

It's good enough, I think, to have {{picture}} point into Creators_Manual#Images without rewriting. Notwithstanding that it could be improved there. --Djonni (talk) 05:57, 4 August 2018 (UTC)
For the general case of "this article needs pictures", agreed, but actually for the Infobox case specifically it's kind of overkill, because they don't actually need to worry about any of that. To add an image to an infobox all you do is upload the file and enter the filename, you're spared having to worry about the intricacies of [[Image]] linking.
(And even when it comes to the syntax, if only the explanation at the top of Special:Upload actually demonstrated [[Image]] syntax instead of [[File]] and [[Media]], I might say it's as good as the one in the Creators Manual.) But, regardless, because infobox image-adding is even simpler, maybe we should have a special version of / path through {{Picture}}, where we just instruct them to upload a file and paste the filename into the template as an | image= parameter, rather than dumping all the rest of that noise on them? -- FeRDNYC (talk) 10:08, 4 August 2018 (UTC)
Limited on time right now, but wanted to say: 1) Yes, actually, that makes sense (not to point editors to the Creator's Manual just to add an infobox image). Perhaps a short, sweet ===Adding an image to the template=== should be in each Template:XX/documentation page, with a link in the default image table cell (e.g., <small>[[Special:Upload|Upload]] an image and [[Template:XX/documentation#Adding_an_image_to_the_template|put it here]].</small>)? --Djonni (talk) 02:34, 9 August 2018 (UTC)
Oh yeah, and point 2) I will (I will I will) start adding {{equipment}} to existing pages, aaaany day now. --Djonni (talk) 02:35, 9 August 2018 (UTC)
Tadah! --Djonni (talk) 08:03, 13 August 2018 (UTC)
And already up to 9 pages now, woo! 🤩 I shall honor your diligence by being lazy and continuing to not do any of those myself. 😏 You're Welcome™! (But maybe I'll get to that {{Picture}} stuff we discussed... after I sort out those last issues with the new Main Page.) -- FeRDNYC (talk) 08:12, 14 August 2018 (UTC)
Hey... hold off, if you can, before doing any more of these. I just had an idea. -- FeRDNYC (talk) 13:08, 14 August 2018 (UTC)
Never mind, idea implemented! -- FeRDNYC (talk) 16:12, 14 August 2018 (UTC)
Also, BTW, I didn't realize I'd broken the parameter check so that you couldn't include a blank image parameter without breaking the default image, but I've fixed that now. So, feel free to make an empty | image = part of your boilerplate, it'll work fine! -- FeRDNYC (talk) 16:14, 14 August 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Tick.png Done The auto-{{picture}} templating we'd discussed is now in place on {{Equipment}}. For the moment it just uses the standard Template:Picture, that can be adjusted later on if we develop any specific new flows. I've already taken the liberty of removing the manual (now-redundant) {{picture}} transclusions from the Equipment articles where you'd already added it (there were only a couple). -- FeRDNYC (talk) 04:11, 15 August 2018 (UTC)

The automatic {{picture}}ing looks better than I feared, looks seamless. If I notice any funny edge cases or anything as it gets rolled out I'll bring it to your attention but I can't imagine what. 👌 --Djonni (talk) 17:42, 17 August 2018 (UTC)

Remaining Infoboxes updated with mobile-friendly code

I've just finished updating the {{Monster}}, {{Artifact}}, {{Beastie}}, and {{Guild}} Infobox templates with the same mobile-friendly code that was already in place on {{Town}}, {{Pet}}, and (the so-far-unused) {{Equipment}}. That covers every article-space infobox in the system, the only remaining ones are {{Hero}} and {{Usergod}}/{{Usergoddess}}, which I may get to at some point in the future, but they're lower priority.

Along the way, I cleaned up the code in all of them, to varying degrees (dependent on how bad the existing code was). And, some specific items of note:

I fixed the auto-categorization for the specialty categories (Category:Bold Artifacts, Category:Healing Artifacts, Category:Activatable Artifacts), which was completely broken as it was dependent on nonexistent parameters.
It now works off the |type= parameter, case-insensitively and ignoring whitespace, as follows:
Also, | monster = something will cause the article to be placed in Category:Monsters' Artifacts. (This is in addition to always placing the article in Category:Artifacts.)
This means that it should no longer be necessary to manually place Categories in Artifact articles at all (if they are using {{Artifact}}), and when editing an article that uses the template it is preferable to remove redundant manual categories. This is so that, if there is a mistake in the template data that changes the category when corrected, there will be no conflict between the categories exported by the template and the categories placed in the article.
This template got the biggest changes of all. In addition to massive code cleanup (it was a MESS)...
  • I completely re-wrote the processing of the multiple |founder= (plus |founder2=...|founder5=) parameters, to create a bulleted list of all the provided founders.
  • I re-wrote both the |friend1=...|friend8= and |foe1=...|foe5= processing, so that both Allies and Rivals are displayed as a bulleted list taking up a single cell, instead of one-row-per-entry like the previous code.
  • I increased the infobox width to 25em. I felt that was a better fit with the new bulleted Founder(s) list, as it tends to be wider.
  • |position=left is no longer available for this template, due to the mobile-friendly code change. That's true of all the infobox templates, post-change, but this template seems to be the one where position= was most used. Any guild pages designed around left-aligned {{Guild}} infoboxes will need to be redesigned to accommodate the right-aligned infobox. I apologize for the inconvenience, but I'm afraid it's a necessary tradeoff to get proper formatting on mobile screens.

If any of my changes tonight are going to be problematic for people, it's likely the changes to {{Guild}}, either technically (there might be bugs) or philosophically (you might object to the decisions I made). In either case, please bring up the issues here and we'll come to a resolution. -- FeRDNYC (talk) 11:18, 7 August 2018 (UTC)

Template:Navboxboss-monsters renamed to Template:Navboxbosses

The name {{Navboxboss-monsters}} just struck me as long and awkward to type, so I've renamed the template to {{Navboxbosses}}. The old name is now a redirect, so existing calls will still work and you can continue to use the old, longer name if you prefer. -- FeRDNYC (talk) 09:22, 14 August 2018 (UTC)

New mobile-friendly Main Page

The Main Page of the wiki is using a new layout that should automatically size itself to your screen, even on mobile devices. Please kick the tires, but if we get a flat it's your fault! 😜

The page will look not-great-at-all in the "Desktop" mode on a mobile browser. That skin is just terrible and nothing will ever look very good in it. However, in the interest of saving people from its awfulness, when you are viewing the site with that skin (only), the bottom of the main page will now include a link to "Switch back to the mobile skin". -- FeRDNYC (talk) 05:51, 16 August 2018 (UTC)

Right now, the ‘desktop skin’ for mobile is much easier to navigate around, due to the smaller font, the mobile version has a lot of scrolling around. For any further improvement, I’d suggest making the mobile fonts show up smaller if possible —Holy Spirit of Hell (talk) 03:52, 25 August 2018 (UTC)