Talk:Main Page

From GodWiki
Revision as of 01:08, 24 July 2018 by Holy Spirit of Hell (talk | contribs) (First two mobile-friendly infoboxes are live! (Please test!!))
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)

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)

Sidebar problem

The "Main page" link on the sidebar is actually a link to "INVALID-PAGE," which in turn is a redirect to the appropriate Main_Page link. This seems like it should be fine, but it has the unfortunate side effect of leaving "Redirected from INVALID-TITLE" at the top of the main page after you've used the link. It also causes problems with namespaces, which you can see if you visit a page under a different namespace and then click on "Main page."

I'm not sure how to fix this, so if someone with sufficient rights could check this out, that would be great. Benjamaster1 (talk) 22:48, 18 February 2016 (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 he 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)

It's time: Diary and Diaryquest templates now default to new "superhero" style

I've just updated both templates to use the new superhero style by default. As a result, all quest and diary boxes on the wiki should now go from looking like this:

Hero's Stats ↓
Invent the wheel
Hero's Diary ▼
4:20 Wrote something irreverent and snarky about a town or quest or whatever

To looking like this:

Invent the wheel
!Hero's Diary
4:20 Wrote something irreverent and snarky about a town or quest or whatever

You can revert boxes to the old style by adding "style=hero" to the template parameters. -- FeRDNYC (talk) 08:47, 10 June 2018 (UTC)

Formatting Infoboxes in the mobile view

I'm considering a rather radical change to how the formatting is done to embed Infoboxes in wiki articles. (Infoboxes are the boxes in the upper-right corner of many articles, generated via templates like {{Monster}} or {{Town}}, that present some basic stats common to articles of that type in a structured format.) This change would hopefully be virtually invisible in the desktop view, but it would greatly affect the mobile skin, for reasons I'll explain.

So, because this would be such a big change, I wanted to seek out input and feedback on both the theoretical and practical aspects:

  1. The idea itself
    Do people feel this is actually an improvement, or do they prefer the way it is now?
  2. The implementation
    Any bugs or technical issues that show up for people using different browsers/devices/etc.

Basically, the current mobile skin has a few unusual CSS rules that were thrown into it, no doubt to work around issues with formatting in the app browser. One of them, and IMHO the most problematic, is the one that forces all HTML tables in the article content to fill the entire width of the display. Since Infoboxes are tables, they're all affected by this rule, and the results are IMNSHO extremely poor. But, since it's in the site CSS, there's no way to turn that rule off without admin acces to edit that CSS.

However, I've found that it's possible to work around the rule, by abusing (I'll admit it) the code that handles right-aligned, thumbnail-sized embedded images. Those images are displayed in a very smart bit of code (in contrast to the heavy-handed table overrides) that responds to the width of the display device, formatting them normally (right-aligned, with text flowing to their left) when there's room, and automatically pulling them into the center of the screen with no text on either side if the display is narrower. In my testing I've discovered that the same logic can be activated for Infoboxes, and I feel it looks far better on both wide and narrow devices.

I've put two examples of my proposed formatting change onto a single page, User:FeRDNYC/TestMonster (ignore the name). There you can see copies of the body content for both the Ballpoint Penguin and Herowin articles, but with the Infoboxes updated to leverage the responsive image-alignment code.

If you view that test page on a mobile device, or in the mobile skin on the desktop (by scrolling to the very bottom and clicking "Mobile view"), you'll be able to see how the Infoboxes would be formatted following this change. Both original articles are linked to, so you can compare them to my version.

If anyone has a moment, please do check it out, especially if you have access to any type of mobile device. I've tested it in Google Chrome on my computer, and my Android phone, but I'd love to hear feedback from anyone who looks at it using an iPhone, iPad, or any other tablet device, as I don't have access to any of those devices to test it myself.

My thinking is, if people like this change and it doesn't cause any problems, that all of the Infobox templates across the wiki would be updated to override that width=100% styling and make use of the responsive formatting. Some other templates, like {{Diary}} and {{Diaryquest}} would probably also be included, though they'd default to being left-aligned instead. -- FeRDNYC (talk) 15:09, 1 July 2018 (UTC)

I have noticed problems with infobox formatting on mobile too, and wondered how amenable it would be to improvement. I admire your creative adaptation of existing features into unexpected implementations ;)
I'll have a chance to test it on an android tablet screen and in a handful of desktop browsers in the next day or two, but I've decommissioned all my iOS devices so someone else will need to take up that testing. Meanwhile, I might try to hunt for some of those infoboxes where I found myself cringing on mobile, if I can find them again, and try to view the test examples you've made up in as many various ways as I'm able. --Djonni (talk) 03:14, 2 July 2018 (UTC)
Cool, thanks. For the most part, the ones that have seemed problematic on mobile were probably ones where the forced width causes weird explosions of the table borders. Like, you'll have an infobox that randomly grows a big empty column to the right of its content. There's a bunch of that scattered around the wiki.
If the width is no longer being forcibly expanded (or, if it is, but only within the <div> container that holds it, which is where the width is constrained) that should no longer happen. Honestly that issue is the main impetus for me doing this, as there's no good way to account for a CSS-forced width=100% !important from within the HTML source. -- FeRDNYC (talk) 11:48, 3 July 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)

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

Everyone, the first mobile-friendly Infobox (see "Formatting Infoboxes in the mobile view", above) 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)