FANDOM

FishTank

aka Isaac

Staff
  • I live in San Antonio, Texas, US
  • I was born on November 18
  • My occupation is Editor Experience Specialist at Fandom
  • I am male
  • Bio I don't always help Fandom users; but when I do, it's as an anthropomorphic fish in an armored military vehicle.
  • [Show More]
Revision as of 16:38, October 18, 2017 by FishTank (Talk | contribs)

| User:FishTank

PI discussion

Hi FishTank. I believe we still have a discussion to finish. On my part, at least, I'd like to finish it. I'd like to finish it here, because it's about the PIs (which started to be implemented on this wiki recently) and because I tend to use examples related to this wiki, since it's the wiki I contribute to.
So, if you don't mind, I'd like to finish it here and I'd just copy the messages I left you on the public chat on Discord to here, so we can go from there. Becasita Pendulum (talkcontribs) 16:41, July 6, 2017 (UTC)

Sure, go for it. FishTank @fandom (wall) 16:43, July 6, 2017 (UTC)

@FishTank

We haven't blocked anyone for disagreeing with us.

Fair. But is it, or is it not, true that people may be demoted from their admin status? Besides, TTF said "I have asked Fandom staff to patrol this wiki, and deal with anyone that reverts these changes, including but not limited to, reverting back to the new syntax, removal of rights for those that make repeated reverts, and temporary bans for those that persist in doing so.". Which means that if we (the community) do not agree with the changes being implemented at the community by non-community members, then we can be punished. I understand this for some cases, but not here. That raises the question: If an user goes at the YGO wiki and clicks on the "convert" button for an infobox (because everyone can do that) and I revert. How would you consider my action?

Portability is working on all platforms, not just mobile. Mercury doesn't care about the CSS classes. The CSS classes are not what makes something portable.

Ah, alright. I didn't think portability was the CSS, by the way. I just mentioned it because FANDOM was selling PIs as "fixes the bad mobile experience" and the YGO community often complained about the YGO wiki on mobile. By using the PI classes I was able to make it look like the PIs do, so that works for the readers. And might work better than having videos appearing there or ads or whatever other stuff readers don't want to see.

On YGO, we've done a staged rollout. We started with three PIs, to see how well they worked for you. We can continue to do more, of course, but these were the three templates with the highest visibility.

They didn't work good, we don't want more. We both know that this doesn't matter, so what do you mean with " to see how well they worked for you"? Does this matter? What was the idea? Starting some and leave the others? Because I won't make use of time there to create PIs.

When you say "look bad", you'll need to be more specific. The clearest place to do that is on YGO itself, rather than in this venue, for a variety of reasons. But poorly formatted for your tastes is opinion. They are objectively easier to read.

