Forum:Organization Overhaul

Forums: Index > The Labyrinth of Time > Organization Overhaul


		DrakeyC - Crossing the distant night...Wandering the desert sea...The gods' voices are mirages... TALK - 18:08, December 30, 2015 (UTC)



		Short and simple - Techno and I were talking on the IRC, and think we could/should adopt KHWiki.net's method for organizing subpages and other content. Take Xehanort's page, for example. That's the basic model we would look at - Boss pages (with subtabs as needed), Other Appearances (with Dissidia and other dedicated subpages as subtabs), Gallery, Quotes, and Etymology (which is already its own namespace). Gameplay stats, either for the base game and spin-offs, could also be moved - let's be honest, our stat growth tables are massive and perhaps could be moved off. To my recollection, most characters fought multiple times have the info for the fights on one page, so this mean someone like Kefka have "Boss" and "Final Boss" for his tabs. Sephiroth would be "FFVII / CC / Bizarro Seph / Safer Seph. This would not only improve navigation by having all this options right at the top of pages, but pages like Cloud Strife could be substantially reduced in size without losing any content. I'd also like to revive the subpages discussion at this time with regards to Theatrhythm, Record Keeper, and perhaps other games that may have enough gameplay info on characters to warrant splitting off

Discussion


		_{18:13, December 30, 2015 (UTC)} Technobliterator ^Talk



		Not only does this reduce pages in size, it also drastically improves load times and manageability, making pages miles more portable for mobile devices and in general. This is very easily achieved and I 100% support this idea. I can think of many ways to achieve this. The question is, though: do we want to include these Gallery/Quotes/etc pages in separate namespaces like Gallery:Cloud Strife, or just subpages, like Cloud Strife/Gallery?


		Kaimi - "No matter how dark the night, morning always comes. And our journey begins anew." TALK - 18:39, December 30, 2015 (UTC)



		Yes! I support this idea! Regarding namespaces: would we need to kind of 'register' that with central Wikia or not? RWBY Wiki utilizes subpages, so it depends, but I think subpages would be the most natural choice at this point since we have a lot of articles in subpages (like Record Keeper's weapons and armor pages), so consistency choice, I guess. Also, this might be a personal preference but would it be possible to have that subpage/namespace list if it comes to that sliding as the page is scrolled? Well, I can always hit "Home" in the keyboard but sometimes I'm that lazy. OTL Is there an article you think is of an exceptional quality? Vote for it here!

I made a proposal for dividing up pages on Forum:Character pages and Other Appearances. I think we're better off splitting the articles by each game/story vs. gameplay, then splitting off things like Gallery and Quotes which are still going to only expand with more and more games [Though I still admit a Gallery page including every image of Cloud can still be useful to users].

We could still work in the top-nav, but it wouldn't be preference. JBed (talk) 18:42, December 30, 2015 (UTC)


		_{21:12, December 30, 2015 (UTC)} Technobliterator ^Talk



		It only requires a Special:Contact message to add a new namespace. Subpages are probablyt the better choice, the only difference between using a subpage and making a new namespace is that the new namespace does not add to the article count, while the subpage does. I personally don't think this is worth it, as the only one that makes sense to be a namespace is Gallery, yet we have Concept art pages already. Having the list appear scrollable might be more difficult, not to code, but to organize how we're doing it. Where do we put it, the right rail, on the left of the page, on the bottom widget? Of course, I thought about it, then I realised you're using monobook anyway, so none of these would help you. :P As for implementing this, I'm going to create a template at the top (with a Lua module), that allows you to enter the name of the enemy page(s), the other appearances page, the gallery page, and the quotes page. These will default to {{PAGENAME}}/Other appearances, {{PAGENAME}}/Gallery and {{PAGENAME}}/Quotes, but when a param for boss is entered, add a {{PAGENAME}} (boss) in by default, or a different name for any of them can be entered/additional ones can be added. This would be standard across most, but we can change things up for more specific cases - for Gilgamesh, the main Gilgamesh (character) page could have tabs for each of his appearances, while Gilgamesh (Final Fantasy V) would have the more standard tab with just the Gilgamesh (character) tab in front of it, same for Cid. We could also do this for Games, and have the Artwork, Translations, and Version differences tabs as well; hell, we could probably even have pages like list of weapons.

I would rather not split the pages at all. If we're going to split pages, I'd prefer to have JBed's method.

I also think the topnav is very, very ugly. No seriously, I really rather not have the topnav, and you'd be hard pressed to convince me otherwise. It's annoying because you have to scroll up to the top of the page after reading the page. This is why we have navs on the bottom of the page. ScatheMote 00:16, December 31, 2015 (UTC)


		BlueHighwind ^{Q? 00:35, December 31, 2015 (UTC)} TALK - So if you care to find me, look to the Western Sky!ツ:



		Something needs to be done about Cloud's page, especially. I would cut out every other appearance into a subpage, and continue splitting as needed. But no, I don't really want this to be a general thing because you'll end up with like three pages for that one bounty hunter chick from FFIX who fought with Amarant that one time. Remember her? Can't remember her name. She doesn't need more than two pages. Gallery pages is an alright idea. But not for everybody. This is for superstar characters only who have just massive pages. We don't need more bells and whistles on every page. (Am I allowed to hate the game logos in the corner? Because I hate them.)

I also don't really like the tabs at the top. I think they would be easily missed. When landing onto a new wiki page one's eye is drawn either to the infobox, or to the table of contents, or maybe even the intro paragraph, when looking for the piece of info you wanted. Following the link to Xenohart's page I did not notice there was a topnav until re-checking. Maybe if they were on the side like Kaimi suggested and you always saw them.

If only couple articles are the problem ones, then maybe a more localized solution would work.Keltainentoukokuu (talk) 01:19, December 31, 2015 (UTC)


		_{01:32, December 31, 2015 (UTC)} Technobliterator ^Talk



		Or if they were noticeable like this or this (or that RYWB wiki thing). Side could still work, though.


		DrakeyC - Crossing the distant night...Wandering the desert sea...The gods' voices are mirages... TALK - 01:42, December 31, 2015 (UTC)



		"But no, I don't really want this to be a general thing because you'll end up with like three pages for that one bounty hunter chick from FFIX who fought with Amarant that one time. Remember her? Can't remember her name. She doesn't need more than two pages." - Lani, and no she wouldn't, she'd have one page, Boss. Side nav would be okay with me.


		_{01:49, December 31, 2015 (UTC)} Technobliterator ^Talk



		We just need like some point where we define when we make these subpages. I'd say 20+ images for Gallery subpage, 4+ appearances for Other appearances subpage?

I agree that the topnav is hard to notice and very ugly (LoLWiki's is better, but only because it fits the color scheme - our Oasis theme is kind of dull right now, though, so maybe change would be good), but a WikiaRail nav might not be. Something like this, Kaimi? (HTML - the alignment of the text is still off a few pixels so don't implement this without editing! also Lani doesn't actually have a Record Keeper enemy page, but she appears as an enemy in that game and if our FFRK coverage didn't suck long we would have made an enemy page for her long ago.)

Cloud Strife already has a number of "subpages" and related pages, btw. It goes something like

Cloud Strife
- Cloud (boss) - Before Crisis
- Cloud Strife/Tactics
  - Soldier (Tactics)
- Cloud Strife/Dissidia (PSP)
  - Cloud Strife/Dissidia (PSP)/Quotes - Though we may want to collapse this into a general Cloud Strife/Quotes page.

I guess we would want Cloud Strife/Record Keeper, Cloud Strife/Theatrhythm, and potentially Cloud Strife/World of Final Fantasy. I don't think much splitting is necessary beyond that, ~~20 images is not enough for a Gallery subpage~~ EDIT 07:10, December 31, 2015 (UTC): Actually I really like JBed's idea of a gallery page with every image of Cloud on the wiki. it's like one of these databases on Song of Ice and Fire wiki. just as long as we don't do anything retarded like the time we had a frame for every 20 seconds of Advent Children Complete. (that's only 4 rows on Oasis! speaking of which, the images don't seem to completely fill up each row, or is this bug only on my end?). Other Appearances split is probably justified if we're not going to break off Record Keeper, Theatrhythm, World of Final Fantasy, etc.

I can see splitting off Gameplay though. That way, when Wikia finishes their database thingie, we can put the table of Cloud's Broadswords in Cloud Strife/Gameplay along with all the other data that hardcore players (there are hardcore FFVII players other than GarlandG?) may want to see.

Sorry I only use Cloud Strife and Lani as examples, but I think that the points I'm trying to make transfer over to other character pages as well Cat (meow ∙ hunt) 07:03, December 31, 2015 (UTC)

Actually, Techno, namespaces do count towards article count when its id is included in $wgContentNamespaces array, something Wikia can also do. but I agreee with subpaging, as far as I remember, there is a limit to how many extra namespaces wikia allows per wiki. --So ve 07:35, December 31, 2015 (UTC)

Yes, Cat, that is good. As per missing data for enemies: FFRKCentral has stats and abilities listed, it's just a matter of time to visit all pages to get stats for enemies, I'm not sure if they have pages for pre-The Battle Arena events but those stats can be found by scavenging through the net which, once again, takes time. And we would most likely not do infoboxes for FFRK since some enemies appear like lots of times across many dungeons and events with different stats and simple tables are the best approach IMO. Also would be be subpaging subpages too or would there only be subpages from the main article?—Kaimi (999,999 CP/5 TP) ∙ 08:41, December 31, 2015 (UTC)

I've imported a tool called "BackToTopButton" - I'm not sure if this works only on Oasis or Monobook as well, but this could solve the scrolling problem. A button at the bottom right will take you to the top of the page again. To test this, MediaWiki:Common.js should let you enter test mode before it gets enabled on the wiki. I can also instead make it use a small arrow that does this and takes up a bit less space.

There's no reason to use subpages within subpages much, Tifa Lockhart/Dissidia is fine, it doesn't need to be Tifa Lockhart/Other appearances/Dissidia. I still think we need to define when we make gallery subpages and when we make other appearances subpages, though.-- Technobliterator ^T_C 12:06, December 31, 2015 (UTC)

To expand on how I think character pages should be structured:

Cloud Strife (the article will have a basic profile, and Appearances list explaining role in game. Appearances list h3d by sub-series [titles with connected stories/worlds], in order of release/appearance*(compVII>FFT>CRacing>FFV>Dissidia etc.)). Each release needn't be covered in more than two paragraphs).
- For every sub-series where Cloud has a story, a page exists for Cloud's story/profile info in that series. So "Cloud Strife/Final Fantasy VII", "Cloud Strife/Dissidia (PSP)", "Cloud Strife/Tactics".
  - For every game the character is playable in, a page to cover their relevant player information (weapons, abilities, etc.). "Cloud (Final Fantasy VII player character (you can see the problem with "Final Fantasy VII PC". can't think of a better name))", "Cloud (Dissidia (Whether we split up 012 or not is up for debate. we have a tables for both in most cases anyway) player character)", etc.
  - For every game the character is fought in, a page. "Cloud (boss)"[Before Crisis].

Boss and PC articles can be linked to in the section for each game. Them subpages can be linked beneath the relevant sub-series/game. I guess info of them as summons/abilities and of their cards won't get their own page, and will instead be covered in the sections on "Cloud Strife".

And many of the images in the gallery will go to where they are most relevant. This should cut down the information on Cloud Strife fairly significantly. Or so I say: Gilgamesh (character) is still quite long (though can still stand to be cut down/split in some places). But there's not that much you can do when we need to say a little about a lot of releases.

RE: Cloud Strife gallery. I thought about a category to put every image of Cloud in. I don't know what the best idea would be. The obvious problem with a category is that you don't get any captions or organisation, however having our files categorised by character would be neat.

I don't disagree with a Gallery namespace in theory, it's just that most of the time we'll end up with "Gallery:<name of article in mainspace>", so we'll be doing extra work to move both things. This might not always be the case though-- we're more likely to have "Gallery:Final Fantasy VII enemy abilities" than "Gallery:List of Final Fantasy VII enemy abilities", because it's a gallery and not a list. Also the artwork and wallpaper pages would find themselves in such a namespace, and wouldn't be associated with an article of the same name. JBed (talk) 22:41, December 31, 2015 (UTC)


		Kaimi - "Ah! The prison repository of wrested relics and raiments." TALK - 13:46, January 8, 2016 (UTC)



		Bump, because we should really agree on something so it's not another fruitless discussion. Also JBed, I don't quite get why story/profile information should go on a subpage, while their playable apparance as a new page with a tag. It's overcomplicating things IMO. Or is my interpretation incorrect? Is there an article you think is of an exceptional quality? Vote for it here!


		_{13:49, January 8, 2016 (UTC)} Technobliterator ^Talk



		Kaimi, I am getting to work on this and I will have a group of image examples that we can vote on before I go ahead and make it final. I just have other stuff to do (like right now I have to convert every single infobox and then I have exam week). Please do not try to rush me, it will be done.

Okay, I was just worried we had started another topic which would once again not bear any fruit. Thanks for the reply. ;) —Kaimi (999,999 CP/5 TP) ∙ 14:45, January 8, 2016 (UTC)

