Talk:Main Page

From GodWiki
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.

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 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)
Hmmm 🤔 I'd be pretty hesitant to permanently reduce font sizes on a particular platform like that (and without an admin, I doubt it's feasible). But you might find that opening the page in your phone browser, rather than the app, gives you more control over font sizing. I know in Safari on iOS it's pretty straightforward, less so on Chrome or Firefox, but still possible.
Considering how many Godville users are using low-cost devices with small screens, or have a vision impairment or other accessibility need, making text size and touch target size smaller than default seems a little problematic to me. --Djonni (talk) 06:18, 25 August 2018 (UTC)
I agree there are certain areas where the fonts are a little oversized, though the most glaring ones are things like section headings which we especially have no control over. We could change the body text size, but I'm not sure how much benefit there would be, and as Djonni says it could cause issues for other people using the wiki.
And when I say that, I mean we totally couldn't change the body text size, either — except by doing something completely insane, like editing every individual page to add some code. But even if we could (which we can't, realistically)... -- FeRDNYC (talk) 19:15, 28 August 2018 (UTC)
But it's true, the WPtouch skin definitely packs more text onto the screen, though I personally feel it's at the expense of comfortable navigation. Lists, in particular, are squeezed way too tightly together, making it difficult to tap on any individual item without potentially hitting an adjacent one. The mobile skin adds extra space between each item to help stave off that problem, and though I don't feel it's done in the most attractive way I do appreciate the effort.
I don't know if you've explored the mobile skin lately, H.S.H, but IMHO it's a lot better now that basically all pages reformat themselves to fit the display so there's no horizontal scrolling. Like I said, it definitely isn't as compact and space-efficient as WPtouch, but I feel it makes the right choices for the most part. Especially when you're browsing by touch, there is such a thing as too compact. The way the Godwiki mobile skin renders is pretty much equivalent to standard Wikipedia's mobile rendering, in terms of font size and etc., and I trust them to have looked at the issue and come up with the solution that works for the majority of people.
One big difference between Godwiki and Wikipedia mobile sites is that on Wikipedia, tapping the Desktop link at the bottom of the page switches you to the real desktop-browser interface: impossibly tiny text, huge page layouts, the works, exactly as it looks in Chrome or Firefox on my computer. Personally I'd prefer that for Godwiki, if the user really wants a desktop interface they should get it. Better than this halfway-measures WPtouch abomination. But, again, that's completely out of our control I'm afraid. -- FeRDNYC (talk) 19:01, 28 August 2018 (UTC)

New convenience template for referencing Godville Blog posts

Since the Godville Blog is one of the few outside resources we ever cite as a reference on this wiki (see History, especially), and in the interest of encouraging more of that (where appropriate), I've created a new convenience template {{Cite blog}} for creating links to Godville Blog posts.

Just give it a post number, and it'll create a link to that post. If you leave out the post number, it'll just provide a general link to the blog (as seen in my opening paragraph):

Wikicode Renders as
{{Cite blog|117}} Godville Blog, Post 117
{{Cite blog}} Godville Blog

More documentation, including an example of how the template can be used in creating citation references in articles, can be found on the template page. I may add additional parameters, like the ability to provide a title for the linked post, if there's any interest. -- FeRDNYC (talk) 13:50, 1 September 2018 (UTC)

Main Page styling tweaks

I just tweaked a bunch of style/layout code on the Main Page, all minor changes individually but they add up to a perceptible difference, hopefully for the better. In case anyone notices there have been changes and is curious what they were, details of the changes made:

  • Styling of section boxes cleaned up:
    • The heading is now "attached" to the border on three sides, and shares its color; hopefully that looks a bit cleaner
    • Some boxes had mismatched header/border colors, I've fixed all that up
    • The inner spacing/margins was also inconsistent between boxes, now they use identical outer margins and (except for 'Random Image') identical internal padding
  • Section colors updated:
    • 'Random Image' now matches: purple header/borders, light purple background (the background and borders were light blue, before)
    • 'Did You Know?' now has a color scheme of its own, in shades of orange (just because)
    • The blues of 'Intro...' are bluer, the greens of 'Featured...' are greener
  • The boxes no longer touch each other (it always looked weird with the different border colors)
  • 'rem' units are used much more extensively (rather than 'em' or 'px'), which should give more consistent scaling

I should really make a "Godwiki Announcements" template/page for this stuff, instead of stuffing it on the Talk page. -- FeRDNYC (talk) 00:51, 8 September 2018 (UTC)

Deprecation of Template:Pet

Following some discussion, we've decided to retire the {{Pet}} template, and instead use {{Monster}} for all Monster articles (including Boss-Monsters and Pets), so that improvements will be shared among the various types automatically.

I've placed the following notice at the top of the {{Pet}} documentation:

Important.png This Template Is Deprecated — USE {{Monster|pet=yes}} INSTEAD
{{Monster}} can now create Pet infoboxes (since all Pets are Monsters), it should be used instead of this template. The syntax is exactly the same, simply add |pet=yes to the code. So, for example...
OLD: {{Pet|image=example.jpg |description=A beast |levels=12-32 |totem=A Guild}}
NEW: {{Monster|image=example.jpg |description=A beast |pet=yes |levels=12-32 |totem=A Guild}}
See Template:Monster for full documentation.
This change will allow Pet articles to benefit from any improvements made to {{Monster}}.

I'll go through and convert the existing Category:Pets articles that use {{Pet}} over to {{Monster|pet=yes}} when I can (except for Alpha Centaur which is already converted), but please use {{Monster|pet=yes}} on new Pet articles (or updated ones), and feel free to convert any uses of {{Pet}} that you happen to come across. Thanks! -- FeRDNYC (talk) 00:52, 18 September 2018 (UTC)

Oh, and just for the record, |pet= can actually be set to any common positive-state value, so |pet=y, |pet=true, |pet=1, |pet=on, etc. are all just as good. -- FeRDNYC (talk) 00:55, 18 September 2018 (UTC)

Yellowtick.png Partly done — I'm now about 2/3 of the way through the Pet articles, 15 more to go. -- FeRDNYC (talk) 00:46, 19 September 2018 (UTC)