Yes, personal (but not limited too) opinion. Big text on the headers, hidden stuff by the dropdowns. Sections poorly addressed. Some of these have been fixed, some have not, I think all can be fixed by making use of the Styles.css (which is only editable by admins, by the way, which can be a disadvantage, since anyone could, before create templates and style them via style.

FANDOM is not a "free host".

It's free in the sense I don't have to waste resources to have my content stored. It is, however, an exchange of services. I freely write about stuff to inform the fandom/whatever about some subject, without having to worry with server costs/problems. FANDOM gives me server space and assistance. In the end, it's still a symbiosis. One doesn't work without the other. If I don't write, people won't have anything to see; FANDOM loses. If FANDOM doesn't host me, I have no where to write; I lose. This is in extremis, of course. The point is; if I'm not satisfied, I can choose to go away.

@charitwo

Some communities prefer 100% control

I don't ask for that much; I just ask to be able to be listened to and to have the opportunity for my ideas to be thought about. I think we all want that. And that, ultimately, is better than 100% control, perhaps, since you may achieve more with that.

FishTank

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.

That is true. The thing is it doesn't seem you, FANDOM, doesn't try to please more than yourselves.

cahritwo

People are by nature creatures of habit and comfortable with the status quo and do not adapt well to change.

People do adapt to change and that's how the world evolves. But not like this, with stuff being shoved like that, when there are possibly better ideas that aren't being taken into account. I think that's the problem here, more than keeping the status quo.

The casual anonymous viewer will likely not care about a new skin or new infobox as long as the content is there and available. The dedicated contributors (which are often referred to by Wikia as a "vocal minority"), the ones that build the community, do care.

FishTank, this. This is important. Even for the user who just corrects typos here and there, this may not matter. But for people who put their effort to shape the wiki and make it a better place in terms of experiencing/accessibility/usability/whatever other stuff, this matters; because you might be destroying not only their work, but opportunities for them. I don't think that's the best approach, because, in the end, if it weren't those people, the wiki would probably look not as good (kinda being bold here, it's more in grosso modo, that I'm talking about).

Ok, the formatting is not the best, but I think it's clear enough. Orange is what you said; light red is what charitwo said; the rest is what I said. Becasita Pendulum (talkcontribs) 19:49, July 6, 2017 (UTC)

But is it, or is it not, true that people may be demoted from their admin status? [...] Which means that if we (the community) do not agree with the changes being implemented at the community by non-community members, then we can be punished. I understand this for some cases, but not here. [...] That raises the question: If an user goes at the YGO wiki and clicks on the "convert" button for an infobox (because everyone can do that) and I revert. How would you consider my action?
You'll have to take up local policy on demotion with TTF, with regards to what he said. He was concerned about some local policies issues and asked me (in specific) to keep an eye out while he was unavailable. While it could and should have been worded better more carefully to avoid confusion, I considered this a short term request.
In general, we (FANDOM) are not in the habit of demoting admins because they don't agree with us. A bureaucrat on a different high-profile community was recently de-admined for sabotaging his community's long-term well-being in a way we considered vandalism. We did not remove him due to disagreeing with us, as has been characterized.
If a general user approves an unprotected template change, I would assume that it is your policy to allow such, as the template is unprotected. If you reverted it, I don't know what your general local policy entails. But if your bureaucrat says specifically that it's not allowed, and he's publicly left explicit and specific instructions as to how that action should be responded to including a request for us to take action, that constitutes an explicit authorization for us to carry out those wishes regardless of consensus. It doesn't get more clear-cut, transparent, or explicit than that case; it's also not FANDOM's general practice.
By using the PI classes I was able to make it look like the PIs do, so that works for the readers. And might work better than having videos appearing there or ads or whatever other stuff readers don't want to see.
As I explained before, using the PI classes has no effect on mobile. This is an understandable confusion, because there's a difference between mark-up (i.e. items that change the visual appearance) and an extension (i.e. a piece of software that lives on the server and creates or modifies the structure of data before output). To use a metaphor: PIs don't just put a fancy frame around a painting, they change the painting from an oil to an acrylic or a watercolor depending on what's being asked.
PIs also do not add videos or ads. They do, however, reposition some videos and ads to be in a predictable place rather than displacing content at the top of a page.
They didn't work good, we don't want more. We both know that this doesn't matter, so what do you mean with " to see how well they worked for you"? Does this matter? What was the idea? Starting some and leave the others? Because I won't make use of time there to create PIs.
I believe we have different interpretations of "they didn't work good". They seem to have worked with very few errors that were quickly resolved. We both know that this doesn't matter sounds more than a little disingenuous. When you say "we don't want more", you are not speaking for the entirety of either your admin team or your community, as I believe you are aware. My personal time has been limited to work on Yu-Gi-Oh, as it is budgeted to cover many responsibilities; I've been asked to come back and continue work when I am available. In the meantime, there is no rush unless you want there to be. I have no expectation that you will make use of your time to do something you do not want to do, and you've made your feelings very clear. If you are under sole obligation to make your community's templates, it is a responsibility I am unaware of. But rest assured that it will be completed by someone. Your cooperation only makes it the best possible experience for your community, as you will be able to identify nuances I can not. If you maintain the templates in the future, here or on any of FANDOM's communities, you'll also benefit from learning what we consider to be the standard for infoboxes.
Some of these have been fixed, some have not, I think all can be fixed by making use of the Styles.css (which is only editable by admins, by the way, which can be a disadvantage, since anyone could, before create templates and style them via style.
I don't know what Styles.css is, but it sounds like something that shouldn't be in the hands of general users on a well-organized community where it is likely to be vandalized. Centralizing CSS versus inline is simply a good practice.
It's free in the sense I don't have to waste resources to have my content stored. [...] The point is; if I'm not satisfied, I can choose to go away.
I believe there is a difference missing in this statement that it is not your personal content. You are contributing to and are a steward of a community effort. It is not any specific user's (or small group of user's) property. While you (as a contributor) can stay or leave as you please, your legacy is combined with that of others here. We're all working together to make it the best content. My job is helping you showcase that to the widest possible audience.
I just ask to be able to be listened to and to have the opportunity for my ideas to be thought about. I think we all want that.
We do. And we (FANDOM) listened. I was in your admin Discord for a week, for example, and I addressed the concerns you had before this enterprise started. You did not raise any ideas that were dismissed out of hand, and all of them were thought about.
The thing is it doesn't seem you, FANDOM, doesn't try to please more than yourselves.
There's no cordial response possible to this aspersion, other than to either ignore it or say that there are obvious examples where it is provably untrue. I don't intend to list them.
People do adapt to change and that's how the world evolves. But not like this, with stuff being shoved like that, when there are possibly better ideas that aren't being taken into account.
I'd ask you to reflect on this statement with the perspective that you are assuming yours is the better idea. We've taken a lot of ideas into account (as we actually do this professionally; we've got a lot of experts that think about this and have been doing it for years), and quite a lot of people do not agree that the ideas you raised were the better ideas. You've challenged. We've responded, with explanation.
But for people who put their effort to shape the wiki and make it a better place in terms of experiencing/accessibility/usability/whatever other stuff, this matters; because you might be destroying not only their work, but opportunities for them. I don't think that's the best approach, because, in the end, if it weren't those people, the wiki would probably look not as good.
We're giving users a new and powerful tool to do that, as continuing on the path Yu-Gi-Oh was on didn't look good either to a lot of people looking. We've also provided lots of opportunities for users to learn how to adapt and evolve with that new tool. All birth and growth has a little destruction involved. Personal choices are up to you.

FishTank @fandom (wall) 05:31, July 7, 2017 (UTC)

If you reverted it, I don't know what your general local policy entails. But if your bureaucrat says specifically that it's not allowed, and he's publicly left explicit and specific instructions as to how that action should be responded to including a request for us to take action, that constitutes an explicit authorization for us to carry out those wishes regardless of consensus. It doesn't get more clear-cut, transparent, or explicit than that case; it's also not FANDOM's general practice.

Fair enough, understandable. So, how many users would I need to gather to demote a bureaucrat from their bureaucrat status? Note (this is more of a disclaimer) that I'm asking this out of curiosity; totally hypothetically.

As I explained before, using the PI classes has no effect on mobile. This is an understandable confusion, because there's a difference between mark-up (i.e. items that change the visual appearance) and an extension (i.e. a piece of software that lives on the server and creates or modifies the structure of data before output). To use a metaphor: PIs don't just put a fancy frame around a painting, they change the painting from an oil to an acrylic or a watercolor depending on what's being asked. PIs also do not add videos or ads. They do, however, reposition some videos and ads to be in a predictable place rather than displacing content at the top of a page.

I understand this perfectly and am already aware of it. For the readers, the visual change works, though. I understand it could have consequences in the future, yes. But who knows? I'm working within the limitations. In any case, I wouldn't intend to follow that path (of using PI classes); was just an example. I also know they don't add ads, etc., but you have more control over where to place them, when before you'd just put them on top (I guess?). I wanted to make it better for the readers. I know I could do it, with some CSS, etc. (we talked about this, I know, just mentioning for my example). Of course, I couldn't then add videos or whatever. But do those readers want to see that?

I believe we have different interpretations of "they didn't work good". They seem to have worked with very few errors that were quickly resolved. We both know that this doesn't matter sounds more than a little disingenuous. When you say "we don't want more", you are not speaking for the entirety of either your admin team or your community, as I believe you are aware.

True, true. I confess I exaggerated a bit and I recognize my mistake. However, I do know users (admins and non-admins) who didn't like and wouldn't like more PIs. Of course, I won't tell names, so I have no way to prove my statement. Therefore, you can deem it as irrelevant and with no value.

there is no rush unless you want there to be.

I mean, it's not pretty to leave stuff unfinished and all. We have some infoboxes with one style others with another, now PIs... The sooner, the better.

I have no expectation that you will make use of your time to do something you do not want to do, and you've made your feelings very clear. If you are under sole obligation to make your community's templates, it is a responsibility I am unaware of. But rest assured that it will be completed by someone. Your cooperation only makes it the best possible experience for your community, as you will be able to identify nuances I can not. If you maintain the templates in the future, here or on any of FANDOM's communities, you'll also benefit from learning what we consider to be the standard for infoboxes.

I have other projects I'd like to complete first, yes. It's not a responsibility I have. I like to help there, but this whole situation isn't being very friendly, just that. I'm not feeling very good with this. For instance, I'm not saying you should do this. Since you started it, it would be good if you could engage on it, of course. But you are a FANDOM staff; I'm not expecting staff to maintain wikis constantly. But I'd expect TTF to do so, since he started this. I don't like the attitude of dropping the PIs and now people take care of them while I'm busy looking the other way. That's how it feels, at least. How it feels to me, that is. And I don't like that.

I don't know what Styles.css is, but it sounds like something that shouldn't be in the hands of general users on a well-organized community where it is likely to be vandalized. Centralizing CSS versus inline is simply a good practice.

Heh, I meant MediaWiki:Themes.css; my bad. Yes, I agree with CSS over style, of course, no doubts there. Then make the page editable by anyone. Because styles could be changed in real time. Now you need to wait for an admin (unless the template was protected before). More limitations for the users in general, is what it means.

We do. And we (FANDOM) listened. I was in your admin Discord for a week, for example, and I addressed the concerns you had before this enterprise started. You did not raise any ideas that were dismissed out of hand, and all of them were thought about.

Yes, and I thank you for that. In the meantime, I had other things to ask and you said you'd be willing to talk. Hence why we're here.

There's no cordial response possible to this aspersion, other than to either ignore it or say that there are obvious examples where it is provably untrue. I don't intend to list them.

It's understandable, though. I didn't mean to offend (especially not personally, goodness, no). You are a company. You want the best for you. It's understandable.

I'd ask you to reflect on this statement with the perspective that you are assuming yours is the better idea. We've taken a lot of ideas into account (as we actually do this professionally; we've got a lot of experts that think about this and have been doing it for years), and quite a lot of people do not agree that the ideas you raised were the better ideas. You've challenged. We've responded, with explanation.

You know? You are right. I bet FANDOM thought about allowing CSS on mobile, for instance. It just doesn't seem they viewed it from our perspective (like we can't see from your perspective, right? Or can we?). Becasita Pendulum (talkcontribs) 15:10, July 7, 2017 (UTC)

So, how many users would I need to gather to demote a bureaucrat from their bureaucrat status?
You don't. Bureaucrats rarely get demoted. Especially if they're active.
I wanted to make it better for the readers. [...] Of course, I couldn't then add videos or whatever. But do those readers want to see that?
In general on FANDOM and beyond, yes. As part of the Modernization effort, we've found that some readers and communities really respond to well done videos. The biggest web sites in the world (from CNN to Facebook, and YouTube of course) have come to the same conclusion. It's why Snapchat and Instagram are popular. I have no data on whether that's true for Yu-Gi-Oh specifically and it's not my department. But in general, yes, readers want to see video in parallel to text.
However, I do know users (admins and non-admins) who didn't like and wouldn't like more PIs.
It's not possible to please everyone. I'd welcome their voices, if they have specific concerns, and we might be able to do something about them. PIs are the FANDOM standard, so we can't really operate on "Somebody doesn't like them and we don't know why".
The sooner, the better.
I'll get on it very soon. I was hoping for a tool from my side that will make some things easier, but it hasn't materialized this week.
I don't like the attitude of dropping the PIs and now people take care of them while I'm busy looking the other way.
I don't know what will ease this feeling of yours except time and listening. This initiative has been going on for months and there's been plenty of time, and as this dialogue shows, plenty of listening.
Yes, I agree with CSS over style, of course, no doubts there. Then make the page editable by anyone. Because styles could be changed in real time. Now you need to wait for an admin (unless the template was protected before). More limitations for the users in general, is what it means.

It's not really possible to have it both ways. Either it's secure, protected, and consistent, or anyone can edit it. Centralizing it not only makes for a more cohesive site, but one where less vandalism and well-meaning mistakes are possible.

I bet FANDOM thought about allowing CSS on mobile, for instance. It just doesn't seem they viewed it from our perspective (like we can't see from your perspective, right? Or can we?).
We have thought about it a lot. We get asked about it a lot. We've talked a lot about the best ways to do it. But in the end, it's just not a good idea for us to allow it. Well-intentioned users break it, and we have a responsibility and desire to make sure it doesn't get broken. That's why we got rid of the old mobile skin.
In terms of perspective, it might be helpful to remind you that many FANDOM staff (particularly in the Community department) are also wiki editors. For example, I was an admin for American Horror Story Wiki for years before joining the staff (and still am the only admin there). So it's not difficult for us to see it from your perspective. We share our perspective and how we arrived at it the best we can.

FishTank @fandom (wall) 17:29, July 7, 2017 (UTC)

Well, in case you're expecting for an answer: There's nothing I want to say for now. I might be leaving more messages here, in the future. Becasita Pendulum (talkcontribs) 18:18, July 9, 2017 (UTC)

Card article design

I see that you're working on a redesign for card articles.

Just a bit of history in the area, a lot of which you're probably already aware.

CardTable2 is trying to cram in too much information, in a less-than-optimal way and gives a terrible mobile-user experience.

It was trying to cover details from the card in all card games, board games, video games, the manga and anime. We've been moving all these details to separate pages, using newer templates, which look cleaner, less busy, okay on mobile and give us freedom to go into more detail on the medium in question.

e.g. we took all manga details from "Swordstalker", put them at "Swordstalker (manga)" and expanded that to cover more manga details that couldn't fit on the original page. Once that had been done for all manga cards, we were able to strip all manga-specific parameters from CardTable2, making it less bloated.

The same process has been done for various other games and mediums. The intention was to get this done for everything, until CardTable2 is stripped down to just data on the regular Yu-Gi-Oh! Trading Card Game. Then it could be updated to a cleaner template, like the others. Creating pages for each of the other games/mediums beforehand would also served as trials to help us come up with better ways to present the styling of the card pages.

The process has probably been too slow for Wikia's liking, with CardTable2 still in high use and being unpresentable in mobile. Plus Wikia would like to roll out portable infoboxes, where possible. This is why you've been tasked with the redesign you're working on, is it?

I have some feedback/questions on the redesign you've been doing:

  • What is to become of templates like {{Manga card}}, {{DM1 card}}. Do you intend to completely scrap them? How much of them is being incorporated into the redesign?
  • I understand the structural changes; portable infoboxes for consistency across Wikia, semantic HTML and uses Wikia's core features so has full support, including mobile styling and JS. Lua for performance and cleaner code. But why the aesthetic changes? If any of this sounds critical, it's unintentional.
    • A card table and an infobox are each essentially the same structure; a heading, followed by an image, followed by a list of key-value pairs. They can be achieved with pretty much the same HTML, meaning same semantics and SEO and can have the exact same appearance in mobile.
    • With the length of the infoboxes in the samples you've prepared so far, I don't think we'll have enough content on the left-hand side to balance them out.
    • Admittedly, I'm not too fond of list of collapsibles on the left, infobox on the right.
    • I think "lore"/"card descriptions" are too long to be included in the infobox. The example you've used in your sample has a very short description relative to most cards. Here's an example of a much longer one; "Supreme King Z-ARC".
    • I think the English "card description" is far too important to be hidden by default. The name, image, basic stats (Type, Attribute, Level, ATK, DEF, etc.), English description are probably the items of highest interest to readers.
    • My best in-use presentation of non-English names and descriptions is as seen at "Dark Magician Girl (DBT)". It doesn't fit too well on mobile and gets worse when an extra column is added for the Pendulum Effect. I think Becasita's suggestion might be what works best here; collapsible headings for "French", "German", etc. When expanded, each section has key value pairs for "Name", "Lore", "Pendulum Effect", etc.
  • You're still supporting video game information. The intention has been to move all of these to separate pages, so there should eventually be no need to cover it on the main (OCG/TCG) articles. Although, maybe necessary for the time being...
  • Set information. I have been considering changing how this is stored. Basically, store semantic data for the contents of a set on the set list page. Do not manually add set data to card articles. They will instead run an SMW query to see what sets it appears in and what its number and rarity in each set is. So for Set Card Lists:Breakers of Shadow (TCG-EN), you just need to ensure the one page is listing the correct cards, numbers and rarities, rather than ensure one hundred pages are listing the correct set, number and rarity. This is pretty much identical to how Deck and drop rates have been set up at Yugi Muto (Duel Monsters 1) and queried at Skull Servant (DM1).
    • Do you know what the future of SMW on Wikia is?

-- Deltaneos (talk) 23:53, August 2, 2017 (UTC)

Regarding CardTable2's replacement, my sandbox representation of Dark Magician may clear up how I've done this so far. The migration is mostly complete.

It was trying to cover details from the card in all card games, board games, video games, the manga and anime. We've been moving all these details to separate pages, using newer templates, which look cleaner, less busy, okay on mobile and give us freedom to go into more detail on the medium in question.
That's ultimately both a good and a bad idea. Moving them to separate pages doesn't really allow you to focus on the details that would help you SEO-wise. In fact, it may ultimately cause more clutter in terms of people not knowing what article to go to. The better play for search engine visibility would actually be to keep a single consistent article and use textual content (not inside templates, not inside tables) to put things into context (i.e. breaking it into headings and adding descriptive text).

e.g. we took all manga details from "Swordstalker", put them at "Swordstalker (manga)" and expanded that to cover more manga details that couldn't fit on the original page. Once that had been done for all manga cards, we were able to strip all manga-specific parameters from CardTable2, making it less bloated.
That's an interesting idea, and I know that you're deep into the process, but ultimately I believe that will negatively impact your article organization as described. For example, comparing the two versions of Swordstalker makes one go to two different pages, and a Google or FANDOM search will make much more sense only searching for the one term. Splitting those off does indeed remove visual clutter from CardTable2. But there are also other ways to remove that clutter by grouping information carefully.

The process has probably been too slow for Wikia's liking, with CardTable2 still in high use and being unpresentable in mobile. Plus Wikia would like to roll out portable infoboxes, where possible. This is why you've been tasked with the redesign you're working on, is it?
In a nutshell, yes. Yu-Gi-Oh has been at the top of the list for needing this migration for a while now. We decided to shift efforts a little bit and pursue the larger targets more assertively where possible.

What is to become of templates like {{Manga card}}, {{DM1 card}}. Do you intend to completely scrap them? How much of them is being incorporated into the redesign?
Excellent question! After a lot of trying to figure out the best way to do this, the simplest way without changing articles en masse with a bot seems to be something I normally don't like doing: using a metatemplate. On the bright side, that metatemplate is a Portable Infobox based on CardTable2. I've been taking the elements that were split out of CT2 into (for example) {{Anime card}} and {{Manga card}} and weaving that functionality back into Card. Now, you're right that the initial stripping process was to reduce the bloat of CT2, reproducing those functions in Lua significantly reduces that bloat both in terms of code visibility in the template and improves performance significantly over nesting functions and using Variables. The result is much more modular. {{Anime card/Draft}} has an example of this. You can see an example version of Dragon Nails at User:FishTank/sandbox2. It should be feature complete as it approaches final integrations. You can also see here why textual content is key to add, as the page looks fairly bare when the visuals are distilled. As for the look of the full-width templates, that's not really possible to replicate as that's the primary reason why the page is not mobile-friendly to begin with. However, the additional step of using these satellite templates is that better CSS themes become possible. With the basic PI in Card, it's not possible (by design) to dictate the logic of how it should be themed or colored based on more than a single variable / parameter.
But why the aesthetic changes?
Because the aesthetic issues are a prime reason of what is making the articles not mobile-capable. Any single element over a certain width has to be scrolled with a finger horizontally and it does not present a good usage pattern. Full width elements just won't work properly. Being a fixed width table, they're not responsive. From a readability point of view and an accessibility point of view, having a large monolithic element is very confusing for readers and browsers alike.

I don't think we'll have enough content on the left-hand side to balance them out.
You will if you put some of the things you've split off, like Rulings and Trivia and Tips, back onto the card page.
Admittedly, I'm not too fond of list of collapsibles on the left, infobox on the right.
If the sets are placed below actual textual content, much as they are with the VG table, that won't be as obvious a visual issue. The alternative was a super long infobox with nothing on the left.
I think "lore"/"card descriptions" are too long to be included in the infobox.
Whereas they look far too short and quite unattractive as a standalone table, typically of one line each. TwoTailedFox expressed the same concern, and I tested it with Thousand-Eyes Restrict. I can split those off much as sets are now, but I strongly believe that you won't like them once they're like that. Collapsed inside the infobox became the best option.
I think the English "card description" is far too important to be hidden by default.
I agree. In fact, it should be in the first textual content on the page, like the article intro / lead in traditional articles. Otherwise, search engines won't pick it up. Tell me how you'd like that framed, and I'll find a way to make it happen.
The name, image, basic stats (Type, Attribute, Level, ATK, DEF, etc.), English description are probably the items of highest interest to readers.
I agree. And I'll make sure that group starts off expanded.
...collapsible headings for "French", "German", etc...
This is an idea that seems good on its face, but I think we'll find is actually rather anti-productive in practice. I'll make a draft variation with it and show you what I'm getting at, but it won't be in this pass.

You're still supporting video game information. The intention has been to move all of these to separate pages, so there should eventually be no need to cover it on the main (OCG/TCG) articles. Although, maybe necessary for the time being...
I'm making a translation of CT2 first, which has these, but I'll repeat the suggestion that I don't think it's a good idea to split them off into separate pages.
Set information. I have been considering changing how this is stored. Basically, store semantic data for the contents of a set on the set list page. Do not manually add set data to card articles. They will instead run an SMW query to see what sets it appears in and what its number and rarity in each set is. So for Set Card Lists:Breakers of Shadow (TCG-EN), you just need to ensure the one page is listing the correct cards, numbers and rarities, rather than ensure one hundred pages are listing the correct set, number and rarity. This is pretty much identical to how Deck and drop rates have been set up at Yugi Muto (Duel Monsters 1) and queried at Skull Servant (DM1).
I'm fine with that, but I'm translating the template as-is. If you want to switch where that data is stored, let me know.

Do you know what the future of SMW on Wikia is?

FANDOM isn't discontinuing SMW, if that's what you're asking. In fact, you're the first community to get the SMW/Lua integration extension we approved this week. — FishTank @fandom (wall) 01:05, August 3, 2017 (UTC)

Just want to express that I don't like the aesthetic much as well; doesn't look very elegant. I don't have many suggestions, besides like I was doing on my draft, which follows {{Anime card}}, etc., but without the metatemplate concept.
And it's great to hear that about SMW! It's super useful and being able to combine it with Lua makes it amazing. Becasita Pendulum (talkcontribs) 12:24, August 3, 2017 (UTC)

Card article design (2)

Thanks for hearing me out.

Moving them to separate pages doesn't really allow you to focus on the details that would help you SEO-wise. [...] The better play for search engine visibility would actually be to keep a single consistent article and use textual content (not inside templates, not inside tables) to put things into context (i.e. breaking it into headings and adding descriptive text)."

I can understand important details are to go in headings and paragraphs, rather than tables because they are what are taken into account when generating the search engine meta description. I don't understand how unifying the pages helps this. Surely each page is going to have their own textual content, generating their individual descriptions? Google can smartly identify pages like this and cluster them together. See this mockup, which is probably what we're ultimately aiming for? (Despite popular belief, you don't exactly get punished by Google for having duplicate content.)

not inside templates, not inside tables

Is "templates" what you intended to say? Don't search engines primarily just look at the rendered HTML, while how it got generated is of little interest, as long as it was present on the initial load?

In fact, it may ultimately cause more clutter in terms of people not knowing what article to go to.

I'm not sure about that. Search engines are intelligent and will figure the best result based on what the user typed. If the search criteria is not very specific, the search engine will probably get the most popular one, which is likely what they're looking for.

In terms of actually using the site, you should find what you are looking for through context. If you're reading about a video game, you get linked to the card as it appeared in the video game.

Example: http://www.smogon.com/ This site has separate pages for each Pokémon for each generation of games. Types, base stats, moves learned and playability vary between games. If you're playing the RB (Red and Blue) generation, you can bring up the list of Pokémon as they appear in that game, http://www.smogon.com/dex/rb/pokemon/ and quickly check the details for each one, seeing only the relevant details. Had that site included all generation details for Starmie on the one page, it would involve a lot of seeking and scrolling past details you're not interested in. If you're checking multiple Pokémon from the same generation, you'd have to repeat the seeking after each change of page. If you are interested in cross-generation details, you can easily click through the links at the top.

As for the look of the full-width templates, that's not really possible to replicate as that's the primary reason why the page is not mobile-friendly to begin with.

That page is mobile-friendly.

something I normally don't like doing: using a metatemplate

Why don't you like metatemplates? It seems like textbook "don't repeat yourself".

But why the aesthetic changes?
Because the aesthetic issues are a prime reason of what is making the articles not mobile-capable. Any single element over a certain width has to be scrolled [...]

I might not have been clear. What I was saying is you can make a card table (header on top, image on the left, stats on the right) and an infobox (header on top, image below, stats below) with pretty much the exact same HTML. They would have the same underlying code, the same effect on SEO, the same mobile styling (header on top, image below, stats below), but different desktop styling. My question is "Why is it favorable for the desktop visuals to be an infobox?".

I don't think we'll have enough content on the left-hand side to balance them out.
You will if you put some of the things you've split off, like Rulings and Trivia and Tips, back onto the card page.

That's actually something I am interested in...

I think the English "card description" is far too important to be hidden by default.
I agree. In fact, it should be in the first textual content on the page, like the article intro / lead in traditional articles. Otherwise, search engines won't pick it up. Tell me how you'd like that framed, and I'll find a way to make it happen.

Just after the first paragraph, appropriately labelled seems most logical. Although, that means you need to scroll past the entire infobox to see it on mobile.

'collapsible headings for "French", "German", etc. When expanded, each section has key value pairs for "Name", "Lore", "Pendulum Effect", etc.
This is an idea that seems good on its face, but I think we'll find is actually rather anti-productive in practice.

Out of curiosity, how is this anti-productive?

-- Deltaneos (talk) 00:13, August 4, 2017 (UTC)

I don't understand how unifying the pages helps this. Surely each page is going to have their own textual content, generating their individual descriptions? Google can smartly identify pages like this and cluster them together.
Is "templates" what you intended to say? Don't search engines primarily just look at the rendered HTML, while how it got generated is of little interest, as long as it was present on the initial load?
Google also prefers pages with more text on them, and adds additional weight. There's no penalty for long or duplicated pages, but there's punishment for short pages. A search for "Dragon Ice errata" should ideally find the Errata on the "Dragon Ice" page, rather than on a short (potentially stubby) "Card Errata:Dragon Ice" page, giving more weight there. Can Google cluster pages? Potentially, if they're defined in <head> as <link> relationships or have semantic data explicitly linking them. FANDOM doesn't generate that from markup. And you still have the same issues. Many stub articles with little searchable content aren't really better there. Also, navigating inbetween different articles with a navbox is not really an option on mobile.
Here's the thing: conceptually, you're a wiki. Wikis have articles. Breaking it apart like the community is a GUI or a database may not be the better paradigm.
"Templates" is, by the way, what I intended to say. Some templates render differently than others, and some are parsed differently (both on desktop and on mobile). Further, our own tools do a bit of parsing and in lieu of other content assumes things like the contents of {{About}} should be sent as the Knowledge Graph page description. So a good part of this sort of thing is even before it gets processed by Google. Template Classification plays a role, too, in how we shape what goes out, as Google interprets the mobile version as well (which omits navigation elements by design).
Regarding your mockup, we're actually not aiming for that, for a couple reasons. Admittedly, some of them are business reasons. But we normally avoid surfacing so much information to Google's Knowledge Graph that people have no incentive to actually visit the page. Also, those clusters only occur in situations that Google controls, such as being the top result. The clusters are limited to only a couple of branch pages. We have some experience in how to present in the best format to Google, if you'll leave that responsibility to us.
I'm not sure about that. Search engines are intelligent and will figure the best result based on what the user typed. If the search criteria is not very specific, the search engine will probably get the most popular one, which is likely what they're looking for.
Hopefully you realize that we have SEO experts on staff that can answer this question. Consolidated, rather than scattered short content, is weighted more heavily, as the search engine has more text to work with. Please understand that this is something we have quite a lot of experience with, and that we're not trying to steer you down a blind path.
In terms of actually using the site, you should find what you are looking for through context. If you're reading about a video game, you get linked to the card as it appeared in the video game.
You know, I do get that. I really do. And you know how your community and the various games work, functionally. I can make a suggestion, but you're not obligated to agree. But you do make a strong case for a well organized Table of Contents, conveniently located immediately after (on mobile) or left of (on desktop) the infobox.
That page is mobile-friendly.
That particular one is, let's say, moreso than others because it is very small. It still could be better. We have a standard way to make it better. 😊
Why don't you like metatemplates? It seems like textbook "don't repeat yourself".
For a few reasons. Server call overhead, data parsing concerns. At a certain point layer pass depth the rendering functions of MediaWiki stop working properly. Metas are harder to understand for someone else doing the coding, because they have to pull the templates from multiple places and it increases the number of potential points of failure.
My question is "Why is it favorable for the desktop visuals to be an infobox?".
A card table *IS* an infobox, in the sense that it's conveying key/value pairs of information about a data object. As such, there's a standard format of what a reader should expect. For the same reason, visually, that most restaurant menus follow a multi-columnar format: spatially scattering across a wide visual field is psychologically offputting and physically taxing on the eyeballs. Having that key data in a more constrained visual field is good practice, no matter the rendering device. Wide page books and newspapers break into multiple columns. The responsive web equivalents are with breakpoints. We're getting into an increasingly academic debate here about the nature of visualizing data and making the reader work to understand it, but it bears out in practice. Unless you're just playing devil's advocate. I can't tell.
All that to say: card tables laid out in the way you describe are just not a very usable design as a pattern when scaled >= 500px.
Nonetheless, you're drawing a possibly erroneous conclusion that the HTML is exactly the same per platform. Especially as applies to the mobile skin and portable elements like PIs, the HTML is not the same; we strip and tweak all sorts of things. It's not only a case of markup. Tag extensions are programming subroutine inputs, not illuminated hypertext. We responsively change the output dependent on the platform. That's not always possible to do properly unless you're using something like PIs.
Although, that means you need to scroll past the entire infobox to see it on mobile.
With PIs as the dominant element on any article that's always going to be the case. PIs always go "above the fold".
Out of curiosity, how is this anti-productive?
Call it a hunch. We can try it.

FishTank @fandom (wall) 01:11, August 5, 2017 (UTC)

Google also prefers pages with more text on them, and adds additional weight. There's no penalty for long or duplicated pages, but there's punishment for short pages. A search for "Dragon Ice errata" should ideally find the Errata on the "Dragon Ice" page, rather than on a short (potentially stubby) "Card Errata:Dragon Ice" page, giving more weight there.

I do like your idea to merge errata and the other namespace-dedicated pages, which are listed under "Other Card Information".

Do you feel the same way about the per-medium pages? A card can appear in multiple games/media, where it can potentially operate under different mechanics, have different stats, names, lores, images, sets, means of acquisition, Fusion material, compatible targets, be used by different characters and other concepts specific to the game they appear in. Do you want me to give you a list of every type of detail, we can cover for a single card across all media it appears in and see how you feel it is best presented?

But you do make a strong case for a well organized Table of Contents, conveniently located immediately after (on mobile) or left of (on desktop) the infobox

We can try. This might tie in the above request.

Can Google cluster pages? Potentially, if they're defined in <head> as <link> relationships or have semantic data explicitly linking them. FANDOM doesn't generate that from markup. And you still have the same issues. Many stub articles with little searchable content aren't really better there. Also, navigating inbetween different articles with a navbox is not really an option on mobile.

I'm only aware of rel="canonical" for semantically linking pages that way. Although, it's not really what I was going for. My mockup was probably unclear. I meant to draw attention to the four search results, which are "clustered" under the first one. (Although as you've since pointed out, that's only for result 1. The knowledge graph was me getting carried away with altering the screenshot. Although, thank you for your insights on it.)

Or was your point about merging to improve search engine visibility that all the page views will be centralised, giving one high-ranking page?

Also, navigating inbetween different articles with a navbox is not really an option on mobile.

I agree. I'm not even sure if they're especially useful on desktop. Do you have analytics that tell you how frequently navboxes are used in general?

Also, I would imagine (although with little certainty) that the navboxes we have that link the different variations of the card are not used too frequently, even on desktop. After reading the Yu-Gi-Oh! BAM "Dragon Piper" page, I think people are more likely to want to read another BAM page next, rather than its manga, DM1 etc. counterpart (except maybe the "main" one). The options for seeing other cards in the same game are to use a "related pages" link or click the "list", "gallery" or category link. I also don't know how frequently any of them are clicked.

I'm not sure about that. Search engines are intelligent and will figure the best result based on what the user typed. [...]
Hopefully you realize that we have SEO experts on staff that can answer this question. Consolidated, rather than scattered short content, is weighted more heavily, as the search engine has more text to work with.

My point was more in response to your concern that users might not know which page they're looking for. But anyway, I can accept you've made a fair argument in favour of the unified article approach.

I am aware and appreciative that there are staff of various disciplines improving the sites behind the scenes. I don't doubt your abilities. We're still presented with a massive paradigm shift from outside the immediate Yu-Gi-Oh! community. You can accept that the editors will still want to scrutinise it? I hope I'm not agitating you with the feedback and questions.

As for the look of the full-width templates, that's not really possible to replicate as that's the primary reason why the page is not mobile-friendly to begin with.
That page is mobile-friendly.

That particular one is, let's say, moreso than others because it is very small. It still could be better. We have a standard way to make it better. 😊

Are the longer ones are massively different (CardTable2 excluded)? I don't understand how the used of a full-width template has any impact on this.

Nonetheless, you're drawing a possibly erroneous conclusion that the HTML is exactly the same per platform. Especially as applies to the mobile skin and portable elements like PIs, the HTML is not the same; we strip and tweak all sorts of things. It's not only a case of markup. Tag extensions are programming subroutine inputs, not illuminated hypertext. We responsively change the output dependent on the platform. That's not always possible to do properly unless you're using something like PIs.

My original question was I understand the structural changes; portable infoboxes for consistency across Wikia, semantic HTML and uses Wikia's core features so has full support, including mobile styling and JS. Lua for performance and cleaner code. But why the aesthetic changes?

I can understand the push for portable infoboxes and thanks for giving more clarity. Can we not have both portable infoboxes and the current styling, is what I was getting at. A portable infobox can easily be styled to 100%. Getting the image on the left can be achieved which hacky CSS, but would only require a small* HTML change to be able to do it more cleanly. (*I don't know what level of backend work would be needed or exactly how big an impact it may have, so I can understand it may not be as "small" as it seems.) With that much, it doesn't take too much to style a portable infobox to look like the current (non-CardTable2) card tables. Am I being too wishful?

Why is it favorable for the desktop visuals to be an infobox?
A card table *IS* an infobox, in the sense that it's conveying key/value pairs of information about a data object. As such, there's a standard format of what a reader should expect. For the same reason, visually, that most restaurant menus follow a multi-columnar format: spatially scattering across a wide visual field is psychologically offputting and physically taxing on the eyeballs. Having that key data in a more constrained visual field is good practice, no matter the rendering device. Wide page books and newspapers break into multiple columns.

The full-width card table is also split into columns. The widest portion, being the lore/description, which on desktop will not go beyond 610px, in the default skin. This can be reduced if too wide.

All that to say: card tables laid out in the way you describe are just not a very usable design as a pattern when scaled >= 500px.

The image takes 200px. When the entire "table" is >=500px, the other column becomes between 278px to 636px. The aforementioned lore is the only thing that tends to become multiline.

-- Deltaneos (talk) 02:29, August 10, 2017 (UTC) I'm sorry that it's taken me a while to respond.

Do you want me to give you a list of every type of detail, we can cover for a single card across all media it appears in and see how you feel it is best presented?
I don't think we need one card per page "to rule them all". I think we can do separate media under different headings, and have an infobox under that heading. And I think we may be able to do this in a relatively rapid development using DPL.
Or was your point about merging to improve search engine visibility that all the page views will be centralised, giving one high-ranking page?
Yes.
Do you have analytics that tell you how frequently navboxes are used in general?
I don't, offhand. I could probably get engineering to give me a census of those "in general", but the CTR (click-through rate) on Yu-Gi-Oh in specific would require some tracking and longitudinal study with JavaScript. I'd venture that it's fairly low.
The options for seeing other cards in the same game are to use a "related pages" link or click the "list", "gallery" or category link.
Which we actually do in the infobox in the current draft.
You can accept that the editors will still want to scrutinise it? I hope I'm not agitating you with the feedback and questions.

Of course! And no, you're not. Nothing wrong with the Socratic method.

Are the longer ones are massively different (CardTable2 excluded)? I don't understand how the used of a full-width template has any impact on this.
Article length (and even infobox length, as it collapses after a certain point) is not a critical factor, but fixed layout width is. And when more content fills up the table, the less easy it is to read because the fixed layout does not "flow" or "wrap". The natural coloration of PIs also helps delineate this in terms of readability.
Can we not have both portable infoboxes and the current styling, is what I was getting at. A portable infobox can easily be styled to 100%. Getting the image on the left can be achieved which hacky CSS, but would only require a small* HTML change to be able to do it more cleanly. (*I don't know what level of backend work would be needed or exactly how big an impact it may have, so I can understand it may not be as "small" as it seems.) With that much, it doesn't take too much to style a portable infobox to look like the current (non-CardTable2) card tables. Am I being too wishful?
I'll be more blunt, since I think we're at the point where I can be. The PIs can be styled to 100% with CSS, but this is further investing in bad design. And it causes really ugly results in the Apps. We also can't change the HTML result without a massive overhaul. It really would take a lot, and I can't justify a development effort internally when I know the product designers will tell me outright that it's a bad design to accommodate. Readers expect a standard width infobox. But more to the point, even if we could, it doesn't mean we should. I've slipped in a picture here of a recent attempt at full width PIs on another community as seen on mobile.

[1]

On desktop, it's also not very functional, leaving huge swaths of whitespace. I can't be much clearer than to say "treat data as data, and don't use tables for layout". See reasons already described.
Am I being too wishful?

Not too wishful, but perhaps a bit dogmatic. Sadly, I have to respond with being equally dogmatic: full width elements are a non-starter. Full stop. We can do better without them, and make more happen with less space. It's less familiar to your community, but it's empirically much more worthy. FishTank @fandom (wall) 15:46, August 18, 2017 (UTC)

I'm planning to get back to working on YGO this or next week. Did I answer most of your concerns? FishTank @fandom (wall) 20:44, September 5, 2017 (UTC)

SEO Addendum

As an addendum, I have an excerpt here from the FAQ of our SEO experts. I've included some of the entries that delve into what we've talked about in this conversation, and some others that are relevant to Yu-Gi-Oh's site organization.

What can users can do to improve organic search rankings?
There are many things to include here, but these are five of the most important:
  1. Write unique, in-depth content.
  2. Focus each page on a single topic.
  3. Add relevant links to each page to ensure all pages can be found.
  4. Complete stubs and build wanted pages.
  5. Share content with those who are as passionate about the topic as you are!
What are we doing that could hurt organic search performance?
SEO best practices are focused on creating unique, descriptive content that can be found and understood by both human users and search engines. Practices that have a negative impact on SEO are (for the most part) things that make pages hard to read or hard to find.
Some things to avoid:
  • creating entire pages of image-based templates and navigation without supporting text
  • creating multiple pages on the same topic
  • excessive use of the main keyword on the page
  • orphaned and dead-end pages (use Insights to clean these up!)
It is also important to avoid creating content that is similar or identical to that found on another page or website—this includes "near duplicate" content that presents similar information in the same order or copies blocks of text.
Is there mobile SEO? If so, what can we do to rank better in mobile organic search?
Yes! More and more people are using phones and tablets to search, so Google and other search engines are adjusting their algorithms to ensure mobile users have the best possible experience.
Most things that should be optimized for mobile (e.g. breakpoints, page load speed, back button behavior, font sizes) are [internally handled by FANDOM's product and engineering teams], but users can help mobile SEO by converting to portable infoboxes.
Do article pages help SEO?
More than 80% of people who visit our communities come through organic search, and 90% of those visitors start out on article pages. Articles pages that include unique, in-depth content and link out to important article and category pages are fantastic for SEO and critical to FANDOM's success.
How should I name our pages? Is there a naming convention that is best for SEO?
Googlebot and other search bots seek to mimic human behavior in evaluating content, so modern SEO is all about user experience. Old school keyword stuffing and link manipulation are out of date; search algorithms are too sophisticated and organic search rankings are too closely tied to user behavior. In truth, both users and search bots prefer accurate page titles and site architecture that aids content discovery.
Page headings and titles are strong, strong signals, so the best practice is to include the most common search terms as “up and to the left” as possible. The logic behind this practice is (1) it makes it more obvious that a page is the most relevant result - and without relying on Google to grasp the relationship between the terms (e.g. 'Wolverine' and 'James “Logan” Howlett') - and (2) it encourages increased click through since casual fans (i.e. search engine users) can tell it is the “right” result from a quick scan through a search results page.
Do stubs and redirect pages impact SEO?
Hundreds of factors contribute to page rank, but since Google's Panda algorithm updates started in 2011, it has become increasingly important to avoid "thin content" (i.e. content that has little to no value to users). It is even thought that Google considers the ratio of quality to low-quality pages across a domain and ranks the entire site accordingly.
Content quality can be judged algorithmically through a metric called “time to long click”. Think about how you behave when you stumble upon a great blog post or article in search results—you spend some time on the page, scroll down a bit, and might click around to explore other content on that site. That is a long click.
On the other hand, some search results are just not what you are looking for—you click back to the search results page almost immediately (short click) and move on to the next result, indicating to Google that the first result didn’t provide much value. Stub pages that appear in search results are more likely to result in a short click than a long one.
Incomplete articles are a natural part of a collaborative site like FANDOM, but our goal should be to minimize the number of thin content pages in our communities. Focus on the most important articles and build those first (e.g. complete the main Spider-Man article before moving on to alternate reality versions). One completed article is better for SEO than multiple stubs and redirect pages created to make our content seem relevant in long tail searches.
Does page length have an impact on SEO?
Page length alone is not good or bad for SEO. What matters a lot more is that the content on the page is targeted around a single keyword (without being a complete avalanche of everything you know about the topic). If you read through it and think: oh okay, this is all about one thing, there's not a lot of repetition or generic text here, and there are links pointing people to related articles; then it is a good indication that it belongs as one article.

FishTank @fandom (wall) 19:16, August 18, 2017 (UTC)

*Disclosure: Some of the links above are affiliate links, meaning, at no additional cost to you, Fandom will earn a commission if you click through and make a purchase. Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+