"I don't quite get why story/profile information should go on a subpage, while their playable apparance as a new page with a tag"

It follows our logic for when to use tags and when to use subpages. Sole gameplay pages go by what they're called. These player character pages are like job or boss pages. With FFVII, Character0 is known by default as "Cloud" (also known for a short while as "Ex-SOLDIER"), so that's the name the article should have.

Meanwhile the story/profile pages follow the story/profile logic that our Dissidia pages currently do. We're talking about the same Cloud/Cloud Strife, it's just a branched off page to focus specifically on his role in one sub-series. JBed (talk) 19:54, January 8, 2016 (UTC)

Design proposals and vote

This vote is now closed. Result: table of contents had the most votes, no strong consensus.

We'll discuss the design before we go through the whole thing about how we're going to split stuff up.

Note these four things first: there's now a button immediately scrolls back up the page in the bottom right, that regardless of which option there will be {{main}} links in sections to subpages most likely, ~~many solutions may not work on mobile skin~~*(nevermind, I can get a solution to work by just display:none-ing it on Wikia and Monobook css) other than the simple tabs and {{main}} links (though I'll have a word with Wikia's engineering team) and monobook receives less than a tenth of a percent traffic if not less, so I'm not designing any of these solutions around monobook as a priority (which is not to say I won't get them to work on the skin at all - and if the scroll back up button doesn't work on monobook, I might find a way to get it to work).

