FANDOM


  • Aiihuan
    Aiihuan closed this thread because:
    Necroposting. Please create a new thread for your matter.
    02:44, January 21, 2018

    Today we are excited to announce the official release date for the redesigned page and article headers. One of the things we talk about in the announcement is the updates we have made to the Theme Designer so you can customize the header image and the color of the header. You can see a mockup of the Theme Designer change here:

    Theme Designer Update

    As part of the redesign we also announced that we will no longer be allowing most forms of CSS and JS customization to the headers. This includes adding fourth and fifth level sub-menus to Wiki Navigation. Some wikis out there have these customizations, and a point of feedback we heard when we showed these changes to the Community Council was that some admins felt that these fourth and fifth levels were essential to their navigational structure. We've opted to disallow this type of customization not only to ensure design consistency across Fandom but also because of the simple fact that it's a bad design practice and hinders the user experience.

    The thinking admins tend to have in adding in fourth and fifth level options is that more navigational links leads to more visitor engagement. After all, if visitors can see as many major topics as possible in the navigation menus, they're more likely to find what they're looking for and stick around, right? That's not actually the case. Providing more links actually makes things more difficult for your visitors.

    Too much choice is a bad thing in the user experience design world because it leads to what's known as decision paralysis. This means there's so much over-analysis of what to do that visitors find it difficult to decide what to navigate to. Once a user reaches this point, they get frustrated and leave with a bad taste in their mouth, making them unlikely to return to your wiki and instead find answers elsewhere.

    So what makes a great menu navigation? How should you handle your complex wiki structure with thousands of pages? And why should you limit your navigational links? Here are a few articles answering these very questions, which we think are helpful to understanding the reasons why we do not want fourth and fifth level options:

    Here are the key points you can find in the articles, which you should keep in mind when designing a navigational structure:

    • Follow the KISS method to success: "Keep It Simple and Straightforward."
    • Avoid deep navigation, like level 4s and 5s, for the reasons addressed in this post.
    • Group menu items into high-level categories. Users don't need to see every major topic, they just need to have a way to access them. Prioritize your navigation to the pages users need the most, not everything you think they might be looking for.
    • Separate essential links from secondary "nice to have" links, then build your navigation accordingly.
    • While simplifying your navigation think about ways you can add important and/or related links to your content, rather than the navigation menus.

    I hope this advice is helpful for those wikis with fourth and fifth level menus. We are more than happy to work with with any community with fourth and fifth levels on advice and other good practices when they are adjusting their navigation structure to account for this change.

      Loading editor
    • Great. No surprise that our customization options are being further limited.

        Loading editor
    • No customization is very unfair. And doesn't allow wiki admins to be creative with our communities, thanks Fandom... You might as well control who gets promoted and who can edit and can't edit on every wiki now, since you're slowly trying to control the entire experience. It's really not fair, I worked long and hard to find a great font for my community and now it's going to not match the nav bar when it's released.

        Loading editor
    • So I'm guessing we can't change things like spacing and hover behavior either?

      Whatever, I don't care anymore.

        Loading editor
    • Banarama
      Banarama removed this reply because:
      Not as relevant for now.
      16:13, June 15, 2017
      This reply has been removed
    • Are wiki admins gonna get any warning, if navigation changes break their current structure? I assume it's just a "tough sh!t, deal with it".

        Loading editor
    • A lot of other types of sites, not just wikis, have been trying to simplify navigation bars. Usually how it turns out is that the navigation bar contains a select few very general pages. Therefore, it takes a lot of browsing from page to page to find details and even then it isn't necessarily what the user wants. The university I attend did this to their main website. In addition, they consolidated a bunch of department websites onto the main website. I could go on a long rant about that, but the long and short of it is as follows. The simplified designs are typically better for those who don't know what they are looking for and are just at the site to casually browse around. However, for those who know what they are looking for, it actually becomes harder to find it. This is because what was once available right on the navigation bar is now hidden behind layers upon layers of links. Sure, once the resource is found, the URL can be booked marked. However, that means the user essentially has to recreate the old navigation bar by bookmarking all the pages.


      Not to mention that all these new changes are very broken in IE and Edge. I know they are not supported browsers but I seriously wonder how great the page design can be if it only works on two browsers; and requires them to be the most recent versions at that.

        Loading editor
    • Edge should probably be supported, but kicking IE to the curb is long over due.

        Loading editor
    • OneTwoThreeFall
      OneTwoThreeFall removed this reply because:
      .
      12:56, June 2, 2017
      This reply has been removed
    • I suspect that less levels will increase the reliance on the local searchbar. Could that see updates to its algorithm and redirect behaviour? For example, only enabling Go-Search will give you the direct result if you've typed the exact pagename of a redirect.

        Loading editor
    • If only Fandom search were better...

        Loading editor
    • It also lists search results in no order whatsoever — it apparently prioritises whichever item is fetched first over which results actually correspond to the search terms.

      Not to mention no support for any modifiers like verbatim-forcing quotes or booleans.

        Loading editor
    • Awesome, less customization.

      What's next, Wikia? Do you want to pick my avatar for me to ensure design consistency? Maybe change all of our usernames so they match each other and follow a "Fandom" theme? Hell, you guys should write the articles for us. Some wikis have terrible articles that aren't consistent with another wiki's fantastic ones -- just write them all yourself to ensure consistency. We obviously don't want potential ad-revenue generators readers being thrown off by poorly-written articles. 

        Loading editor
    • At this point I wouldn't even be surprised if Wikia just ditched CSS altogether for some reason, like "consistency" or "the mobile experience". There's no reason for these new features to not at least allow CSS, it makes them look disconnected from other areas that do use CSS. Needless to say my hype for the new navigation dropped from 100 to 0 real quick.

      I don't see what would be wrong with removing the gradient or adding a border to the header. Soon enough the desktop site will be identical to mobile one in terms of appearance.

        Loading editor
    • We will no longer be allowing most forms of CSS and JS customization to the headers.

      Please clarify what you mean by "most forms" because both CSS and JS can provide a very wide variety of changes and we don’t want anyone tripping over anything accidentally.

      We've opted to disallow this type of customization not only to ensure design consistency across Fandom but also because of the simple fact that it's a bad design practice and hinders the user experience.

      The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. "Is what I’m designing consistent with other things we’ve designed (or others have designed)?" is the wrong question to ask. Instead,"Will the user’s current knowledge help them understand how to use what I’m designing?" Current knowledge is the knowledge the user has when they approach the design. It's the sum of all their previous experiences with relevant products and designs. When you think about consistency, you’re thinking about the product. When you’re thinking about current knowledge, you’re thinking about the user. They are two sides of the same coin. I've just noticed that the designers who spend more time thinking about the users are the ones that end up with more usable designs.

      The thinking admins tend to have in adding in fourth and fifth level options is that more navigational links leads to more visitor engagement.

      This is not necessarily true, navigation bar links can be as simple as categories breaking down, to the simplest form, such an example would be on the SU wiki where they give links to what a "fusion" consist of.

      That is just what I think, though.

        Loading editor
    • This,is a disaster.

        Loading editor
    • ΜΖD wrote: At this point I wouldn't even be surprised if Wikia just ditched CSS altogether for some reason, like "consistency" or "the mobile experience". There's no reason for these new features to not at least allow CSS, it makes them look disconnected from other areas that do use CSS. Needless to say my hype for the new navigation dropped from 100 to 0 real quick.

      I don't see what would be wrong with removing the gradient or adding a border to the header. Soon enough the desktop site will be identical to mobile one in terms of appearance.

      This sounds like you don't understand what CSS is... CSS is used for like 99% of the styling of everything. The only difference is that some CSS can be customized by admins and users and some can't.

        Loading editor
    • Fandyllic wrote: This sounds like you don't understand what CSS is... CSS is used for like 99% of the styling of everything. The only difference is that some CSS can be customized by admins and users and some can't.

      I know what CSS is? I've been using Wikia and editing CSS for some 6 years now. All I said was with the way "modernized" features (discussions, new header and footer, etc) don't allow CSS customization I could see Wikia removing it from even more things if they continue modernizing more parts of the site.

        Loading editor
    • We are more than happy to work with with any community with fourth and fifth levels on advice and other good practices when they are adjusting their navigation structure to account for this change.


      How and where can I receive such support?

      Edit: Also, did I miss something or were you guys so opt to receive user feedback and make test versions only to then just decide this without any of the aforementioned discussion?

        Loading editor
    • I've been Admin on a Wiki for a few months now but I'd say I'm still relatively new. I've read about how Wikia has slowly been taking away customization, and I can imagine that I'd be angry too if I put a lot of work into making a Wiki distinct only for this to happen.

      But then again, I don't really read about all the great looking Wikis when they used to have more customization. Sometimes, we have to let go of the details and stop worrying about the fonts and gradients, and go back and think about the experience of the reader. To me, that's what Wikia is doing, and generally, I think people aren't the best at deciding what's best overall. Personally, I think I suck at customization, despite majoring in art, and that's because designing a site is a whole other beast. So I'm glad Wikia is gonna make our Wikis look a little cleaner for us and giving us a few more tips for the top navigation.

        Loading editor
    • I'm not sure — they're giving us tips by locking it up.

        Loading editor
    • For once I’d like to see a good feature roll out that didn’t trip at the finish line & scrape its face on the pavement. These headers were universally regarded as a flat upgrade up until this point. CSS can’t change much basic functionality, so if standard experiences are the goal, removing CSS is overkill. Even despite the fact that the myriad uses of JavaScript were thrown under the rug, such as different Navs per content area, I understand that they change basic functionality. CSS however, does not. To quote Fandom, CSS is the path to “a brighter, more colorful web”. By their own words Fandom is shooting itself in the foot by killing off CSS, that beauty of individuality.
      I wonder also, how does Fandom plan to restrict CSS? JavaScript is already regulated by the review process, but CSS is not currently regulated. Is there going to be a “CSS review process”? How far down the rabbit hole are we going to go?
        Loading editor
    • I personally do love the new page header. Sure, I see why you want to disable ExtendedNavigation and JS, but why restrict CSS? Some wiki admins would like to customize their wiki in many ways, and why are you no longer allowing CSS customization for the new page header?

        Loading editor
    • Gotta love Central sometimes.

      • Fandom: "Hey guys, we're updating the header because the old one sucked. This new one is prettier, and you can even add your own image in it!"
      • Central: "Cool! Sounds great!"
      • Fandom: "Okay, here you go, only thing is, we're going to have change a certain option, because evidence suggests that it actually hurts your wiki's viewership a lot, and-"
      • Central: "OMFG DAE fandom LITERALLY stripping customizations from wikis???? Time to RAGEMODE PROTEST!!!!!"

      I'm sure Staff would have less of a problem addressing (sometimes legitimate) feedback and concerns a lot more if you read beyond the title of their threads.

        Loading editor
    • If you cared to read the replies, you’d see that most of these comments have cogent points & are not simply knee-jerk reactions to titles. Belittling people & comparing their outcry to childish irrationality doesn’t make your points any stronger nor does it make our points magically go away, it just makes you personally look insulting.

        Loading editor
    • Technobliterator wrote: Gotta love Central sometimes.

      • Fandom: "Hey guys, we're updating the header because the old one sucked. This new one is prettier, and you can even add your own image in it!"
      • Central: "Cool! Sounds great!"
      • Fandom: "Okay, here you go, only thing is, we're going to have change a certain option, because evidence suggests that it actually hurts your wiki's viewership a lot, and-"
      • Central: "OMFG DAE fandom LITERALLY stripping customizations from wikis???? Time to RAGEMODE PROTEST!!!!!"

      I'm sure Staff would have less of a problem addressing (sometimes legitimate) feedback and concerns a lot more if you read beyond the title of their threads.

      Are you stupid? I think we all know how to read here.

        Loading editor
    • Ursuul wrote:

      If you cared to read the replies, you’d see that most of these comments have cogent points & are not simply knee-jerk reactions to titles.

      And none of them respond to the content at all. It's just "q_q customization going away", then whining about a slippery slope and how customization makes wikis special. I'm fairly sure Fandom Staff know that that's the case, but as the thread stated, there are very clear reasons why CSS and JS, as well as fourth/fifth level navigations, do not make sense anymore (btw, it's extremely easy to make a font for a wiki and use CSS to prevent the font affecting the top nav or the bottom of pages).

      Belittling people & comparing their outcry to childish irrationality doesn’t make your points any stronger nor does it make our points magically go away, it just makes you personally look insulting.

      Of course not, but do you not see how, when you fail to interpret the other point of view, and basically rage post about customization just because of the removal of one feature, you will rarely ever receive a response? This is standard Community Central practice, they flip out over the removal any tiny customization feature lost, even if they demonstrate very clearly how said feature is actually a detriment to the wiki, and entitled users complain about "no, we'd rather keep it and drive readers away, also remove all ads and let us remove the Fandom banner". After this, they collectively barrage a thread with dozens of responses (often including flaming), whine about some "corporate dystopia" in which Fandom has control over everything, and turn around and claim they have "community support" and that therefore staff should give into their (often unreasonable) demands.

      It's happened every time for the past few years and it's why I wish Fandom didn't even announce things to Central and just went ahead and made the changes anyway. You're not going to get any constructive feedback here.

        Loading editor
    • Technobliterator wrote:

      Ursuul wrote:

      If you cared to read the replies, you’d see that most of these comments have cogent points & are not simply knee-jerk reactions to titles.

      And none of them respond to the content at all. It's just "q_q customization going away", then whining about a slippery slope and how customization makes wikis special. I'm fairly sure Fandom Staff know that that's the case, but as the thread stated, there are very clear reasons why CSS and JS, as well as fourth/fifth level navigations, do not make sense anymore (btw, it's extremely easy to make a font for a wiki and use CSS to prevent the font affecting the top nav or the bottom of pages).

      I just wish at least CSS and renaming the text in the Explore menu (e.g. Random page to Randomizer) was still permitted. If these customisations were still permitted, I would've completely support the new page header.

        Loading editor
    • JustLeafy wrote:

      I just wish at least CSS and renaming the text in the Explore menu (e.g. Random page to Randomizer) was still permitted. If these customisations were still permitted, I would've completely support the new page header.

      That's JS, but something like that sounds reasonable. You may be able to get Fandom Staff to be more lenient there.

        Loading editor
    • I don't like customization being limited. One of the biggest issues I have here is they refused to establish the extent of the ban on CSS/JS. I get prohibiting JS to drastically change the nav's behavior, but CSS seems pretty harmless to me. I was initially upset about the upcoming ban on the ExtendedNavigation, but I can still see rationale behind it. Most people can't handle lots of information (I have my own thoughts on that, but I'll keep those to myself) and not long after this post I completely rebuilt the wiki's nav (it's probably more useful now than before and further highlights the wiki's awesome categorization structure). Regardless of the reasons Fandom or other users give, I personally believe wikis should be able to drive away readers if they want to do something they think is necessary, even if others think it's a bad idea (it only directly hurts themselves). I doubt it hurts Fandom's bottom line considering the vast number of wikis pull in very few views.

        Loading editor
    • @Technobliterator:

      Please give examples of them clearly stating how CSS customisation will inevitably harm wikis and reduce page views, other than in the case of ExtendedNavigation. I understand that you may want to support Fandom in this case, but actually take a look at the replies. Has Fandom given any rationale for removing CSS? Are those users then ignoring said rationale? Or are they ignoring something that does not even exist? I invite you to actually read through everything, without being caught up in ideological blind hatred of debate.

      Meanwhile, you continue to compare actual criticism with "whining", and disliking Fandom's reduction in the agency of individual wikis (which after all, could move to another host) with flaming. Such an eloquent argument. Everyone that was just providing cogent points, ~SHUT UP! YOU'RE ALL 9-YEAR-OLDS IF YOU ARGUE WITH THE SITE HOST!~

      In addition, Tech, you are being highly inconsistent. On one hand you're saying CSS and JS = unworkable, the other hand you're saying that CSS and renaming NavBar text is "reasonable". Can you provide a clear platform?

        Loading editor
    • Technobliterator wrote:

      JustLeafy wrote:

      I just wish at least CSS and renaming the text in the Explore menu (e.g. Random page to Randomizer) was still permitted. If these customisations were still permitted, I would've completely support the new page header.

      That's JS, but something like that sounds reasonable. You may be able to get Fandom Staff to be more lenient there.

      I know, but I wish that JS code was an exception. I'll try contacting the Fandom Staff.

        Loading editor
    • DEmersonJMFM wrote: I don't like customization being limited. One of the biggest issues I have here is they refused to establish the extent of the ban on CSS/JS. I get prohibiting JS to drastically change the nav's behavior, but CSS seems pretty harmless to me.

      This has been explained before - the new page headers are supposed to be consistent across the entire site, same with the very top bar and the footer. This helps users move across the different wikis as they become a much more familiar experience to them, and more important, prevents certain wikis from adding bloated CSS that makes the header appear unreadable. Some wikis make decent use of CSS, but others just add fancy fonts and gradients just "because they can" and ruin it, which drives readers away. Fandom also explained that it is because advertisers want a more consistent page header across the site before targeting some ads at wikis - while you may think "boo, advertisers", this actually means pages will have fewer ads overall in favor of a few high quality ads. Keeping the bloated smaller ads which often slow pages down is more likely to drive readers away.

      Everything else can still use CSS, and even the top header still allows you to add a picture - so for those who aren't CSS savvy, it's technically more customizable than before. Also, the design of the top nav, which most people agree is infinitely better than the old one, is what most customized top navs looked like anyway. So it's not like this is some evil plot to take away customization from the entire wiki, it's literally just for the page header.

      Regardless of the reasons Fandom or other users give, I personally believe wikis should be able to drive away readers if they want to do something they think is necessary, even if others think it's a bad idea. I doubt it hurts Fandom's bottom line considering the vast number of wikis pull in very few views.

      Then you philosophically disagree with Fandom Staff. I would think both Fandom Staff and most users would want their work to reach the broadest number of people possible (albeit for different reasons - obviously for Fandom there's a monetary incentive and for users it's to feel pride in their work). But after having explored a lot of the wikis and seeing how some of them just follow bad practices when they're allowed to, personally I think that customization should be more limited. I believe that every wiki should be allowed to have its own identity in terms of appearance, and a few nice pieces of functionality, but that beyond that, shouldn't be given so many tools that they can break their own wikis.

        Loading editor
    • That's mostly true, but all I really need is to be able to make minor design changes that are beyond the scope of the Colour Changer Theme Designer, like for example, rounding the outside corners or giving the navigation bar a small border. Fandom may be being a little paranoid — I've never seen a heavily overcustomised header in my day, only ones tweaked in reasonable ways that still enable readability.

        Loading editor
    • SuperRobot9338 wrote: @Technobliterator:

      Please give examples of them clearly stating how CSS customisation will inevitably harm wikis and reduce page views...

      See my response above - there is plenty of rationale.

      Meanwhile, you continue to compare actual criticism with "whining", and disliking Fandom's reduction in the agency of individual wikis (which after all, could move to another host) with flaming. Such an eloquent argument. Everyone that was just providing cogent points, ~SHUT UP! YOU'RE ALL 9-YEAR-OLDS IF YOU ARGUE WITH THE SITE HOST!~

      I don't. Actual criticisms are often very legitimate - but they are lost in the whining. Like I said, the typical Central response to any, even minor, loss of customization is a resounding ragepost, is conspiracy theories about how it's all an evil plot to make every wiki look the same, and often without even considering the other point of view. You may say, "well, they didn't consider our point of view either!" But yet when they open threads and see responses like this, they're not going to be able to consider your point of view because they will have to read through so many hate comments (often not fun) before they do that. We need more reasonable, constructive criticism of Fandom before we're going to be able to work with them.

      btw, the "lmao we can just move host" threat often turns out to be a hollow threat. Very few of the wikis that moved off-Wikia ever surpassed them, because they do not have the same search engine advantage.

      In addition, Tech, you are being highly inconsistent. On one hand you're saying CSS and JS = unworkable, the other hand you're saying that CSS and renaming NavBar text is "reasonable". Can you provide a clear platform?

      No I'm not. I'm saying that renaming navbar text sounds very reasonable because it won't significantly alter how the navbar works, will still allow it to feel familiar across different wikis, and have no potential to break it. I'm also saying that feedback like that is much more reasonable and is much more likely to receive a response, and consideration, from Fandom Staff. I know that if I were staff, I would be more willing to work with and respond to something like that, than "OMFG staff taking away customization, everyone go move offsite!!!!!!!"

        Loading editor
    • Technobliterator wrote: See my response above - there is plenty of rationale.

      I don't see any major examples of "bloated CSS".

      I don't. Actual criticisms are often very legitimate - but they are lost in the whining. Like I said, the typical Central response to any, even minor, loss of customization is a resounding ragepost, is conspiracy theories about how it's all an evil plot to make every wiki look the same, and often without even considering the other point of view. You may say, "well, they didn't consider our point of view either!" But yet when they open threads and see responses like this, they're not going to be able to consider your point of view because they will have to read through so many hate comments (often not fun) before they do that. We need more reasonable, constructive criticism of Fandom before we're going to be able to work with them.

      We have brought constructive criticism if you look around the middle of the page — it's only after you posted that it's degenerated into flaming.

      btw, the "lmao we can just move host" threat often turns out to be a hollow threat. Very few of the wikis that moved off-Wikia ever surpassed them, because they do not have the same search engine advantage.

      Unencyclopedia + Fallout Wiki + League of Legends Wiki + Dota 2 Wiki + Dayz Wiki + … you get the point.

      No I'm not. I'm saying that renaming navbar text sounds very reasonable because it won't significantly alter how the navbar works, will still allow it to feel familiar across different wikis, and have no potential to break it. I'm also saying that feedback like that is much more reasonable and is much more likely to receive a response, and consideration, from Fandom Staff. I know that if I were staff, I would be more willing to work with and respond to something like that, than "OMFG staff taking away customization, everyone go move offsite!!!!!!!"

      Once again you're using the Strawman Fallacy — whenever anyone disagrees with you, you compare their criticism with whining.

        Loading editor
    • My issue with those wikis is that they were under a different circumstance with the previous skin changes. Considering the customisation policy hasn't been updated, it is a touch early to bust out the pitchforks. To my understanding, the comments about corporate intrigue and the death of customisation outright are likely what Techno describes as "flaming".

      I don't see entirely eye to eye with limited opportunity for header CSS, but I don't sense the intention is part of some greater plot like some people said. Those comments didn't stand out to me for their cogency like the others did. The recent rail module redesign didn't disallow people from restoring borders and backgrounds to it.


      I personally think cascading customisations (like a font change for the whole page) should be allowed to affect the header too. I still would like to know more details about what limited customisation is allowed. More options in the Theme Designer would be welcome:

      • I'd be interested in having an adjustable picture-to-gradient ratio.
      • The image in the test header above is more opaque than most of the other 30. A transparency option would be welcome - doing so through image editing is less versatile in the event of a colour scheme change.
      • Full-width background images would also be a welcome option.
        Loading editor
    • That's certainly true. In actuality, I'm fine with restrictions as long as it's only something like "no removing functionality, no obfuscating features, no reduction in clarity or usability" with a CSS review process. The only real reason there's all of this debate is due to Fandom's own ambiguity and lack of clarification on how this is going to work, other than a boilerplate message.

      However, the rail module update was different — that was just modifying the base styles, while this one is modifying the base styles and restricting the ability to change it.

        Loading editor
    • Technobliterator wrote:
      And none of them respond to the content at all. It's just "q_q customization going away", then whining about a slippery slope and how customization makes wikis special. I'm fairly sure Fandom Staff know that that's the case, but as the thread stated, there are very clear reasons why CSS and JS, as well as fourth/fifth level navigations, do not make sense anymore (btw, it's extremely easy to make a font for a wiki and use CSS to prevent the font affecting the top nav or the bottom of pages).
      The content, if you cared to read it again, was “X, Y, Z practices (basically extended navs) cause reader frustration & drive readers away & standard experiences drive views up”. That’s fine, totally understandable, but if you’d noticed, most of the replies begrudgingly accept that JS is barred but are asking why CSS is a problem. Fandom said that disrupting the usual functionality causes issues for readers; I accept that. What I don’t accept, & what Fandom has not explained, is how custom CSS disrupts the usual functionality. THAT is the crux of what people are asking after which you have either studiously ignored or reduced to mewling, childish bickering because you didn’t find it convenient to address it.
      Technobliterator wrote:
      Of course not, but do you not see how, when you fail to interpret the other point of view…
      Oh please. You’re the one who’s talking past everyone, while we’ve acknowledged Fandom’s points about JavaScript & are simply asking after CSS.
      Technobliterator wrote:
      …and basically rage post about customization just because of the removal of one feature, you will rarely ever receive a response? This is standard Community Central practice, they flip out over the removal any tiny customization feature lost, even if they demonstrate very clearly how said feature is actually a detriment to the wiki, and entitled users complain about "no, we'd rather keep it and drive readers away, also remove all ads and let us remove the Fandom banner".
      Again, as SuperRobot9338 said, they nor you have demonstrated how CSS is the problem. I agree that viewership is important & that’s why I’m more than happy to let JS go in this instance, but CSS doesn’t disrupt that. There’s no sense in removing it. In fact, if the lower Wiki is heavily unique, then the Header would clash with the Wiki below & admins would either be forced to adapt the Wiki to the Header or live with an eyesore. The Header being cut off from CSS is more far-reaching than you say.
      Technobliterator wrote:
      After this, they collectively barrage a thread with dozens of responses (often including flaming), whine about some "corporate dystopia" in which Fandom has control over everything, and turn around and claim they have "community support" and that therefore staff should give into their (often unreasonable) demands.
      Not a few hours ago you compared everyone’s legitimate complaints to irrational children, yet you have the audacity to complain about flaming. Have your cake or eat it.

      As for the Community Support bit; if Fandom didn’t want democracies insisting on their rights, then they shouldn’t have encouraged & propagated the notion that Wikis are ruled by their communities. Either it’s true or it isn’t, but saying it is true while acting like it isn’t won’t exactly discourage these events from happening.
      Technobliterator wrote:
      It's happened every time for the past few years and it's why I wish Fandom didn't even announce things to Central and just went ahead and made the changes anyway. You're not going to get any constructive feedback here.
      There is a difference between a void of constructive criticism & willfully discarding it. You & I both know that you, I, other Councilors, & users on the blog have mentioned other things they wanted in the headers (an option to replace the wordmark or remove it, separate theme designer controls for its color, a dropdown on the Discuss button containing links to specific categories, cascading CSS, et cetera). You know this, for you have been involved in these conversations! How about you stop sweeping everyone who disagrees with you under the rug & actually consider their statements? Even if the others are “whining,” they are still worth your ear because these are the people who work their butts off to make the best of their communities just like you do, & thereby provide revenue to Fandom & make Fandom a greater place. They’re complaining about the loss of CSS because it follows a trend of removal, because it restricts their community expression, & because it’s important to them.
        Loading editor
    • Technobliterator wrote:
      ...the new page headers are supposed to be consistent across the entire site, same with the very top bar and the footer. This helps users move across the different wikis as they become a much more familiar experience to them, and more important, prevents certain wikis from adding bloated CSS that makes the header appear unreadable. Some wikis make decent use of CSS, but others just add fancy fonts and gradients just "because they can" and ruin it, which drives readers away. Fandom also explained that it is because advertisers want a more consistent page header across the site before targeting some ads at wikis...

      The global nav and footer were Fandom's "space" anyways (I didn't even bring these up, not relevant). I'm not one of those that thinks Fandom wants to eliminate all styling, but your argument here for supporting the change could also be one for removing all CSS in general (for consistency sake and to not drive users away with CSS abuse that wikis do in general). What's the next thing that's "supposed to be consistent?"

        Loading editor
    • Technobliterator wrote:

      ...Fandom also explained that it is because advertisers want a more consistent page header across the site before targeting some ads at wikis - while you may think "boo, advertisers", this actually means pages will have fewer ads overall in favor of a few high quality ads. Keeping the bloated smaller ads which often slow pages down is more likely to drive readers away.

      ...

      First, where did you get this information? Second, I fail to see how this would impact ads. At least in the current setup, ads are placed between the global navigation and the header. Even if they weren't why do they care about the style of the page? So they can match the style of the ad? The only other thing I can think of is that they will use some sort of automated program to select which wikis to place the ads on; and that program, for some reason, obtains the subject of the page from visually reading the page instead of just looking at the content in raw form.

      Without further explanation, I really don't see how that argument makes any sense.

        Loading editor
    • Ursuul wrote: I wonder also, how does Fandom plan to restrict CSS? JavaScript is already regulated by the review process, but CSS is not currently regulated. Is there going to be a “CSS review process”? How far down the rabbit hole are we going to go?

      I was thinking about that as well the other day...but CSS is so widely used I feel like they wouldn't make a review process for that (at least I believe there's probably more wikis using CSS than JS). As it is there are wikis that have changed the footer, global nav, etc and don't face repercussions due to being smaller/not as popular and overlooked.

      I already wait sometimes 3 days for JS to get approved, the potential wait time for a CSS review process would be scary lol

        Loading editor
    • I hope I do not break the tempo here, but I while I can somewhat understand the CSS limitation (albeit as many mentioned, it is quite questionable for why Fandom seems to yet again remove customization for the various different types of communities) I cannot yet understand their reason to remove the JS extensions, and I'd really like Brandon or someone else to actually response to the comments and thoughts presented here...

      About the JS extensions though, I don't want to believe that they are actually having

      it's a bad design practice and hinders the user experience.

      as their sole reason for this. I once broke down my navigation levels to what Fandom would probably want, and visitors came left and right to tell me how much more they benefitted from the detailed navigation we had (Consequently I changed it back, here the nav in question). I do not understand how Fandom just generalizes it and simply declares like that what a bad practice it is. Among the many types of communities Fandom should house, mine most certainly proofed to have a great experience with it, whatever Fandom believes to be right for us.
      So might it be because of the uniform style across all Wikis that they are recently aiming for? In that case, the extended levels pose a minimum abnormality at most. After all, it doesn't visually alter the webpage at all.

      I don't tremendously fret over this, I just don't quite enjoy this lack of communication, as trivial as it might sound for some.

        Loading editor
    • Browseitall wrote: I hope I do not break the tempo here, but I while I can somewhat understand the CSS limitation (albeit as many mentioned, it is quite questionable for why Fandom seems to yet again remove customization for the various different types of communities) I cannot yet understand their reason to remove the JS extensions, and I'd really like Brandon or someone else to actually response to the comments and thoughts presented here...

      About the JS extensions though, I don't want to believe that they are actually having

      it's a bad design practice and hinders the user experience.

      as their sole reason for this. I once broke down my navigation levels to what Fandom would probably want, and visitors came left and right to tell me how much more they benefitted from the detailed navigation we had (Consequently I changed it back, here the nav in question). I do not understand how Fandom just generalizes it and simply declares like that what a bad practice it is. Among the many types of communities Fandom should house, mine most certainly proofed to have a great experience with it, whatever Fandom believes to be right for us.
      So might it be because of the uniform style across all Wikis that they are recently aiming for? In that case, the extended levels pose a minimum abnormality at most. After all, it doesn't visually alter the webpage at all.

      I don't tremendously fret over this, I just don't quite enjoy this lack of communication, as trivial as it might sound for some.

      One major problem for Fandom (although they don't seem to want to call it out) is that custom JS can break the VisualEditor which relies heavily on good upstream JS.

      As for the argument that deep levels of menu navigation are bad for users... Most of the study on this is not science, but pseudo-science. It usually relies on a particular audience of users and has no control comparison. The variety of users in most commercial web sites is much narrower than the broad variety in wikis. Commercial websites are designed for your grandmother, not your cosplaying cousin who uses a 3D printer to create replica weapons.

        Loading editor
    • Technobliterator wrote:

      We need more reasonable, constructive criticism of Fandom before we're going to be able to work with them.

      After just reading most of this thread for first time, I agree that it did start off with OMG, rage post initially. After reading the OP, tbh was not surprised as it sounded like even Fandom was expecting that. HOWEVER, it then settled down and most started questioning why CSS? More importantly specifically what forms of CSS will no longer be allowed.

      The op never clarifies any good reasons for removing CSS and even your stated given scenario "Fandom also explained that it is because advertisers want a more consistent page header across the site before targeting some ads at wikis", I still fail to see how this explains anything at all in regards to CSS. But anyway, I really could care less, most wiki I have gone to on Fandom are pretty basic similar formats being used.

      If are wanting real constructive criticism however. I wished they spent more time working on making initial user experience actually beneficial (instead of on this more appearance feature which most dont care about anyway). I have rarely seen many users actually even attempting to alter this (beyond admin) unless on rare occasion of attempting to make finding pages easier. Not on appearance of it.

      Please spend more time improving the Search engine, which is dreadful and appears to have random sort order results.

      Please spend more time finding a way to incorporate Category pages in the navigation menu much better. Usually, at least most wikis I have visited, wikis have pretty good structure set up with category pages, it is much easier to navigate and find what pages and articles you are wanting, once you are able to find good category page to start with. I am sure some wikis do not have good Category hierarchy set up, but for the many that do this would be beneficial.

      Please spend more time on Help pages, as once you do actually find page you are looking for and wanting to help contribute and add your improvements, is not bad. It is decent start for help pages. However, trying to find specifically what portions you are looking for is not the most intuitive. Worse is the lack of helpful info for those intermediate users. Basic beginner help ... great. Advanced ... pretty much over the top for intermediate. It really needs better help info for those in between. Including a whole list of all options plus better descriptions for each.

        Loading editor
    • SuperRobot9338 wrote:

      I don't see any major examples of "bloated CSS".

      I find that hard to believe.

      We have brought constructive criticism if you look around the middle of the page — it's only after you posted that it's degenerated into flaming.

      Please explain how your post earlier on this thread, in which you practically just spout conspiracy theories about how we're losing customization and turning into some "corporate blob" instead (you got 8 kudos for doing that, so you know your audience at least) is constructive criticism.

      Unencyclopedia + Fallout Wiki + League of Legends Wiki + Dota 2 Wiki + Dayz Wiki + … you get the point.

      Uncyclopedia was barely a Wikia wiki in the first place - when it was, it used a different skin. It also has very low viewership regardless as the wiki is basically a gimmick.

      Fallout Wiki on Fandom is far more successful than The Vault which moved off-Wikia. If League of Legends Wiki ever split off-Wikia, it didn't work, the Fandom League of Legends Wiki has excellent viewership. Dota 2 Wiki was never part of Fandom to begin with.

      So no, I don't "get your point". Of the wikis that split off of the Wikia host, only WoWpedia and Kingdom Hearts Wiki seemed to have done so successfully. WoWpedia because Blizzard linked to the new host, but even still WoWWiki has its viewership. Kingdom Hearts Wiki because us, the Final Fantasy Wiki - hosted by Fandom still - links to it instead of to the Wikia one.

      Once again you're using the Strawman Fallacy — whenever anyone disagrees with you, you compare their criticism with whining.

      I'm not really interested in debating those who disagree with me. I came here to call out the whining on Central that is completely counterproductive and will not help improve the site at all. I've seen it for the past several years, and I'm aware that my posts here won't change peoples' minds.

        Loading editor
    • If your goal isn’t to change anyone’s mind, but to simply spout your frustrations to the aether, then you might as well talk to a mirror, or perhaps a brick wall, for all the productiveness you’d get from the exercise. Better yet, you could say nothing at all & not waste everyone’s time talking to you when you won’t even consider anyone but yourself. If all you want to do is “call us out” & mock us by talking past us, then why should we give your words any consideration when it isn’t reciprocated in the slightest?

        Loading editor
    • Kevin "Hawk" Fisher wrote:
      After just reading most of this thread for first time, I agree that it did start off with OMG, rage post initially.

      You think that was a rage post? LOL That was more of an acceptance observation based off previous feature releases.

        Loading editor
    • My goal is not to change anyone's mind, because no one's mind can be changed. Everyone is convinced that all CSS is eventually going away, that every wiki in the future will look identical, and that Modernization, Portability or whatever are all part of a conspiracy theory to restrict all forms of customization, Fandom Staff don't care about their users, and the like that I've all heard before. It's all you'll ever find on Central, and it's very tiresome to read.

      If you people think bombarding threads with these conspiracy theories and rage posts will get Fandom Staff to listen to you and cave into your demands, even though it has never once done so any time in the past decade, then by all means keep at it. If you think that running a site like Fandom is so easy and Staff are so stupid that they haven't implemented your obvious solutions, then by all means create your own wikifarm. If not, find constructive ways to make your case that CSS is needed in the top nav.

        Loading editor
    • The question about CSS is: Why not?

      Also, Technobliterator, if you call cogent arguments rage posts and blatant conspiracy theories without any evidence again I'm leaving this thread to you and the rest of the actual rage posters.

      (Yes Fandom Staff doesn't care — that doesn't mean we'll shut up. Has that ever happened in a protest? Actually, give sources this time instead of calling people trolls and whining children.)

      (In addition, when you call one wiki more successful than another actually cite stats and view rates and the like instead of assuming that Fandom Wikis are always more successful unless they barely exist. Also, Unencyclopedia is extremely popular on Fandom — no other wiki has Fandom allowed this level of customisation.)

        Loading editor
    • DEmersonJMFM wrote:
      Kevin "Hawk" Fisher wrote:
      After just reading most of this thread for first time, I agree that it did start off with OMG, rage post initially.
      You think that was a rage post? LOL That was more of an acceptance observation based off previous feature releases.


      Me? Imho, not really or at best mildly. However all beginning posts to start off with includes:

      • "No customization is very unfair." :D
      • "Whatever, I don't care anymore."
      • "*sigh*

      It looks like the ultimate goal is for all wikis to look exactly the same, except for different colours."

      • "I assume it's just a "tough sh!t, deal with it"."

      are all points that one can validly claim as such. Now some are worse than others, but imho, none of that sounds like acceptance either. Observationally, sure.

      *sits on the fence*

        Loading editor
    • SuperRobot9338 wrote: Also, Technobliterator, if you call cogent arguments rage posts and blatant conspiracy theories without any evidence again I'm leaving this thread to you and the rest of the actual rage posters.

      We're discussing great things here that are all constructive for all of us and also for Staff. But, let's stay civilised and focus on the topic rather than on other people's ways of expressing their thoughts and ideas - criticise the thoughts, not the users.

        Loading editor
    • Kevin "Hawk" Fisher wrote:

      • "Whatever, I don't care anymore."
      are all points that one can validly claim as such. Now some are worse than others, but imho, none of that sounds like acceptance either. Observationally, sure.

      This comment was about the crossed out comment, which attributed to a later comment about the unspecified extent of this restriction. Ultimately I accepted that the answer didn't matter anymore for the sake of the conversation (I was, for some reason, under the impression Staff would be answering questions) so days later I edited the post.

      The "No customization is very unfair" comment was off the mark (some kind of customization (CSS/JS) is being allowed but Fandom created some of this drama themselves when they failed to be specific by simply stating "most" and including only one example).

        Loading editor
    • SuperRobot9338 wrote: The question about CSS is: Why not?

      I already answered and gave the same answer Fandom Staff have given before. The response I got was, "I don't trust that answer, why would that turn advertisers off?" Perhaps Fandom Staff can elaborate more on this if you need them to, but in my case, since they're working for a business that has to constantly speak to advertisers daily and I'm not, I'll take their word for it. And since Modernization is all about reducing the number of ads on pages, which I'm all for, I absolutely do not want to obstruct it or slow it down - which many Central users seem keen to do.

      Also, Technobliterator, if you call cogent arguments rage posts and blatant conspiracy theories without any evidence again I'm leaving this thread to you and the rest of the actual rage posters.

      If you think comments such as "I wouldn't be surprised if we eventually lost all CSS because <insert reason here>" is not a conspiracy theory, you are welcome to leave this thread. If Staff hated CSS and customization so much, they could have forced all Portable Infoboxes to use the Europa skin, instead they gave them the option to use CSS through themes. They could have chosen the image in the top nav for each wiki, instead they let us choose our own. They could have forced every wiki's Discussions to use the same set of rules, instead they let us set our own rules.

      Need I go on? Customization is core to giving each wiki its own identity, but the page header is key to making the wikis still feel consistent. Therefore it makes sense for the header to be more limited. However, we can't even have that conversation. Because before users discuss whether they should be able to customize the header, or question why advertisers want the page header to be consistent, they post conspiracy theories and rage posts.

      (Yes Fandom Staff doesn't care — that doesn't mean we'll shut up. Has that ever happened in a protest? Actually, give sources this time instead of calling people trolls and whining children.)

      If Staff didn't care, they wouldn't make this thread and explain why they're limiting navigation below a certain level, because they wouldn't care enough to explain why they're making changes. They also would have forced Message Walls on all wikis, and would have stopped adding features to Portable Infoboxes. To be honest, I don't think they should bother making threads like this. Their users will give them no respect nor time irrespective of what they do, and will just post rage post conspiracy theories.

      (In addition, when you call one wiki more successful than another actually cite stats and view rates and the like instead of assuming that Fandom Wikis are always more successful unless they barely exist. Also, Unencyclopedia is extremely popular on Fandom — no other wiki has Fandom allowed this level of customisation.)

      Google "Fallout 4", or anything Fallout related. You'll notice which wiki always shows up, and which is rarely on the front page. If you still don't believe me, compare this with this.

        Loading editor
    • Kevin "Hawk" Fisher wrote:

      Please spend more time improving the Search engine, which is dreadful and appears to have random sort order results.

      Please spend more time finding a way to incorporate Category pages in the navigation menu much better. Usually, at least most wikis I have visited, wikis have pretty good structure set up with category pages, it is much easier to navigate and find what pages and articles you are wanting, once you are able to find good category page to start with. I am sure some wikis do not have good Category hierarchy set up, but for the many that do this would be beneficial.

      Please spend more time on Help pages, as once you do actually find page you are looking for and wanting to help contribute and add your improvements, is not bad. It is decent start for help pages. However, trying to find specifically what portions you are looking for is not the most intuitive. Worse is the lack of helpful info for those intermediate users. Basic beginner help ... great. Advanced ... pretty much over the top for intermediate. It really needs better help info for those in between. Including a whole list of all options plus better descriptions for each.

      These are all excellent suggestions. However, you should also send them to Special:Contact/feedback and if you want to be really nice, tell us what Fandom staff said in response on a separate thread.

      I especially agree with the need to improve Help pages. I've needed to fix so many and so many more are in bad shape or missing.

      As for "tough sh!t, deal with it", that is more resignation than rage. I've been interacting with Fandom (previously Wikia) staff for 10 years and the previous quote is what I would characterize as a fairly accurate summary of how staff has approached introducing several changes over these many years. I also know some staff very well or better than most. They often get caught up in justifying something because it's their job. The puppet masters above are usually too scared to directly interact with users. You will get to see and talk to some of them if you get to Community Connect, but they still keep their distance.

        Loading editor
    • Fandyllic wrote:

      These are all excellent suggestions. However, you should also send them to Special:Contact/feedback and if you want to be really nice, tell us what Fandom staff said in response on a separate thread.

      Thanks for the link, I will forward as suggested.

      As to your comment, no need to explain to me (kinda figured as much). They were taken out of context anyway, picking the worst parts on purpose to emphasize initial tone of posts from one viewpoint. As I kinda do see point thatTechnobliterator was trying to make ... although also see both sides as well. I actually loved the entire post for 3rd bulleted quote from SuperRobot and enjoyed reading it :D[1]

        Loading editor
    • @Technobliterator

      1. I am completely in support of the other aspects of Wiki Moderisation, and I believe many of the other "conspiracy theorists" here also support them. I just don't see why removing CSS would deter advertisers.
      2. Rage posts? Where? Either way, look around you. Users are doing exactly what you say they aren't — questioning why advertisers would need this and having civil conversations about why keeping the header consistent is all that necessary. Wake up.
      3. If you really hate disagreements with Fandom, you can go live under a rock. Nothing will change either way, so why should we stop? In addition, the only thing they've addressed is ExtendedNavigation, and that argument has been well questioned by Browseitall and Fandyllic if you'd care to look.
      4. That is a good point, but you haven't addressed the rest of the examples I gave.

      Also, addressing your earlier point where you called me a conspiracy theorist for just speculating, remember that was mere speculation and wasn't intended to be an insult to Fandom or a rage post, just an off-hand reflection of my fears in general. The other points by other users have been more pertinent to the present, so unless you address those arguments, you won't convince anyone.

        Loading editor
    • Noreplyz wrote: We're discussing great things here that are all constructive for all of us and also for Staff. But, let's stay civilised and focus on the topic rather than on other people's ways of expressing their thoughts and ideas - criticise the thoughts, not the users.

      Good point — I admit that was overly negative of myself. However, all of us should take a step back and stop calling each other rage posters or conspiracy theorists like some of us have stooped down to.

        Loading editor
    • SuperRobot9338 wrote: @Technobliterator

      1. I am completely in support of the other aspects of Wiki Moderisation, and I believe many of the other "conspiracy theorists" here also support them. I just don't see why removing CSS would deter advertisers.
      2. Rage posts? Where? Either way, look around you. Users are doing exactly what you say they aren't — questioning why advertisers would need this and having civil conversations about why keeping the header consistent is all that necessary. Wake up.
      3. If you really hate disagreements with Fandom, you can go live under a rock. Nothing will change either way, so why should we stop? In addition, the only thing they've addressed is ExtendedNavigation, and that argument has been well questioned by Browseitall and Fandyllic if you'd care to look.
      4. That is a good point, but you haven't addressed the rest of the examples I gave.
      1. It's explained right here. "We need to provide value to advertisers so we can keep our wikis going strongly and continue to make improvements on features and general site performance. Wiki pages have been a challenge because the design hasn’t changed much since 2010 (and in parallel, many low quality ad products have been added), but advertisers’ expectations definitely have changed. Advertisers are now demanding to have their ads associated with a much cleaner, modern look." This is following a three-blog series on how they intend to improve the ad experience. You can question why CSS shouldn't be restricted to prevent users from breaking the "cleaner, modern look" that advertisers demand from sites in the page header, but I have a good idea what answer you'll get.
      2. The vast majority of posts on this thread are rage posts and are absolutely not "civil conversations". It's just, "you're banning customization, what next in this slippery slope, this is a disaster..." My posts may not have been much better, but I deemed the tone of them appropriate given what they were in response to.
      3. I really don't hate disagreements with Fandom, that's the thing. I disagree with Fandom all the time, and have been very vocal when I did. I hate the Central attitude of "dogpile on every thread with cynical rage, insert conspiracy theories about how we're losing customization forever, upvote every comment, then turn around and claim we have 'community support' and demand whatever decision made for the good of the wiki be reversed". It's a petulant attitude. FYI, no, frankly, the counterarguments to that weren't great, "it's more helpful to randoms to limit navigation but less helpful to core users who find the links useful" is meaningless because said "core users" probably amount to about a percentage of users or less, and it has been explained several times that Modernization is about making the wiki more appealing to the broader public.
      4. Assuming you're referring to the other wikis when you say "examples", try the same exercise with them and you will find the same results - except for wikis that were never part of Wikia to begin with (Dota 2 wiki).

      Also, addressing your earlier point where you called me a conspiracy theorist for just speculating, remember that was mere speculation and wasn't intended to be an insult to Fandom or a rage post, just an off-hand reflection of my fears in general.

      There's offhand reflection of fears about trends you're noticing in recent updates, such as:

      As Fandom moves towards becoming a centralised, corporate, and bland site more like Facebook, and less a mosaic of vibrant and dedicated communities passionate about their content, I fear the worst for Wikias. No longer is this website hosting myriad sites, each a self-dependent community about their topic, but rather simply a giant megacorporation that believes a wiki about Sushi should always look and feel just like a wiki about Runescape, and that it should be indistinct from anything else.

      and outright conspiracy theories, like:

      It looks like the ultimate goal is for all wikis to look exactly the same, except for different colours.

      Note the key difference. In your first post, you express a concern - one I would argue is completely unfounded and still a silly concern to bring up in response to "hey look, here's a new header, you can add your image in it now, you just can't break it with JS or CSS", but you highlighted a trend and why you feared it. In your second, you made baseless predictions about the future.

      Also, even if you hadn't made said concerns. Why do you think posting "all wikis are becoming the same corporate trash, they will soon look identical, Staff doesn't care about us" is likely to convince anyone at Fandom? Do you expect them to read your posts and go "welp, he got us! He caught our evil plot! Guess we better reverse everything now and give them more CSS tools..." Have you ever been sympathetic when a user, or a group of users, on your wiki argue that the admins "don't care about the users" and then try and tell other users to not listen to the admins, perhaps telling them to vandalise pages?

        Loading editor
    • Noreplyz
      Noreplyz removed this reply because:
      Off topic
      22:32, June 1, 2017
      This reply has been removed
    • I'm just hoping we at least will be able to change the font on it. I fear for what's next because of this idea of "Ensuring a consistent experience across FANDOM". I understand not allowing JS to a extent, but not allowing CSS is overkill. Holding my breath to see what happens, hoping for the best. I love this new nav bar, it's modern and looks great. Also generally speaking I have been a fan of all of the new ideas coming from FANDOM (discussions and wiki modernization). But at the end of the day, Admins want more customization, not less. (Plus, I don't think Admins being allowed to fully customize the nav bar will effect your ad revenue, just saying.) :)

        Loading editor
    • Here is my question. Does it really matter how well integrated an ad is if no one visits the site?

      I think the argument most people here are trying to make is that customization is one of the main attractions of using Fandom. By removing it (intentional or not, this has been gradually happening with each "new"/"modernized" feature), Fandom is decreasing the motivation to use their sites. This is an issue as it is generally accepted that higher usage equates to higher quality information and thus higher viewership. The latter advertisers really care about.

      What constitutes a balance is difficult to say, but I think it is somewhat clear that most people on this thread simply think that restricting CSS, depending on how it is done, is going too far.

        Loading editor
    • This is disappointing. I recently created my wiki back in February, and I have been steadily updating it, and I finally have found a suitable navbar that I think adds to the wiki's design and theme, and now it's going to be removed. Customazation doesn't make wikis seperated, it makes all wikis unique and refreshing. Should all movies have the same actors? All songs have the same beat? I know so many people keep saying this, but, truthfully, it will never go old.

        Loading editor
    • I can still do some css and js changes to the new ones. But onto my personal css files instead of the Community Wikia CSS. So I still like it as long as the color of navbar can be different from the color of the buttons.

        Loading editor
    • Personally you can edit whatever you feel like editing.

        Loading editor
    • DEmersonJMFM wrote:
      Personally you can edit whatever you feel like editing.

      So in this wiki, I made the new navbar a bit roundy for me

        Loading editor
    • That's cool and all, but it's only in personal CSS :/

        Loading editor
    • HM100 wrote:
      DEmersonJMFM wrote:
      Personally you can edit whatever you feel like editing.
      So in this wiki, I made the new navbar a bit roundy for me

      Can you show us?

        Loading editor
    • JustLeafy wrote:

      HM100 wrote:
      DEmersonJMFM wrote:
      Personally you can edit whatever you feel like editing.
      So in this wiki, I made the new navbar a bit roundy for me

      Can you show us?

      Disney Wiki New Navbar customized by HM100 using his personal css

        Loading editor
    • HM100 wrote:

      JustLeafy wrote:

      HM100 wrote:
      DEmersonJMFM wrote:
      Personally you can edit whatever you feel like editing.
      So in this wiki, I made the new navbar a bit roundy for me

      Can you show us?

      Disney Wiki New Navbar customized by HM100 using his personal css

      Cool.

        Loading editor
    • JustLeafy wrote:

      HM100 wrote:

      JustLeafy wrote:

      HM100 wrote:
      DEmersonJMFM wrote:
      Personally you can edit whatever you feel like editing.
      So in this wiki, I made the new navbar a bit roundy for me
      Can you show us?
      Disney Wiki New Navbar customized by HM100 using his personal css
      Cool.

      TY

        Loading editor
    • Well, like it or not, the new header is supposed to start rolling out soon.

        Loading editor
    • HM100 wrote:

      DEmersonJMFM wrote:
      Personally you can edit whatever you feel like editing.

      So in this wiki, I made the new navbar a bit roundy for me

      Nice!

        Loading editor
    • Brandon Rhea wrote:

      Too much choice is a bad thing in the user experience design world because it leads to what's known as decision paralysis. This means there's so much over-analysis of what to do that visitors find it difficult to decide what to navigate to. Once a user reaches this point, they get frustrated and leave with a bad taste in their mouth, making them unlikely to return to your wiki and instead find answers elsewhere.

      Unfortunately, everybody wants to pretend they're a novelist these days, rather than keeping information brief and to the point. This often goes hand-in-hand with the creation of 5 million trivial categories, half of which contain only a couple of articles.

        Loading editor
    • Can communities alter the nav drop-down menu color and text color/styling?

        Loading editor
    • LordTBT wrote:
      Can communities alter the nav drop-down menu color and text color/styling?

      Not directly. I've heard that the colors are automatically picked based off the main color of the theme designer. You can end up with some strange color choices.

        Loading editor
    • You can see us loving it here;
      http://payday.wikia.com/wiki/Thread:63301

      We really used threading to make navigation easy, but hey, feel free to suggest us how to make it easier to look up stuff on the navbar, go ahead.

      Because as of now, most shit just got cut out and the navbar is pretty useless;
      http://payday.wikia.com/wiki/MediaWiki:Wiki-navigation?curid=2064&diff=154576&oldid=154481

      Oh, and still using a custom .css because fuck if I'm going to use this shitty mobile view on my PC. Why does every update needs to make your site more crap. Can't you guys improve rather than deprove something for a change? Seriously. Atleast it's not as horrid as you guys screwing up diff's last time.

        Loading editor
    • my navbar ended up with a white color which basically screwed up my whole design because my wordmark is white, but I changed it and it looks okay now. I think I need to change the whole navbar though because it looks bad.

        Loading editor
    • Please, would it be possible to add about 500 ms delay before the dropdown menu is shown?

      Thank You.

        Loading editor
    • Like I said in my comment on the blog, it would've been much better to just not mess with this (y'know not fix what isn't broken) and work on stuff that actually needs fixing or modifying.

        Loading editor
    • We noticed a few issues with the new menus on the rr3.wikia:

      1. Clock: The clock has disappeared.
        1. The clock is very useful for coordinating the start time of events. Often an event would be quoted as 'starting 00:00 this website clock' to coordinating a start time world wide.
        2. It also had a purge function, clicking the clock would ?action=purge the page, useful, when making design changes.
      2. Italics in Page Title: The DISPLAYTITLE template no longer works. We often use the template to display repeated events, with the version in italics, e.g. {{DISPLAYTITLE:Retro Rivals ''(v5.3.0)''}}, then link to a disambiguation page, or previous version.

      Can these be looked at and advise how we switch the options back on.

      RR3 Michael P (talk) 06:21, June 14, 2017 (UTC)

        Loading editor
    • Technobliterator wrote:
      This has been explained before - the new page headers are supposed to be consistent across the entire site, same with the very top bar and the footer. This helps users move across the different wikis as they become a much more familiar experience to them, and more important, prevents certain wikis from adding bloated CSS that makes the header appear unreadable. Some wikis make decent use of CSS, but others just add fancy fonts and gradients just "because they can" and ruin it, which drives readers away.

      Everything else can still use CSS, and even the top header still allows you to add a picture - so for those who aren't CSS savvy, it's technically more customizable than before. Also, the design of the top nav, which most people agree is infinitely better than the old one, is what most customized top navs looked like anyway. So it's not like this is some evil plot to take away customization from the entire wiki, it's literally just for the page header.

      I would agree IF the end results in consistency. Being able to now see this new release, I foresee this will be less consistent across wiki's in key areas that are important resulting in discouraging visitors from actually contributing to wiki's.

      Wiki Activity which used to be seen in first menu, and which most admins etc believed was good location for it, has now been moved. It gave priority to that topic drawing first attention to its visitors and hopefully encouraging them to actively participate. This is simple matter and some have already moved it back. However the end result I am guessing is that a lot will have moved it back there, yet not all will. End result less consistent.

      Other such basic ways to contribute such as uploading Images, Videos is no longer easy to find. Another way to actively encourage visitors to contribute. Can visitors still upload, sure but they will need to know differing ways how, which once again detracts from encouraging basic visitors from doing such. Which once again now means wiki's will have to find alternative and creative ways of incorporating these links back.  I can almost gaurantee, end result will be less consistent.

      Talk page used to be easily seen, when you could see a number indicating that users were having a discussion, this once again potentially encourages visitors to actively be involved. But not anymore, it is now hidden behind the edit button and will only encourage active contributors and not inactive ones. Even than an active contributor must actually look to see if is such talk. I can once again see wiki's attempting to find alternative ways around this. Leading to inconsistency.

      So I must ask how is the design of new nav bar considered by most to be better? I can agree that the appearance will now make all wiki's instantly more recognizable, but the actual function (imho most important aspect of drawing visitors) will be less recognizable. Is it good to have the 'less is more' so as to not overwhelm visitors? Sure it is, but ONLY if it is done well. Sorry to say, but Fandom has not done this well at all. Their given KISS method is great, but Fandom has taken it too far. Of course you dont need to see every topic and option .. but you really do need to see some of the important ones. Ones that will hopefully encourage visitors to contribute. Making wiki names redundant now, is also not what I see as keeping it simple. Sure some wiki's did not have it in their wordmark image while most others did which was not consistent before. However, this will not change that. Some will now be like OP shows (Wiki name being listed twice), others will change text to something else, while those that didnt have name in wordmark can still choose to leave it like default or change it to say something else. In other words keeping it simple failed to work in this regard of keeping them consistent. Of course allowing more options obviously doesnt either though.

        Loading editor
    • I think it is time the staff start responding to our criticism instead of staying silent under the pretense of "There's always going to be objection." don't you think?

        Loading editor
    • RR3 Michael P wrote:
      We noticed a few issues with the new menus on the rr3.wikia:
      1. Clock: The clock has disappeared.
      2. Italics in Page Title: The DISPLAYTITLE template no longer works.

      The clock (DisplayClock) is no longer allowed site-wide. You can add it in your personal JS by updating the script name to UTCClock. You can also look into c:dev:CodeLoad, which can make it easier for users to use the script themselves.

      The italics issue was brought up earlier (don't remember exactly where), but a Staff member said they would look into the issue and hopefully get a fix soon.

        Loading editor
    • Nothing should be limited. Ever. All codes should be allowed site wide.

        Loading editor
    • Alissa the Wise Wolf wrote:
      Nothing should be limited. Ever. All codes should be allowed site wide.

      While I like customization and individuality, this idea would be a nightmare.

        Loading editor
    • DEmersonJMFM wrote:
      Alissa the Wise Wolf wrote:
      Nothing should be limited. Ever. All codes should be allowed site wide.
      While I like customization and individuality, this idea would be a nightmare.


      Who cares. More customization is better regardless.

        Loading editor
    • DEmersonJMFM wrote:

      Alissa the Wise Wolf wrote:
      Nothing should be limited. Ever. All codes should be allowed site wide.

      While I like customization and individuality, this idea would be a nightmare.

      Yeah. It's like everybody owning admin powers.

        Loading editor
    • JustLeafy wrote:

      DEmersonJMFM wrote:

      Alissa the Wise Wolf wrote:
      Nothing should be limited. Ever. All codes should be allowed site wide.
      While I like customization and individuality, this idea would be a nightmare.
      Yeah. It's like everybody owning admin powers.


      This is objectively incorrect, as only admins can customize the wiki.

        Loading editor
    • Alissa the Wise Wolf wrote:

      JustLeafy wrote:

      DEmersonJMFM wrote:

      Alissa the Wise Wolf wrote:
      Nothing should be limited. Ever. All codes should be allowed site wide.
      While I like customization and individuality, this idea would be a nightmare.
      Yeah. It's like everybody owning admin powers.


      This is objectively incorrect, as only admins can customize the wiki.

      Yeah, but... I meant all customizations being site-wide is as bad as giving admin powers to everybody. Hopefully I clarified what I said to you.

        Loading editor
    • JustLeafy wrote:

      Alissa the Wise Wolf wrote:


      JustLeafy wrote:

      DEmersonJMFM wrote:


      Alissa the Wise Wolf wrote:
      Nothing should be limited. Ever. All codes should be allowed site wide.
      While I like customization and individuality, this idea would be a nightmare.
      Yeah. It's like everybody owning admin powers.

      This is objectively incorrect, as only admins can customize the wiki.
      Yeah, but... I meant all customizations being site-wide is as bad as giving admin powers to everybody. Hopefully I clarified what I said to you.


      That really just depends on the Admin on whether or not it's actually a bad idea., a variable too broad regardless of the situation.

        Loading editor
    • DEmersonJMFM wrote:

      LordTBT wrote:
      Can communities alter the nav drop-down menu color and text color/styling?

      Not directly. I've heard that the colors are automatically picked based off the main color of the theme designer. You can end up with some strange color choices.

      What do you mean "Not directly"? Does that mean we can do it via CSS? I'm happy to do it that way...

        Loading editor
    • No, you can't do it by CSS, but you can alter the drop-down by changing the colours of other elements.

        Loading editor
    • SuperRobot9338 wrote: No, you can't do it by CSS, but you can alter the drop-down by changing the colours of other elements.

      Because the CSS doesn't exist, or because it's "not allowed"? I'd just prefer to change the drop-down from white to the same color as the nav itself.

        Loading editor
    • LordTBT wrote:
      Because the CSS doesn't exist, or because it's "not allowed"? I'd just prefer to change the drop-down from white to the same color as the nav itself.

      CSS isn't allowed, so you can't match the colors wiki-wide.

        Loading editor
    • LordTBT wrote:

      SuperRobot9338 wrote: No, you can't do it by CSS, but you can alter the drop-down by changing the colours of other elements.

      Because the CSS doesn't exist, or because it's "not allowed"? I'd just prefer to change the drop-down from white to the same color as the nav itself.


      CSS isn't allowed for the navbar anymore, which I don't understand. CSS made the navbars unique.

        Loading editor
    • Fashionista101 wrote:

      ...which I don't understand...

      Not many people understand outside Fandom staff. Restricting functional changes like JS expansion or strange animation makes sense, but completely restricting changes in look and style doesn't. Fandom is trying to use UX (user experience) reasoning that is flawed. No one really actually scientifically studies UX or UI efficiency anymore so anyone can pull up any BS article full of opinions and say that justifies something.

      In the good 'ol days, Apple used to run an extensive UI/UX testing lab for their devs which was the foundation of their ease of use. You can tell they stopped doing it, since their new UIs make people want to barf before they figure out the new unintuitive garbage. Android isn't any better, but they don't have a precedent to worry about.

        Loading editor
    • Wikia Fandom FANDOM doesn't want to risk inconsistency, so they severely limited customisation.

        Loading editor
    • "We've opted to disallow this type of customization not only to ensure design consistency across Fandom but also because of the simple fact that it's a bad design practice and hinders the user experience. "

      Ugh. We've opted to ignore the users' wishes because we know better. Taking out one of my favorite ways to get places just makes it... well, more of a pain in the ass to get places. Now navigation isn't easier, it just stops me from optionally going deeper, so I have to stop by more intermediate pages.

        Loading editor
    • Like somebody above said, it's now harder to find things like "videos" and "wiki activity". I just had to redo my whole navigation bar because it looked terrible. It still looks...meh. And I think the new navbar looks kinda boring. 

        Loading editor
    • I don't even know where to find upload video's or pictures now. Had to use MutlipleUpload for a single file :/

        Loading editor
    • Hassat Hunter wrote:
      I don't even know where to find upload video's or pictures now. Had to use MutlipleUpload for a single file :/

      Click on "Videos" or "Images" and the option is right there on the right. You can also add the options to your Toolbar if you want.

        Loading editor
    • Providing more links actually makes things more difficult for your visitors.

      Too much choice is a bad thing in the user experience design world because it leads to what's known as decision paralysis. This means there's so much over-analysis of what to do that visitors find it difficult to decide what to navigate to. Once a user reaches this point, they get frustrated and leave with a bad taste in their mouth, making them unlikely to return to your wiki and instead find answers elsewhere.

      So what makes a great menu navigation? How should you handle your complex wiki structure with thousands of pages? And why should you limit your navigational links? Here are a few articles answering these very questions, which we think are helpful to understanding the reasons why we do not want fourth and fifth level options:


      I think that your research on hierarchical navigation may be incomplete. Also, your conclusions might be based on a misreading of the sources cited above.

      Usually, users can complete tasks more quickly and accurately when using a broad and shallow hierarchy than when using a narrow and deep hierarchy. But that's more of a general trend than an absolute rule. As Kathryn Whitenton at Nielson Norman pointed out,

      Should your website's hierarchy be flat or deep? Like most design questions, there's no single right answer, and going too far to either extreme will backfire. Flat hierarchies tend to work well if you have distinct, recognizable categories, because people don't have to click through as many levels.

      But there are exceptions to every rule. In some situations, there are simply too many categories to show them all at one level. In other cases, showing specific topics too soon will just confuse your audience, and users will understand your offerings much better if you include some intermediate category pages to establish context.

      Miller and Remington (2002) found that users completed tasks more quickly and accurately when using a three-level hierarchy than when using a two-level hierarchy, but only when the hierarchy's labels were clear and easy to understand.

      Three-level hierarchies do not always work better than four- or five-level hierarchies. The contents of the website must also be taken into account.

      Furthermore, it's a fallacy to conclude that simple hierarchies present the user with fewer choices than complex hierarchies. Simple hierarchies have fewer choices *in the hierarchy itself*, but the choices that are offloaded from the global navigation still have to go somewhere. They are usually placed in individual web pages. These pages are either "navigation" pages that were added in order to complete the global navigation; or they are large, complex pages that were formed by merging the contents of smaller pages. Both approaches are just as likely, if not more likely, to overwhelm the user than a global navigation structure that is four or five levels deep.

      On my own wiki, thelastdoor, four hierarchical levels are ideal. The first hierarchical level is The Last Door itself. The second level is Chapters (as opposed to Characters, Locations, etc.) The third level is Seasons and the fourth level is Episodes. Now that the global navigation has been restricted to three hierarchical levels, the user cannot navigate directly to a desired episode. Instead, they must navigate to a "Season" page and then navigate again to an "Episode" page. (I should point out that each season only has 5-8 episodes.)

      I respectfully suggest that wikis be given the option to use 4 or 5 hierarchical levels.

      Sources

      • Miller, C. S., & Remington, R. W. (2002). Effects of structure and label ambiguity on information navigation. In CHI ’02 extended abstracts on Human factors in computing systems (pp. 630–631). Minneapolis, Minnesota, USA: ACM.
        Loading editor
    • Excellent analysis. As usual, a blunt instrument was used pretending to be needle-nose pliers.

        Loading editor
    • Why do all wikia's need to be the same? If they cover different topics surely they should be allowed to differentiate from eachother design-wise?

        Loading editor
    • I personally don't think linking episodes in the navigation would make four levels ideal if it's the lowest common denominator of media content. That isn't a perfectly clear hierarchy if the labels are the episode titles, or of high utility if the article names are the episode numbers. The links are also unlikely to get much traffic - behaviourally, people might want to see the finales and the season debuts specifically, but browse by category or list otherwise.

      As a reader, I would probably head to an "episode guide", series article or "Season 1" page to try and get a wider view of the series. Failing that, I would search for a wide-scope media article, season article or episode list. I like to make informed choices about my browsing, so that I benefit from the wiki's content more. Finding a fully specific drill-down aspect of the series in each navigation is somewhat arbitrary when that functionality can be achieved with search or intermediary articles when context is missing.

      While the original post lacks detail on what UX changes only having three levels would cause, I wouldn't agree that the choice of limiting those and using portals is going to overwhelm the user. Insights offers a perspective into what articles are most popular - the lists and portals big wikis use are consistently high-traffic because they are versatile, media-rich and they define the relationship between different levels in the hierarchy. They also bring in pageviews.

      EDIT: An important SEO and UX consideration is the content-link balance of a wiki. Balancing that out makes those aspects of the wiki hierarchy clearer.

        Loading editor
    • Yes. Lists and portals have been consistently high-traffic and rich in information, so they're not so bad. Fandom was certainly a bit too broad in its one-size-fits-all approach to header customisation, though. I would prefer if the Theme Designer had a few more options, like changing the header background blending or the dropdown menu colours, and certain scripts were approved by Fandom to be used in header navs.

        Loading editor
    • "We've opted to disallow this type of customization not only to ensure design consistency across Fandom but also because of the simple fact that it's a bad design practice and hinders the user experience. "

      I am dying to know how much a PR firm was paid to come up with that sentence.

        Loading editor
    • Hey now, we all know proper navigational tools are "a bad design practice", probably also the reason Fandom search works like crap (just search it for yourself, KISS).

      Personally, on the Wikia I frequent, the topbar just became completely useless.
      I long for the days I don't have to wake up and find another horrid Wikia change that needs it's users to fix it up for them. Still needing to use a widescreen .css to not get completely nauseous browsing Wikia.

        Loading editor
    • Speedit wrote:
      As a reader, I would probably head to an "episode guide", series article or "Season 1" page to try and get a wider view of the series. Failing that, I would search for a wide-scope media article, season article or episode list. I like to make informed choices about my browsing, so that I benefit from the wiki's content more. Finding a fully specific drill-down aspect of the series in each navigation is somewhat arbitrary when that functionality can be achieved with search or intermediary articles when context is missing.


      Thanks for the response. Just to clarify, The Last Door is a series of computer games. Each episode of the series is a different game. Sometimes, a user will want to browse an episode guide, but usually they want to navigate directly to the game that they’re currently playing. Articles about individual episodes often get the most traffic on the wiki. Because there are sixteen episodes, the list of episodes has to be subdivided on the menu, which results in four hierarchical levels.

        Loading editor
    • Ah! Now that makes sense, cause I was thinking the same as Speedit.

        Loading editor
    • That specific scenario makes a lot more sense now.

        Loading editor
    • Customisation should be down to Wiki Administation, not people from Wikia who have never even seen the wiki. This is very unfair and the headers look downright awful a lot of the time.

        Loading editor
    • Andrewds1021 wrote: Not to mention that all these new changes are very broken in IE and Edge. I know they are not supported browsers but I seriously wonder how great the page design can be if it only works on two browsers; and requires them to be the most recent versions at that.

      When it was rolled out on Tuesday (EDT), this was still an issue. However, I am pleasantly surprised to find that this particular issue now appears to be fixed; at least for the new header.

        Loading editor
    • We should have freedom to scale and move around the header image and not be hindered by those awful gradients and mandatory "site name" text.

        Loading editor
    • FortressMaximus
      FortressMaximus removed this reply because:
      00:44, June 16, 2017
      This reply has been removed
    • FortressMaximus
      FortressMaximus removed this reply because:
      00:45, June 16, 2017
      This reply has been removed
    • You didn't think implementing the header image through at all, what's the point of the image if its going to be hidden by buttons, text and a mandatory gradient you can't control the transparency of? Here are some ways you can improve the theme designer if you want to make it easier for people who don't know css (that being said, removing custom css for the header is, as many have said, a really bad idea).

      • Make the site name text optional since most wikis have it in the wordmark anyway.
      • Add a slider to change the transparency of the header background color just like the main content background instead of a gradient covering the image.
      • More freedom for the header background (taking into consideration it is supposed to be responsive)
        • Give the option to have a solid repeated background image that will work regardless of width.
        • Different backgrounds for different widths (from what I've seen, at least three options)
        • The ability to anchor a background image x units from the left, right or center etc.
        • With all of this in mind, the background image file should be allowed to have any dimensons so long as it is within the the bounds of the header image dimensions when viewed on a maximized window at 100% zoom.
        Loading editor
    • The second is editable in the Theme Designer as the community text, but the first isn't doable. Theme Designer would sure benefit from more options.

        Loading editor
    • Speedit wrote:
      The second is editable in the Theme Designer as the community text, but the first isn't doable. Theme Designer would sure benefit from more options.

      Currently, we are mandated to have an opaque color background and if one has an image for the header background it will be covered by a gradient of said color. The only choice is which color, but it must be opaque and present. The gradient should be removed entirely and admins that want it on their wikis they can just overlay it in their image editor.

      As for the community text, we're forced to have something there. We are not allowed blank characters or nothingness and I saw many wikis that have their name in their watermark end up with redundant text next to it when the change suddenly happened.

      Also, some old wiki names reappeared because it was using the same data as the placeholder for the wordmark. (that is, when you first create a wiki, it doesn't have a wordmark but the name of your wiki in text, those who replaced it with an image might've thought the text would be gone but they've come back.

        Loading editor
    • Yeah I don't mind the gradient, but I don't like how the color is also overlaid on the header image. The buttons are annoying too, my header image has two characters in it and one's face is covered by the "create a page" button, it looks kinda silly.

        Loading editor
    • JoshuaJSlone wrote: Now navigation isn't easier, it just stops me from optionally going deeper, so I have to stop by more intermediate pages.

      I guess something I failed to take into account is that from the point of view of people selling advertising this is a feature rather than a bug. Slideshow mentality.

        Loading editor
    • Technobliterator wrote:

      Everything else can still use CSS, and even the top header still allows you to add a picture - so for those who aren't CSS savvy, it's technically more customizable than before. Also, the design of the top nav, which most people agree is infinitely better than the old one, is what most customized top navs looked like anyway. So it's not like this is some evil plot to take away customization from the entire wiki, it's literally just for the page header.

      The only new significant changes we can make is what the color is (which we could do already except now it takes up the entirety of the header instead of the just the menu) and the text, which used to be a wordmark placeholder. The image is barely visible, what kind of customization is that?

      It's not what "what most customized top navs looked like" at all.

      If FANDOM want to enforce a consistent header layout across all wikis, they have to do better than an image one even can't see clearly because its covered by buttons, a gradient and probably redundant text.

        Loading editor
    • So is there anything that can ben done with community CSS?

        Loading editor
    • Can the links at the top-left of the pages been removed please? we already have the category links below the articles

        Loading editor
    • ΜΖD wrote:

      adding a border to the header

      Yet another thing they didn't plan out. The main content background is more customizable than the header now (borders, transparency).

        Loading editor
    • Andrewds1021 wrote:
      So is there anything that can ben done with community CSS?

      Nothing.

        Loading editor
    • Andrewds1021 wrote: So is there anything that can ben done with community CSS?

      Only more edit tools and icons near the interlanguage menu can be added with JS. Nothing with CSS, unfortunately.

        Loading editor
    • JustLeafy wrote:

      Andrewds1021 wrote: So is there anything that can ben done with community CSS?

      Only more edit tools and icons near the interlanguage menu can be added with JS. Nothing with CSS, unfortunately.

      But some wikis has done it even if it is prohibited. However, this can be allowed as personl basis only. My test stuff for making the new header look like old ones but with new style on this wiki that has no site glow is a success too. See my personal wikia.css if you wish to give it a try.

        Loading editor
    • HM100 wrote:

      JustLeafy wrote:

      Andrewds1021 wrote: So is there anything that can ben done with community CSS?

      Only more edit tools and icons near the interlanguage menu can be added with JS. Nothing with CSS, unfortunately.

      But some wikis has done it even if it is prohibited. However, this can be allowed as personl basis only. My test stuff for making the new header look like old ones but with new style on this wiki that has no site glow is a success too. See my personal wikia.css if you wish to give it a try.

      I'd rather view a screenshot of how the headers currently look in your screen.

        Loading editor
    • JustLeafy wrote:

      HM100 wrote:

      JustLeafy wrote:

      Andrewds1021 wrote: So is there anything that can ben done with community CSS?

      Only more edit tools and icons near the interlanguage menu can be added with JS. Nothing with CSS, unfortunately.
      But some wikis has done it even if it is prohibited. However, this can be allowed as personl basis only. My test stuff for making the new header look like old ones but with new style on this wiki that has no site glow is a success too. See my personal wikia.css if you wish to give it a try.
      I'd rather view a screenshot of how the headers currently look in your screen.

      Magnificant Page header design by HM100

        Loading editor
    • HM100 wrote:

      JustLeafy wrote:

      HM100 wrote:

      JustLeafy wrote:

      Andrewds1021 wrote: So is there anything that can ben done with community CSS?

      Only more edit tools and icons near the interlanguage menu can be added with JS. Nothing with CSS, unfortunately.
      But some wikis has done it even if it is prohibited. However, this can be allowed as personl basis only. My test stuff for making the new header look like old ones but with new style on this wiki that has no site glow is a success too. See my personal wikia.css if you wish to give it a try.
      I'd rather view a screenshot of how the headers currently look in your screen.

      Magnificant Page header design by HM100

      Cool.

        Loading editor
    • JustLeafy wrote:

      HM100 wrote:

      JustLeafy wrote:

      HM100 wrote:


      JustLeafy wrote:

      Andrewds1021 wrote: So is there anything that can ben done with community CSS?

      Only more edit tools and icons near the interlanguage menu can be added with JS. Nothing with CSS, unfortunately.
      But some wikis has done it even if it is prohibited. However, this can be allowed as personl basis only. My test stuff for making the new header look like old ones but with new style on this wiki that has no site glow is a success too. See my personal wikia.css if you wish to give it a try.
      I'd rather view a screenshot of how the headers currently look in your screen.
      Magnificant Page header design by HM100
      Cool.

      Only thing I need to issue is the wds buttons which can make even more beatiful if I do this.

        Loading editor
    • TheWearyandHeavyLaden wrote:
      I'm glad Wikia is gonna make our Wikis look a little cleaner

      If they want it clean they should just kept the community name as the default version wiki-wordmark and not 100% absolutely redudant text next to the wordmark.

        Loading editor
    • And apparently there are some length issues as well. For example, w:c:mondaiji.

        Loading editor
    • Can the edit button go back to the left please?

      I'm logging myself out almost every time i want to edit :(

        Loading editor
    • Wow! awesome.this is very active

      Thanks

        Loading editor
    • The theme designer must be improved.

        Loading editor
    • FortressMaximus wrote:
      The theme designer must be improved.

      Suggest them using S:C and staff may implement them.

        Loading editor
    • HM100 wrote:

      FortressMaximus wrote:
      The theme designer must be improved.

      Suggest them using S:C and staff may implement them.

      They won't without specifics.

        Loading editor
    • Oh god. What is wrong with Wikia these days with their no-consensus force-feeding of feature-depletion?

        Loading editor
    • Not to exacerbate the necro-posting, but when was Fandom/Wikia that much different?

        Loading editor
    • Ever since my first time in 2014, things were much different. The first dislikable change I faced in Wikia is the cramming of space and enlarging every single text, making it bad for desktop people in large screens like Macintoshes. And I had to use CSS to change my interface. But with the constant changes, there were so many changes at such rapid and unexpected pace that my CSS got outdated to the current features very quickly, causing a whole lot of annoying glitches.

        Loading editor
    • Qwertyxp2000 the second wrote: Ever since my first time in 2014, things were much different. The first dislikable change I faced in Wikia is the cramming of space and enlarging every single text, making it bad for desktop people in large screens like Macintoshes. And I had to use CSS to change my interface. But with the constant changes, there were so many changes at such rapid and unexpected pace that my CSS got outdated to the current features very quickly, causing a whole lot of annoying glitches.

      Well, the thing is, you now have to manually update your CSS in order to do so.

        Loading editor
    • What do you mean by "the enlarging of every single text"? As far as I can tell, the text size for main content has changed very little if at all since I joined late 2013.

        Loading editor
    • Andrewds1021 wrote: What do you mean by "the enlarging of every single text"? As far as I can tell, the text size for main content has changed very little if at all since I joined late 2013.

      The default font size is now larger. Try using my personal CSS onto a large-screen computer like a Macintosh and you'll see the changes.

        Loading editor
    • Is it possible the font size changes you at seeing came from the @media portions? I just checked all the CSS associated with your reply and the default CSS sizes applied in my browser are not larger (in fact, some are smaller) than what you have in your CSS; and most of it is without @media.

      What I get from Wikia (not necessarily in order):

      @media only screen and (max-width:1595px) {
          .WikiaPage .WikiaArticle li {
              line-height: inherit;
          }
       
          .WikiaPage .WikiaArticle {
              font-size: 14px;
              line-height: 22px;
          }
      }
       
      .WikiaArticle li {
          line-height: 20px;
      }
       
      .WikiaArticle,
      .wikia-infobox {
          font-size: 13px;
          line-height: 21px;
      }
       
      body {
          font-size: 12px;
      }

      What I see on yours:

      @media only screen and (max-width:1576px) {
          .WikiaPage .WikiaArticle li {
              line-height: inherit;
          }
       
          .WikiaPage .WikiaArticle {
              font-size: 14px;
              line-height: 22px;
          }
      }
       
      .WikiaArticle li {
          line-height: 22px;
      }
       
      .WikiaArticle {
          font-size: 14px;
          line-height: 22px;
      }
        Loading editor
    • Hmm... Hard to say what exact changes are right, because CSS appearance varies from computer to computer.

        Loading editor
    • Yes I'm right

        Loading editor
    • PictureField55 wrote: Yes I'm right

      Right about CSS varying from computer to computer?

        Loading editor
    • Qwertyxp2000 the second wrote:

      PictureField55 wrote: Yes I'm right

      Right about CSS varying from computer to computer?

      Yes

        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message