So, I have these possible designs:

Right rail: We use the "Article Information" on the right rail, going above sideicons. The unfortunate problem is this means that they will rely on JS, which doesn't load immediately, and will appear half a second or so after the page load, and also won't work on mobile. Other than these things, this is likely the least controversial option. Example: Catuse made one already, can't be bothered to do my own.
Top tabs: We use tabs at the top, similar to Wookieepedia, LoL wiki and some anime wikis. This adds a bit of space, but is the second easiest solution behind just having no design. It also means we can easily have dropdowns underneath these tabs, comes without any JS problems and, depending on design, could be non-intrusive. Example: work in progress here, made with HTML by inspecting elements. I'm proud of this, took me ages, could easily change design.
Table of contents: We add a few bullet points either in the table of contents listing some subpages, or just to the right of it, and then restrict the width of the table of contents with CSS. Although one may think "hey, this'll make the ToC longer!", it actually will be vastly reduced by given how many sections will no longer be there taking up space. This won't appear too obnoxious, but will come with the right rail issues. I'm going to consider talking to the engineering team about how to get it to work easiest on mobile. Example: Number 1, and number 2. First was made with inspector, second I had to edit with GIMP, because I got no clue how to code that one. Both, however, I forced ToC width to be 250px.
Space just below article name: There's a small space from the name down to the edit button. This can easily be occupied with links. However, this also comes with problems that the right rail solution brings: it'll require JS, and won't work on mobile. Example: here, I just needed to remove padding below title and then used inspector for the rest. Could be straight-forward.
No design, plain main links: This involves simply using {{main}} in sections with no links. I think this would be a real shame, but it would be the easiest solution. No load times, but also makes navigation arguably more difficult.

These are my designs. Feel free to add any of your own in this section if you want, preferably with an image as well.-- Technobliterator ^T_C 15:16, January 27, 2016 (UTC)

Right rail votes

I like ToC version 2 as well, but I feel that the placement of the subpages in its own specific area, removed from the main body of the article, is better. 8 bit 20:47, January 28, 2016 (UTC)

Top tabs votes

At the top of page, easily accessible and findable for all viewers. We can keep subpages links if we don't want people to scroll to the top, but with the "back to top" button now that seems unnecessary. DrakeyC (talk) 15:19, January 27, 2016 (UTC)
Looks good, others not so much. Although I'm not the fan of that blue. Maybe classcodes would be good?—Kaimi (999,999 CP/5 TP) ∙ 16:22, January 27, 2016 (UTC)
The design can be customized, but this seems to be the most easily recognizable/accessible option, and it would probably be the easiest to optimize with Monobook. --Shiruba Kurono 03:31, February 7, 2016 (UTC)
It looks better and easier to use for casual visitors. Monterossa (talk) 04:22, February 7, 2016 (UTC)
--Miphares (talk) 06:11, February 7, 2016 (UTC)

Space below votes

Table of contents votes

This was initially my idea (I will take no credit for implementation), so I will support this. I think it's the nicest, non intrusive, and we don't have to have ugly tabs. ScatheMote 20:31, January 27, 2016 (UTC)
Not sold on the tabs idea, but this seems doable. The TOC change could be done even with other design decisions though? It seems to fit with all of them.Keltainentoukokuu (talk) 21:14, January 27, 2016 (UTC)
Though I made design #1, the technical restrictions suggest that this (or a fusion of the two?) is the best. As Scathe said, we want a low-intrusion design. Cat (meow ∙ hunt) 08:03, January 29, 2016 (UTC)
— Yuan^Salut 10:57, January 29, 2016 (UTC)
Now I know easy ways to get it to work on mobile, I think this is least obtrusive will still visible.-- Technobliterator ^T_C 11:36, January 29, 2016 (UTC)
Techno wants hard work so I say give it to him. :V Seriously, I hadn't considered this a possibility before, but now that we think it will work, it's a good design, and placed right where people should be looking when they want a specific section. Might want to have a plan for a top tabs implementation in case this plan implodes somehow. -- Some Color Mage ~ (Talk) 00:00, February 22, 2016 (UTC)

No design, plain main links

Continuation

Please see Forum:Organization Overhaul 2.