FANDOM



  • February 16 update: this test is being retired - see this post for more info!

    Hey Community!

    One of our current projects is to look into updating the page header area - that is, the area which currently contains the wordmark, local navigation and contribute button.

    Page header - current

    Page header area highlighted

    We want to make sure the page header area is as useful as it can be - both for the newbie who has never visited your wiki before and for the experienced editors. We're also keen on making the mobile and desktop experience feel a bit more connected.

    We know that changes can make people nervous, but we want to reach out about our ideas early to foster transparency and allow for lots of feedback early in the process. The possible updates are in flux - the outcome significantly depends a lot on research, tests, and the feedback we receive from you.

    Please feel free to ask many questions. We may not have immediate answers since the project is still at an early stage, but the fact that you asked us the question is just as important and useful to us.

    Our findings

    Our first step was to seek a better understanding of how readers interact with the page header. To do this we analyzed usage data of the current page header (see slides 8-15 of this slideshow for data & light analysis) and we performed in-person interviews with people who have never visited our website before. Here is a very brief summary of those interviews:

    • When instructed to move from one page to another (e.g. Luke Skywalker to Chewbacca) nearly everyone's first instinct was to look for a blue link inside the article. If they could not easily find a link they would go to either the browser search bar to search google or the search icon in the global nav.
    • Overall, people understood the local nav but their actual usable behavior showed it wasn't the most important feature, relative to search and in-article links.
    • None of the six participants fully understood the Fandom // Community // Article information architecture.

    We also looked at how logged-in contributors use the page header, and how they have been customized across the site. Data is available in the link above, and in our video conference interviews we learned that admins are open to changes of the page header area, assuming they have an opportunity to provide feedback on designs and have the ability to customize whatever our final design is. Your feedback will be valuable as we understand what does and doesn't work in this design and what needs to be customizable.

    The second major phase of this project was to run some A/B experiments to see how readers react to different changes. We ran five experiments — one replaces the local nav with a search bar, one moved or removed the 'On the Wiki' tab, one introduced a new CSS style, one introduced a 'scroll to top' feature, and the fifth experiment hid the nav entirely. You can view screenshots of the tests at this link and the data from the tests on this spreadsheet. Here's a brief summary:

    • Moving the 'On the Wiki' tab for anonymous users may result in a minor increase in page header engagement. (We feel there is little harm in making this a permanent change so this change has been made on all communities on December 1.)
    • The 'new' CSS nav may result in a minor increase in page header engagement, showing a new design may result in more pageviews.
    • Relocating search to the local nav area may result in more searches. This idea will be explored further.
    • Hiding the nav entirely decreases reader Pageviews/Session.
    • The 'scroll to top' feature did not significantly change Pageviews/Session or Page Header engagement

    A test concept

    As a result of this research, we've come up with a potential concept for how the page header could look:

    Though the layout is somewhat different, it retains much of the existing content - the wordmark, navigation and contribution options.

    We think placing the wordmark top and center will help emphasise your wiki's identity, while the reorganised links should make it easier for a newbie to get to know your wiki. In particular, while the main links are hidden initially, you can quickly browse a wide overview of the wiki's content by clicking 'Read'.

    As an initial test concept, it is not a final design (indeed, work is still ongoing on this concept right now) and it is subject to significant changes. We could end up going in a very different direction, as other concepts are being explored.

    We'll be testing it out on a few communities over the holiday break to get feedback on the concept and to obtain data on how it's used. Check out the test concept on Scrubs Wiki!

    Over to you

    While we're sure you'll have plenty of feedback on the above concept, there are two other broad questions we'd love to hear your thoughts on:

    • Are there specific things that you really like about the current, standard page header?
    • What do you feel is missing from the current page header area - especially as a reader of a wiki?

    Thanks for reading!

      Loading editor
    • While the images of the test looks promising, it reminds me of how websites stylized their search engines years ago (A bit less stylish than even now) with more menus. The page header is better on how it is divided now, however, it needs to be designed the same way as the global navbar, and with more details in layout (I know this is an early version).

        Loading editor
    • I rather like the design of the dropdown menus, but the wordmark's shape, size, and placement are just wrong to my eyes. I would prefer the implementation of dropdown menus with the wordmark remaining on the lefthand side of the page. This would prevent the center of the header from appearing too tall or too busy and would fill in the gaps of unused space to the left and righthand sides.

        Loading editor
    • The styling is fairly rough in this version - I'm looking forward to having a live example of the concept to link next week, which should make the experience a bit clearer.

      I understand the concerns about the space usage - one of the benefits of this kind of layout is that it really draws your eye to the wiki's identity (the wordmark), but that doesn't mean the sides would have to be completely blank to do so. Would the idea of being able to put a banner background image there appeal? (Other thoughts are welcome, of course - we're open to lots of ideas.)

        Loading editor
    • Perhaps. There is a Dev wiki script that does just that for the current navbar, but I've found it's a bit too busy at times, particularly when the wiki in question employs a visually overpowering background as well. Perhaps what you could do is include the logo in the same row as the dropdown menu headers, with two or three menus flanking each side of the logo. I've seen this design used on some websites, and it looks a fair bit cleaner than placing the logo above the menus. Example header

        Loading editor
    • Thanks for the link - one of my colleagues had a similar thought, particular for very large screens. I'll certainly be passing on that example :)

      (Edit: I've updated all the screenshots to show a wider view, to give better context for how this concept currently looks.)

        Loading editor
    • The wordmark shouldn't be in the center. The designs for everything else look fine, but the wordmark should stay where it originally was.

        Loading editor
    • This might turn out to be Fandom's best change of the year. I really like the direction of the updated headers.

        Loading editor
    • If you move the wordmark to the side, you could fit an advert in all that empty space :)

        Loading editor
    • I like the "scroll to the top" button, but I'm not sure I can endorse any of the other changes as a global default. Different wikis have different navigation and presentation needs. I would have to see some of the various major design changes on wikis of various topics to think about if the changes work well depending on the topic.

      The central wordmark style also looks very awkward in the examples. It seems tacked on rather than integrating with the wiki.

      Some other ideas to test:

      • For the default first menu tab be just "Search" with a search entry box and button as the contents instead of menu items or sub menus. You could remove the smaller search entry box from the global nav.
        Loading editor
    • Webkinz Mania wrote: This might turn out to be Fandom's best change of the year. I really like the direction of the updated headers.

      Don't fall in love with it too much, there are some other concepts we're exploring. In the end we'll choose whatever helps readers discover and read more wiki and discussions content.

        Loading editor
    • @Fandyllic — We are under the working assumption that whatever final design we land on will eventually be enabled on all communities, but we're a long way from that point. This is simply our very first prototype and know full well we'll learn a lot along the way of what works and doesn't for different verticals, color schemes, readers, and contributors. We want to share all our findings with you here on Community Central so we don't surprise anyone with our final result.

      The fact there are two search bars feels strange. We'll monitor which gets used more frequently and where the best long-term place is for it.

      Could you illustrate your other suggestion? A simple sketch will do. :)

        Loading editor
    • First of all, I really like the slideshow as it's nice for us to see the data and the thought process behind an idea. I find that pretty important in suggesting whether a change should be made.

      Personally, I'm not at all surprised by Random page being the most important link on the "On the wiki" tab. When I go to a wiki to read, the Random page button is the most important button I use (I like to see what the wiki has and I wouldn't necessarily know what to search for). Any future design must keep this option.

      To the test concept - in general I'm not impressed. Here's why. Overall, having the wordmark center with nothing beside it is a waste of space and looks odd. I get making the wordmark center-stage to strengthen a wiki's identity, but the concept doesn't work currently. There was the recommendation for a center image though that's not going to work for every wiki given their backgrounds or complexity of the wiki (why I seen the hero image as a failure). The dropdowns remind me of the huge hubs dropdown when the first version of the new global navigation was revealed. It's a very ugly and wasteful approach. I also have to say I'm surprised a local search is making a reappearance. Does that mean the global nav search will be removed (I like the search bar being with me as I read)? There's also repetition in the proposed "Create" tab and elsewhere on the page (ie. the new create a page button and the Community page module).

      My preference of the current nav is its slime design. It's not bulky - not bulky (ugh, global nav). The ExtendedNavigation script makes it even more versatility without becoming an amoeba that consumes the page. And, of course, it's styled with the wiki.

      Trying to be objective as a reader not familiar with the site, I'd say most of the "On the Wiki" tab doesn't help a reader (for a viewer that could be a different story dependent on the purpose of the visit, the data shows though most don't care about Chat, the Forum, Videos, and I'd assume Maps would be in the same boat). Hiding (or omitting) the Random page button is a huge mistake. I remember going to one wiki (the Portability wiki I think) and the Random page button was missing and I was lost. I didn't know what I wanted to read and I felt like a fish out of water.

        Loading editor
    • Ohmyn0 wrote: @Fandyllic — We are under the working assumption that whatever final design we land on will eventually be enabled on all communities, but we're a long way from that point. This is simply our very first prototype and know full well we'll learn a lot along the way of what works and doesn't for different verticals, color schemes, readers, and contributors. We want to share all our findings with you here on Community Central so we don't surprise anyone with our final result.

      The fact there are two search bars feels strange. We'll monitor which gets used more frequently and where the best long-term place is for it.

      Could you illustrate your other suggestion? A simple sketch will do. :)

      I'll try to do a mockup.

        Loading editor
    • Took me awhile, but here it is...

      Wikia Search in menubar mockup

      I'm thinking Videos and Images could be moved out somewhere, but not sure where. Maybe Contribute.

        Loading editor
      • Are there specific things that you really like about the current, standard page header?: Yes. The fact it's easy to navigate, I don't have to click Search to search something, I loved that everything was individualized - I could put characters under characters and not have to read everything to find it. The current version is so much easier, cleaner, and not nearly as... Clustered looking.

      The current version is simple, not complicated to look at, and I know what to do without being instructed. I didn't take up as much room, I could choose where to go even if I didn't know what it was that I was looking for. I especially don't like that the logo is moved to the center of the page, it looked much cleaner at the upper left.

      What I do like, though, is the "new" search bar. It's easier to use then going all the way up (plus easier to look at), which a reason why I support Fandyllic's idea.

        Loading editor
    • I absolutely love this, especially because it redesigns a rather outdated (in my opinion) part of Oasis. I do think the search bar is pretty redundant, though, because there's a massive bar above it that does exactly the same thing, except it's more helpful (it scrolls with the page and is wider). I really hope you implement this, it's lovely.

      Edit: I have seen that Random page is missing, though. That's pretty much a foremost option for editors to find things to edit and a way for newbies to take a look at content, and it's generally a nice tool to have. This feature must have this, I think, it'd be annoying to have to use a bookmark instead. Other than that, great job.

      Also, as a reader I'd personally quite like it. I am aware that lots of people aren't keen on broad space as has been shown in the past on the Wikia platform (throwback to the h1), but I think the wordmark gives the site more identity, and identity is important for a website to gain traction with readers in my opinion. For readers, I can foresee it looking much cleaner and easy to navigate, so it's a win-win.

        Loading editor
    • Just stumbled on this, very interesting. Taking feedback from the users straight at the beginning of the early days of a project is definitely a great idea. Those are my thoughts from what I've read:

      1) Definitely keep the Random button, I use it everyday to edit the wiki I work on just because its a great way to go around and have a look through a regular user's eyes.

      2) I also agree that the Search bar should be included more within the local wiki, at the moment I feel like users might mistake it for a global search bar and not bother with it (especially in adaptaions of popular stuff)

      3) I think having edit this page in the contribute bar is a waste of space, its unlikely people will even bother clicking on it if they actually want to edit the page and are more likely to see the Edit button at the top of each page (or wherever the specific wiki put it)

      Apart from that, I would definitely keep the general layout, its compact and the wordmark's location gives the reader the ability to constantly go back to the home page. Perhaps a heavier emphasis on the fact that users can scroll through the level 1 menus (arrows?).

        Loading editor
    • I prefer the current bar still tbh, due to how easy it is to navigate and that it can be styled in many ways. The opening examples are just a bit too clunky and large imo, they look like menus for a mobile site. I don't like how a fully open menu, like in screenshot 2, takes up half the page and it should be condensed more (another thing the current Oasis bar does fairly well). Random page needs to stay too, its usually the first thing I click on a new wiki.

      I really like Fandyllic's idea though. I'll be glad to see the search bar moved back onto the wikis themselves...unless you plan on keeping the global nav search bar too, that's kind of redundant.

        Loading editor
    • Check out the test concept in action on Scrubs Wiki! The original post has been updated with this link as well.

        Loading editor
    • Thanks for the link! As I thought I would, I really like the design of the dropdown menus and I think they'll make browsing much easier. However, as I stated previously, I'm still not happy with that logo placement. I still think it'd look better this way, but for fear of beating a dead horse, I'll leave this as my last response regarding that issue.

      Either way, thanks for accepting user input this early in the design process!

        Loading editor
    • Looking at the live example it really looks like the new navigation encourages less links and benefits wikis that have less variation in content (the third column looks like it's mostly an overflow for the second, this would exclude a very large amount of information on more diverse wikis). Again, I can not stand the dropwdown styling being so chunky; it must be scaled down quite a bit in physical size (for the content presented) as well as being increased to at least support (ideally should expand upon) the current navigation. The idea of moving search again seems to be more back pedaling. Searching anywhere in an article saves a good bit of time and I'd hate to see that go.

      Edit: Just saw this post about the existing limits applying. I guess the issue is the current width requirement so moving to this test design didn't show well on the fact there wasn't a change to the limits. I would like to assume there would no longer be a width requirement, but that's usually not a safe thing to do.

        Loading editor
    • I have training in UI design so this might be long and nit-picky. 

      problems:

      1. putting the Community page under the create menu could be confusing. A newbie would think what is community page and why would I want to create one.

      2. same with Wiki Activity

      3. Photos and Videos on the 'create' menu sound like they are like multiple upload

      4. Chat is like wise confusing. It might describe what is happening if the user is the first to join Chat but it not how they think of it.

      works well:

      1. putting Search on the local bar. It never confused me where it was but I can see how it could.

      2. more intuitive to the designer. Example: On Trans wiki I felt the need to put redundant links under wiki content and as top level nav. In the new design it clearer where each level belongs.

      Recommendations:

      1. rename 'create' 'contribute'. It better captures what the menu is about.

      2. move chat to new menu with discussions/forums. They are related features differing only on time scale and permanence. 

      3. add a random page link to read menu

        Loading editor
    • BertH
      BertH removed this reply because:
      No context since the spam reply was removed
      20:18, December 19, 2016
      This reply has been removed
    • My thoughts:

      The navigation needs to focus more on content and links to articles. Users usually come to find information and less so to edit - I would prefer something like the one below that focuses more on what people are looking for.

      NzNavigation

      With more second level navigation, however, this would mean shortening the right links into icons - which should be easy enough icons for users to identify but might need some testing to see if it affects clicks to discussions and editing. They could possibly be expanded to include the words on larger screens.

      The navigation popup itself is also a bit fat, and does not play well with both the flow of links (Episode 1-6 is split from Episode 7-9) and also with smaller screen sizes. Changing the height from 48px to 36px seems more appropriate and lets the original total of 10 per navigation level stay.

      NzNavigation2
        Loading editor
    • 250x65px simply isn't large enough for the wiki wordmark, and if it's moved to top-center of the page there's no reason to keep the 250px width limit.

        Loading editor
    • Bwburke94 wrote: 250x65px simply isn't large enough for the wiki wordmark, and if it's moved to top-center of the page there's no reason to keep the 250px width limit.

      As someone who made many, many wordmarks, 250x65 is fine as a size for most wordmarks, but it would be nice to have something slightly larger, like 320x80. The topics of some wikis have very long names.

      However, I also like a nice wiki title image that has a different layout from the wordmark as the wordmark doesn't always make a good wiki title image. See Downton Abbey Wiki and Many-Colored Wiki for examples of different title images from the wordmark. A wiki I am a backup admin at has an example of a centered wordmark with a clashing title image that doesn't look great: WikiTea

        Loading editor
    • Apologies for not paying much attention to the most recent replies, I just want to answer the main topic in a personal way.

      When I first started using wikia (of course without much knowledge of mediawiki, etc.), I had a hard time understanding how to navigate to pages that I want to get to. I discovered the search bar, and category pages later, and have used those two features very often. As an admin, I'd hate to lose all the stuff from the top bar, which would be a big blow to accessibility for editors, especially new ones, so that they can find pages that help them understand what needs work, etc. However, by what it looks like, that functionality is alright, and is getting a UI revitalization, which is just fine by me.

      I'd say the feature I used most in this part of the page is the wordmark, which is my main link to get back to a neutral wiki page from which to move out into the thick of pages and content. However, a wiki specific search bar that works a little better than the global search would be hugely appreciated. Thanks for reading.

        Loading editor
    • While I find the current navbar sufficient for personal use (might just be because I designed the navbar on the wiki I'm on most), I do have to agree that perhaps it wouldn't be as easy or wouldn't serve as an aid for browsing for users not accustomed to the setup of a wiki's navbar and can make things complicated. For example, sometimes, I would be looking for something I feel should be easily accessible or found in the navbar (like policies, or links to series pages, or character list) but wouldn't find it on some wikis, so I suppose that presents certain challenges.

      I also do think that maybe the navbar is overdue for an update, but I still don't mind the current one. I do sometimes still feel like I need more space for more content links (even with the extensions). I also hope this means the mobile version/app will now have a proper navbar similar to the one on PC.

      Feedback on the concept:

      • I think I'll like the continuity, with no distinct borders or different background color for the navbar.
      • Like some above, I do not like the wordmark placement. It just looks wrong to me, probably because of the size of the wordmark and the unnaturally big space beside it on both sides makes it bothersome for me. This also ruins the effect of wordmarks with transparent backgrounds. Perhaps the placing would be better if the logo/wordmark was more like a banner. Keeping the wordmark on the left side of the top of the screen might be better, or completely redesigning the wordmark, or the look of the top border (removing the small colored part that's different from the rest and extending the top to reach the same height as the wordmark, letting it blend into the background)—the last option doesn't eliminate my issue with the big spaces though.
      • As stated above, I'd hoped that this redesign would eliminate the existing limits to the navigation lists, but it seems that it doesn't.
        • Perhaps decreasing the navigational item height (which I feel makes the whole thing way too bulky, even for tablet use) would allow for more items?
      • In line with the bullet above though, I do quite like the distinction between the "Read" and "Create" options and think this could help make the limit feel less like a limit, because, at least in my case, our wiki has 3 series-related headings and now we'd have an extra. I'd like those even more if the Create options will be customizable, allowing us to include the items under the current navbar's "On the Wiki". My 5th parent heading is currently Community-centered content, so I was hoping for a dedicated heading for that with subheadings (or at least the ability to create one).
      • For the Discuss heading, can this link to Forum when on desktop and Discussions when on the mobile version/app? Or perhaps make Discuss unclickable, then have a drop-down to link to available modes of discussion (Forum, Discussions, Blogs, Chat).

      Would it be weird if the local navbar (with the test concept's design) was just attached to the global nav, maybe with the wordmark, or a banner (something like those CSS navbar backgrounds on some wikis), or simply a different color between the two as the separator?

        Loading editor
    • Rwtia64 wrote:

      Would it be weird if the local navbar (with the test concept's design) was just attached to the global nav, maybe with the wordmark, or a banner (something like those CSS navbar backgrounds on some wikis), or simply a different color between the two as the separator?

      The main reason to keep the global and local nabbers separate is that the global one relies more on Javascript which can fail or be buggy. Also, the only thing I use the global navbar for is a quick way to get to CC and search (because I'm forced to).

        Loading editor
    • Will we be able to customise the top level headers (read, create, discuss, search)? You haven't shown what will be beneath "discuss" but it would not be relevant for our community. It seems like we're losing our 3 customizable headers in favour of whatever you guys will put there.

      Also, our community's "on this wiki" tab has not moved. Is there a way to force it to update?

      Thanks

        Loading editor
    • Acer4666 wrote: Will we be able to customise the top level headers (read, create, discuss, search)? You haven't shown what will be beneath "discuss" but it would not be relevant for our community. It seems like we're losing our 3 customizable headers in favour of whatever you guys will put there.

      Also, our community's "on this wiki" tab has not moved. Is there a way to force it to update?

      Thanks

      Umm... your questions sound like you think these test changes are actually being rolled out to all wikis. You do understand this was just a test for feedback, right?

        Loading editor
    • Seems we're giving lots of good feedback.

        Loading editor
    • Bwburke94 wrote: Seems we're giving lots of good feedback.

      Some of it is good. Some of is it not so good. I just wish Wikia staff would respond more to the feedback so we can tell if the feedback is actually being considered and understood.

        Loading editor
    • Fandyllic wrote:

      Acer4666 wrote: Will we be able to customise the top level headers (read, create, discuss, search)? You haven't shown what will be beneath "discuss" but it would not be relevant for our community. It seems like we're losing our 3 customizable headers in favour of whatever you guys will put there.

      Also, our community's "on this wiki" tab has not moved. Is there a way to force it to update?

      Thanks

      Umm... your questions sound like you think these test changes are actually being rolled out to all wikis. You do understand this was just a test for feedback, right?

      I understand completely. I'm giving feedback, that if this gets rolled out like they're suggesting I would have the above concerns. What I like about the current headers are 3 customizable top level headers, which would be lost with this proposed change.

      The question about how "on this wiki" should have moved is a concern about the here and now. How do we implement this change on our wiki if it has not happened?

        Loading editor
    • Acer4666 wrote: The question about how "on this wiki" should have moved is a concern about the here and now. How do we implement this change on our wiki if it has not happened?

      The change to On This Wiki is its movement to the right of the navigation, yes? That is currently enabled for users not logged in to Fandom - you can try go to your wiki on an incognito tab to see its effects. It is also a test though - meaning it may disappear or be adopted for logged in users in the future, depending on how it goes.

        Loading editor
    • Noreplyz wrote:

      Acer4666 wrote: The question about how "on this wiki" should have moved is a concern about the here and now. How do we implement this change on our wiki if it has not happened?

      The change to On This Wiki is its movement to the right of the navigation, yes? That is currently enabled for users not logged in to Fandom - you can try go to your wiki on an incognito tab to see its effects. It is also a test though - meaning it may disappear or be adopted for logged in users in the future, depending on how it goes.

      Ah right, thanks, didn't see it was just for anon users.

        Loading editor
    • I'd rather see a screen cap of the scrubs wiki with that odd center align wordmark and how the ads are going to be place around it. I hope you guys at Wikia are not going to put the wordmark in the ads area.

        Loading editor
    • Devilmanozzy wrote: I'd rather see a screen cap of the scrubs wiki with that odd center align wordmark and how the ads are going to be place around it. I hope you guys at Wikia are not going to put the wordmark in the ads area.

      Or ads in the wordmark area.

        Loading editor
    • Just so it's clear -- you can check out the actual concept on Scrubs Wiki right now! There's more to look at than just the screen shots.

        Loading editor
    • BertH wrote: Just so it's clear -- you can check out the actual concept on Scrubs Wiki right now! There's more to look at than just the screen shots.

      Honestly, I'm not turning off my ad blocker to risk it. I have to assume then that indeed this is just a way to fool folks into clicking ads. The trust has been thin with you guys on the tech side of wikia this week.

        Loading editor
    • WikiTea is another example.

        Loading editor
    • Devilmanozzy wrote: Honestly, I'm not turning off my ad blocker to risk it. I have to assume then that indeed this is just a way to fool folks into clicking ads.

      ???

      What does looking at the page header on Scrubs Wiki have to do with turning off adblock?

        Loading editor
    • Noooooo! The current nav bar design is the perfect framework and so easy to use. It is up to the wiki's admins to organize the nav bar's links in an effective way, and changes like this would only make it harder for people to find those links. Fandom should just add the features added by w:c:dev:ExtendedNavigation to the nav bar by default.

        Loading editor
    • Iiii I I I wrote:

      Devilmanozzy wrote: Honestly, I'm not turning off my ad blocker to risk it. I have to assume then that indeed this is just a way to fool folks into clicking ads.

      ???

      What does looking at the page header on Scrubs Wiki have to do with turning off adblock?

      Try reading. It's good for you. I think you missed the issue. He wants us to look at ADs to destroy our computers to see how it looks. If he was honest, he'd show a screen cap of it.

        Loading editor
    • There are no new ad placements as part of this test concept; an ad may appear between the page header and the top navigation bar, just like on communties that do not have the test concept.

      ScrubsTestWithLeaderboard
        Loading editor
    • How much do the current ads vary in size... I've seen some at least twice as tall as in that screenshot.

        Loading editor
    • Devilmanozzy wrote: Try reading. It's good for you. I think you missed the issue. He wants us to look at ADs to destroy our computers to see how it looks. If he was honest, he'd show a screen cap of it.

      Can you point out exactly where Bert tried to trick you into looking at an ad? Did you miss all the screenshots in the first post?

        Loading editor
    • hey everyone, thanks for the awesome feedback so far! Your input is extremely helpful so we truly appreciate you sharing your thoughts on this test concept. Now, to address some of your concerns:

      • the wordmark being centered: we found during user interviews that the wordmark was initially being overlooked and that there was also confusion as to if it was clickable or not. In the test concept we centered the logo to see if it would help draw the users eye into the page header better, and with the links right below build the understanding of not only what a user can do on the wiki, but also the heiarchy between the main page and the rest of the wiki pages. Testing such a drastic change will allow us to collect insightful data that we can then direclty compare to the current position to see which placement works best.

      • reader tools vs contribute tools: one of the main things we are looking to accomplish with the new page header is to provide the most valuable links to both readers and contributors at the right time. The links you see now will almost certainly change as we continue to test and anaylze different useage patterns from both readers and contributors.

      • the dropdown menu: this is one of many design concepts we plan to put in front of users to see if they understand the heiarchy and structure of the wiki. This concenpt translates well to the mobile web navigation and follows a traditional left-to-right reading pattern. Your feedback on the bulkiness is great and something we will take into consideration when exploring more dropdown design patterns.

      Thanks again for all of the great feedback and please keep it coming!

        Loading editor
    • TyA

      I dislike the space between the header and the content area just so the wordmark can be awkwardly placed there and I dislike the "Discuss" menu item.

      With how it is, I'm lead to believe it is to just discuss the fandom of the wiki, rather than the wiki itself or something similar. While some wikis do allow this, some don't offer forum space for that. Maybe have Discuss be a drop down, with the top still linking to the forums, and allow admins to specify certain types of discussions that can be had. Such as on the RuneScape Wiki, we have runescape:RuneScape:Active discussions, which gives a nice overview of most of the discussions on the wiki.

        Loading editor
    • Is there any way we can change it back in our personal CSS/JS? If the local wiki logo is going to go in the middle of the page, I am not in the least bit impressed. So I really would like to know how to change it back in my personal CSS/JS in advance so that when - if - the time comes, I can change it back in my personal CSS/JS.

        Loading editor
    • @C.Syde65: you can do pretty much anything in personal CSS/JS, so I don't doubt that it would be possible to change the design that way. The layout code changes are fairly significant though - it uses a new design system that we've been working to make more use of.

      I should re-iterate (though I'm sure you're aware), this is just a test concept - anything that does go live more widely could be quite different.

        Loading editor
    • Kirkburn wrote: @C.Syde65: you can do pretty much anything in personal CSS/JS, so I don't doubt that it would be possible to change the design that way. The layout code changes are fairly significant though - it uses a new design system that we've been working to make more use of.

      I should re-iterate (though I'm sure you're aware), this is just a test concept - anything that does go live more widely could be quite different.

      I just really want to get some idea of what I have to change when the changes finally happen, if they do happen, since I don't want to have to be stuck with this design, since I'm much happier with the design in it's current form.

        Loading editor
    • C.Syde65 wrote:

      I just really want to get some idea of what I have to change when the changes finally happen, if they do happen, since I don't want to have to be stuck with this design, since I'm much happier with the design in it's current form.

      If I were Wikia, I would not find that as a convincing argument to announce a schedule of when changes are happening. Even if they know when they will probably make the changes, telling you, for what I think is a trivial reason, seems foolish.

        Loading editor
    • I don't really care when exactly the changes are happening. I just want to know how to reverse the changes for my personal CSS.

        Loading editor
    • We do want to be more open about our future plans, hence this thread. However, we don't have anything to announce beyond what's already been said so far - the feedback and data from this test concept will help us make those decisions.

        Loading editor
    • Kirkburn wrote: We do want to be more open about our future plans, hence this thread. However, we don't have anything to announce beyond what's already been said so far - the feedback and data from this test concept will help us make those decisions.

      Any ideas on what CSS codes I might need to keep track of in advance, in order to bypass any changes that might be made? As long as they're codes that I can lookup using inspect element, I should have no trouble in reverting the changes in my personal CSS.

        Loading editor
    • C.Syde, you should be able to revert it to your own look with CSS. The changes don't seem too difficult to revert.

      When it changes globally, you can check the Technical Updates for specific CSS classes and ids that were updated.

        Loading editor
    • Looks great! Good work team!

        Loading editor
    • I'm just investigating the Scrubs Wiki, to see if there's any chances of reverting these changes, if these changes ever become global.

        Loading editor
    • Ugh. I so far haven't been able to change the navbar or logo back to it's former state using CSS on the Scrubs Wiki via inspect element. If I only knew exactly how they were positioned on other wikis when I try to inspect their codes using inspect element, then I'd be able to fix them quite easily. But since these codes don't seem to be inspectable, the only way to find out what I need to change is by other means, or if someone were to tell me what it was that I need to change, without necessarily telling me how to change it.

        Loading editor
    • It's too difficult, since it seems to be an entirely different layout altogether, and I've even had to send a feedback request, asking if I could have the code for the CSS needed to keep the layout in it's current form, should the layout change.

        Loading editor
    • TyA

      C.Syde65 wrote: It's too difficult, since it seems to be an entirely different layout altogether, and I've even had to send a feedback request, asking if I could have the code for the CSS needed to keep the layout in it's current form, should the layout change.

      I don't really think discussion on how to change it back to the old version is really relevant to this discussion. Perhaps say why you don't like it, or ways you think it could be surprised. If you need help with CSS to modify the look, perhaps try making a new thread asking for help?

        Loading editor
    • Yeah, I was just thinking that. In-fact that was supposed to be my final message regarding the subject.

        Loading editor
    • Menu font size is a bit too large. That should be customizable - key word here.

      Also, I think moving the wordmark to the center creates too much white space - it should be an option to keep the wordmark to the left and use this nav.

        Loading editor
    • LordTBT wrote:
      Menu font size is a bit too large. That should be customizable - key word here.

      Also, I think moving the wordmark to the center creates too much white space - it should be an option to keep the wordmark to the left and use this nav.

      Absolutely. Many wikis depend on minimizing white space, and the changes the last few years have done the opposite.

        Loading editor
    • A few thoughts about it. My main dislike about it is the fact you cannot edit the "create" tab. It would be nice to edit it because I love the way in the old header it already shows the "Wiki activity" page. It would be nice to move that up to the top. I do like the link to the discussions and the logo on top! Overall it is a good change!

        Loading editor
    • Yeah, the size is a little too large

        Loading editor
    • It's a pretty nice design but I don't think the drop down menu should overlap the article as much as it does. Also, in the sub-menus it seems like you have to actually click on the word of the article instead of being able to click anywhere in the box despite the entire thing being highlighted when you hover over it.

        Loading editor
    • This is really interesting. It does take quite a lot of vertical space when you open the menus, but it organizes all of the links in an easy-to-understand format that follows modern web design conventions. Plus, it doesn't make the ad situation any worse, which is always a good thing to make sure of. I didn't know this was happening until Tuesday's technical update, so I wonder how many communities are currently testing this out, but I'm looking forward to future iterations and updates to the design.

      I did chuckle a little at this:

      None of the six participants fully understood the Fandom // Community // Article information architecture.

      Not many users do either. I'm happy to see that this is still being brought up as a problem, because Fandom still needs to work on that.

        Loading editor
    • I've noticed an issue with the current navigation. This is the current thread at the small breakpoint of Oasis. The Contribute button feels out of place. There is a large quantity of whitespace that the wordmark could utilize. The vertical stacking of the nav at the small breakpoint reduces the consistency, yet is necessary to accomodate it.

      I like Noreplyz' suggestion of increasing the rank of the content navigation. Having the second level navigation links at 36px allows more to fit on my 768p screen and feels more consistent - the links at each level align nicely.

      I think the content of the "Discuss" tab should be editable, with uneditable links to the community's chosen forum and chat. That will fix both Ty's issue of being able to point to specific discussions in a wiki-style forum and address Miiohau's point of chat also being used for discussion.

        Loading editor
    • Would we still be able to use CSS and JS to custom navigation (I mean wikiwide) or it would break the ToU?

      Right now there are a lot of wikis with custom scripts adding extra level of navigation, reducing the white space, etc. It would be really sad to replace them all with giant box-looking links. While it can be good for mobile devices, it's completely unnecessary on PC (I believe you can click the button even if it doesn't have a 40px height).


      PS: Agreed with users above, it does take too much place. I'd like to see something like this ↓ instead.

      Scrubs navigation edit
        Loading editor
    • I like that mockup, Andrey.

        Loading editor
    • But can we alter the color? It seems that everything is becoming a dull, white and black-styled thing. While I don't really have problems with the design, if a wiki is color-coded, or has a general theme color, it doesn't matter if there are more engagements if the wiki itself is being forced into looking more drab than my grandma's curtains.

        Loading editor
    • That's technically possible, as it uses the WDS icons. Because they're SVGs, you can recolor the icons very conveniently with just .wds-icon {color:#HEX;}. Then you'd be putting a custom background color and text color on the level 1 links to get colored tiles.

        Loading editor
    • Can't wait for the update where they remove articles. It's definitively going to make more space. Who reads articles on Wikia anyway? Everyone knows people are on Wikia (or Fandom, whatever) for Discussions and the "Fandom" articles thingy on the side.

      As for the design, I'm hyped for the "Empty HTML page" update, where the whole Fandom network is just a blank HTML page uploaded on a shitty free-to-host server.

        Loading editor
    • Me too!

        Loading editor
    • Everyone knows people are on Wikia (or Fandom, whatever) for Discussions and the "Fandom" articles thingy on the side.

      I do think that is thread hijacking and of little relevance. By posting about the module on a feature thread, you annoying people who'd rather just move on.

      EDIT: Did you have to swear, break policy AND cuss the free hosting?

        Loading editor
    • Andrey Andrey wrote: Would we still be able to use CSS and JS to custom navigation (I mean wikiwide) or it would break the ToU?

      Right now there are a lot of wikis with custom scripts adding extra level of navigation, reducing the white space, etc. It would be really sad to replace them all with giant box-looking links. While it can be good for mobile devices, it's completely unnecessary on PC (I believe you can click the button even if it doesn't have a 40px height).


      PS: Agreed with users above, it does take too much place. I'd like to see something like this ↓ instead.

      Scrubs navigation edit

      Thanks for the mockup!

      As this is a limited test concept, it's not really possible to answer your question directly, since any wider update might be radically different (and the desire for such CSS/JS might not exist). Certainly this test has limitations that likely wouldn't exist in a wider scale version, such as it being quite basic, not being very theme-aware and having odd limits on the number of links.

        Loading editor
    • Wrath022 wrote: But can we alter the color? It seems that everything is becoming a dull, white and black-styled thing. While I don't really have problems with the design, if a wiki is color-coded, or has a general theme color, it doesn't matter if there are more engagements if the wiki itself is being forced into looking more drab than my grandma's curtains.

      While limited, it does use make some use of the local theme - Scrubs Wiki just has a very simple design. Vampire Diaries Wiki is a dark wiki that is also running the test at the moment.

        Loading editor
    • LordTBT wrote: Menu font size is a bit too large. That should be customizable - key word here.

      Also, I think moving the wordmark to the center creates too much white space - it should be an option to keep the wordmark to the left and use this nav.

      Space usage is totally a valid concern. Personally I like how the centered wordmark makes it clearer that everything below that point is 'part of that community' - but it does pose questions about how to fit things around it. There's been some interesting ideas so far - splitting the navigation links to either side, or using the available space for interesting visual elements (e.g. banner images), and we would love to hear more thoughts and ideas.

        Loading editor
    • I think Discuss should be a menu with Discussions and Chat. Not sure how Chat is considered part of Create, but Discussions is not. Also, the Read menu definitely seems overly restrictive. I don't like having to go through Read for all the other stuff.

        Loading editor
    • I just saw what it looked like - it's really awesome!

        Loading editor
    • Fandyllic wrote: I think Discuss should be a menu with Discussions and Chat. Not sure how Chat is considered part of Create, but Discussions is not. Also, the Read menu definitely seems overly restrictive. I don't like having to go through Read for all the other stuff.

      It's fair to say that the 'Create' menu has ended up a bit strange - it's one of those things that got weirder as more development occurred (a very useful aspect of creating tests: discovering inadequacies!). It'll certainly warrant more thought.

        Loading editor
    • Kirkburn wrote:

      Fandyllic wrote: I think Discuss should be a menu with Discussions and Chat. Not sure how Chat is considered part of Create, but Discussions is not. Also, the Read menu definitely seems overly restrictive. I don't like having to go through Read for all the other stuff.

      It's fair to say that the 'Create' menu has ended up a bit strange - it's one of those things that got weirder as more development occurred (a very useful aspect of creating tests: discovering inadequacies!). It'll certainly warrant more thought.

      Although I'm glad for a reply... it isn't very encouraging.

        Loading editor
    • What more are you looking for? It's still in active development and nowhere near finalized.

        Loading editor
    • Aye, I do want to reiterate that this is a test concept - it's a bit rough in some areas. We don't want to spend a lot of time polishing something that may not ultimately be used, as that would waste development resources.

        Loading editor
    • Unfortunately, Wikia communication practice on in-development features is such that one can never know at what state a feature is in on the development timeline. Also, "more thought" is vague and uninformative.

      Discussions was supposed to still be in development and then all of a sudden it is the sole feature for new wikis and the previous thread-based Forum is no longer an option.

      Until I have an idea that these tests are not going to suddenly appear as the way things work, I have to be wary and respond as if feedback is going to be largely ignored unless some concrete action is mentioned.

        Loading editor
    • It doesn't look or feel right. Idk why tbh. It's so empty and um...I guess out of place. The font is too small.have you tried using capital letters?

        Loading editor
    • Another wiki that has this is The House Of Cards Wiki! You can check it out there too!

        Loading editor
    • This seems very odd. I like the old drop down version.

        Loading editor
    • I really hope you guys don't go with this version. The wiki wordmark in the center feels out of place and should stay to the left. A post earlier in the thread showed the idea of being able to add characters, episodes etc. to this new design on the bar which I feel is a better solution. Instead of shoving it in a "Read" drop down. Doing that makes it HARDER for people to find what they want quickly which means they spend shorter time on the wiki. Also, I'm really concerned about the customization with this nav bar. Will you allow admins to fully customize this or only allow some parts of it to be customized? Also what would happen to personal JS scripts for the nav bar, like WikiMarks? Also thinking about the custom CSS option, that could probably work out better then this also. Aside from all that, I'm a fan of modern designs, and this new design looks nice and is a vast improvement over the current design in terms of visual appeal, but in terms of functionality over the current bar, it's not there.

        Loading editor
    • Biggest problem with it is the location of the wordmark, and the need for customization of all part, but keeping with the idea of what we have now. I also hope that this can also be CSS and JS compatible. I would like to see way more updates on the issue.

        Loading editor
    • Pretty much agree with everything HighJewElfKing said, the nav bar has to be small enough that users feel they can see every option before making a decision. On smaller screens it's likely that users will have to scroll down to see everything. And the create button doesn't need such an empahsis, it was fine at it's previous location. Although the new labelling does make it clearer what users can expect under each of the main tabs.

        Loading editor
    • If it's not broken, don't fix it.

        Loading editor
    • Jamesb1 wrote: If it's not broken, don't fix it.

      If it is an outdated design that doesn't speak clear to users and editors, maybe consider fixing it.

      They've mentioned that this is one of the designs they are considering, so it's not a final design and they're probably collecting data and feedback to see if it works or not. It might not be a fix but surely a step to gather info so that they can make a better solution.

        Loading editor
    • If this site abandoned continuous improvement, I'd probably leave.

      This is not optimal design. The design at the medium breakpoint is also dated, and I'd really like to see all of the page design get some attention and modernizing. That doesn't mean sacrificing compactness as a goal, but making sure things aren't too unintuitive because they are more compact. Noreplyz strikes a nice balance in his mockup.

        Loading editor
    • Jamesb1 wrote:
      If it's not broken, don't fix it.

      I'm fine with them working on improving the site, as long as they don't push a rushed update onto the wikis all of a sudden. 

      This thread is a perfect example of how a feature development should go. Keep up the good work, guys.

        Loading editor
    • I'm OK with changes, but two thing needs to be kept. One: on both wikis I'm an admin of, we have links to what's called the "Article Creation Center" and the Community Portal. My main wiki (my version of Pottermore pretty much), also has a link to the Index. What those things are:

      Index: Category where all the Content categories are. If you just want to read not contribute, that's your spot. Index includes a dropdown menu for the basic links so you don't have to go to the index.

      Article Creation Center: On Crystal Prism Wiki, this tab has links to Recently Changed Pages, Wanted Pages, and Pages Needing Illustrations. The main tab itself links to the Center itself, which is a Community Page that contains preload boxes for common articles.

      Community Portal: This tab contains links to Recent Blog Posts, the Chat and the Forum (Now Discussions). It also contains links to the Community Portal itself. This page, which seems to come with every wiki, is important as it gives a basic overview of how wiki editing works. It's been slightly customized for both wikis, but the overall info remains the same.

      Losing any of these things and their quick links I feel would impact the communities as a whole. They exist to make it easier for new editors to find the info they need, for members to gather, and the Article Creation Center helps keep a consistant layout between same-subject articles.Please the image attached for how these look.

      Wikia Example

      Example of the wiki's I run.

      Also see Crystal Prism Wiki and Jungle Emperor Leo Wiki to see how it works in action.

      Thanks for your time.

        Loading editor
    • Speedit wrote: If this site abandoned continuous improvement, I'd probably leave.

      This is not optimal design. The design at the medium breakpoint is also dated, and I'd really like to see all of the page design get some attention and modernizing. That doesn't mean sacrificing compactness as a goal, but making sure things aren't too unintuitive because they are more compact. Noreplyz strikes a nice balance in his mockup.

      You're saying the proposed header is optimal? It's not even 10% smaller than the current page header; the only difference is that the whitespace is now on either side of the wordmark, and the literal white space is reduced by the colored bar at the top.

        Loading editor
    • Speedit wrote: If this site abandoned continuous improvement, I'd probably leave.

      This is not optimal design. The design at the medium breakpoint is also dated, and I'd really like to see all of the page design get some attention and modernizing. That doesn't mean sacrificing compactness as a goal, but making sure things aren't too unintuitive because they are more compact. Noreplyz strikes a nice balance in his mockup.

      Noreplyz's mockup is better, but still has the big problems of lots of wasted space. These new UI designs need to be reviewed on a variety of screen sizes, but seem to be designed for screen sizes that space is not at a premium. Considering the trend of the standard laptop having a crappy ~1360x768 resolution in many cases, this waste of vertical space can be painful.

        Loading editor
    • Agreed - I think the layout is improved, but the size needs a second look. Vertical size is at a double premium to horizontal size, and the expanded navigation is slightly clipped on my 768p screen.

        Loading editor
    • All this talk about how new user don't get how the navbar works is preposterous. When I joined, I had no idea how the thing worked, but since I hovered over it, it took two seconds to do. This one looks even more complicated.

        Loading editor
    • I wouldn't say that the current navigation style is not understood - but I think it's fair to say that it has issues. For example, it's not ideal for touch devices, and may not be the best or most organized use of space. That's not to say this test concept is perfect either - we're definitely open to suggestions on how to improve either version.

        Loading editor
    • Kirkburn wrote: While limited, it does use make some use of the local theme - Scrubs Wiki just has a very simple design. Vampire Diaries Wiki is a dark wiki that is also running the test at the moment.

      I see. I'll be looking forward to more specifics later on in the future, then. Thank you for your reply!

        Loading editor
    • Cans48 wrote: All this talk about how new user don't get how the navbar works is preposterous. When I joined, I had no idea how the thing worked, but since I hovered over it, it took two seconds to do. This one looks even more complicated.

      That may be you, but everyone is different. You cannot say that just because you had no problem with it, that it everyone had no problems with it.

        Loading editor
    • Kirkburn wrote: I wouldn't say that the current navigation style is not understood - but I think it's fair to say that it has issues. For example, it's not ideal for touch devices, and may not be the best or most organized use of space. That's not to say this test concept is perfect either - we're definitely open to suggestions on how to improve either version.

      Through the simple usage of non-linking tabs and such, the nav bars on my wikis (example: The Clash Royale Wiki) work great on touch devices.

        Loading editor
    • Kirkburn wrote: I wouldn't say that the current navigation style is not understood - but I think it's fair to say that it has issues. For example, it's not ideal for touch devices, and may not be the best or most organized use of space. That's not to say this test concept is perfect either - we're definitely open to suggestions on how to improve either version.

      Which is precisely why you should let mobile/touch devices use a "hamburger" style menu instead.

        Loading editor
    • Like how you removed a perfectly (agreeably) good feature, Appreciation, will you remove this new change if/when it's released IF it gets bad reception? I really am not keen on this, and if I and everyone else keep(s) hearing those words, what exactly are YOU going to do about it? Massive changes like this can't just be done permenantly, we all use this site as a community, and changes you make like this can really effect how people use individual wikis, effecting site views, etc. If this is going to go ahead, I really think it should be done as a test period (It might be, I haven't read this entire thread and/or its comments yet), just to see how successful it is, just like how Appreciation was done. 

        Loading editor
    • The only thing I don't like about making a new wiki is the forums. The forums are much better than discussions, in my opinion. But I guess discussions is still okay.

        Loading editor
    • Monkeypolice188 wrote:
      Like how you removed a perfectly (agreeably) good feature, Appreciation, will you remove this new change if/when it's released IF it gets bad reception?

      The Appreciation feature didn't have much bad reception (though it wasn't perfect and users had great ideas for improvements), but it was a test feature from the very beginning, so it being removed was 100% expected. It may return some day.

        Loading editor
    • These things are huge. Especially with the fonts and amount of padding used on the 1st sub-level! Although my fat fingers appreciate it on a mobile device, there's a lot of wasted space when viewing this on a desktop. It would be a very good idea to reduce the scaling, or at least add some way for us to modify it via CSS without violating the TOU.

      I would like it if the global & local nav bars were integrated, saving a lot of space. It could also make it easier to collapse the navigation on a mobile device (1 click vs 2 clicks). (Gears, 3 dots, & "hamburger" menus FTW!)

      I'm neutral on the placement of the word-mark. It's mostly a stylistic element. It makes sense on big screens, but it makes a lot less sense on smaller screens. I'll be slightly heretical here and say that in many cases, it can be omitted in favor of the much smaller "home" icon (I do understand that it is useful for branding, though).

      The current test themes are fairly "meh". I'm looking forward to better integration with the Theme Manager and CSS, but there are no glaring problems. The icons next to the top level headers look fine (clear meaning, good scale relative to text). I would prefer the non-hover color of the icons to be closer to that of the text, but they aren't super transparent.

      There are definitely a lot of issues with organization, flow, and naming conventions.

      I like having the local search bar in the local menu. When I see the search bar in the global menu, I always think it's for a cross-wiki search. However, I'm not sure how to best integrate it into this navigation header.

      • "Create" needs to be changed to "Contribute" or something similar... this would allow for things like "expand this article", "update this page" and "proofread this article" to fit better.
        • Add "Add a Blog post" to the "Create" menu.
      • Change the name of "Read" to something more inclusive of consuming multimedia. Maybe something like "View" or "Explore"? Not all users are going to be using their eyes to interact with the wiki.
        • Move viewing "Videos" to "Explore"
        • Move viewing "Photos" to "Explore"
        • Add Special:Random under "Explore"
      • Put all discussion forms (blog/chat/forums/comments/etc) under "Discuss", not just the new discussion module.
        • A link to Leaderboards should be here for communities that have enabled Leaderboards.
      • Keep the Search bar, but change the current header "Search" to "Help" (or some similar concept).
        • Add links to Help:Contents... and policies & MOS, "report user", admin/mod details, and volunteer (VSTF & WLB, etc) type things there.
      • I see there is no "On this Wiki" section. I approve. One expects that all of the content of the header would be "on this wiki". I appreciate that the various links previously in that location are implemented as links in the various sections instead.

      I'm not an admin on any of the test wikis, so I don't see an option to edit the navigation itself... Is there a visible link/button on/near the navigation header, or do you have to go somewhere esoteric (like Special:AdminDashboard) to edit it?

      Overall, it's not too bad. I kinda like the division between consuming, creating, and discussing content. I do hope that the customizable slots aren't too limited...As an admin, I have a few wikis where I definitely use all 3 sub-levels & most of the slots (4/7/10) for wiki specific content. Forcing users entirely into the category namespace for that same content would be less than ideal.

        Loading editor
    • Having a new menu is ok, but please allow us to use wordmarks in different resolutions and in SVG format so that they are scaled automatically.

      The buttons and list items of the header menus are too big, and they look odd compared to the main wiki content. It will be better for them to be merged into the global navigation bar.

      Looking at the screenshots, I think the edit menu, the talk button, and the page count should be moved to the empty spaces around the new header buttons.

        Loading editor
    • Vandraedha wrote:

      I'm not an admin on any of the test wikis, so I don't see an option to edit the navigation itself... Is there a visible link/button on/near the navigation header, or do you have to go somewhere esoteric (like Special:AdminDashboard) to edit it?

      On WikiTea (a test wiki where I happen to be an admin), there is the standard "Edit Wiki Navigation" link at the bottom of the "Create" menu.

      Also, I agree with almost everything on your post. Hopefully Wikia staff reads it and actually considers acting on a large portion of it.

        Loading editor
    • Changes I suggest:

      New-header-mprovements-minimal

      Also, would you please add the new header feature to the Wiki features page so that I can try it out? Thanks!

        Loading editor
    • KurwaAntics wrote:
      Having a new menu is ok, but please allow us to use wordmarks in different resolutions and in SVG format so that they are scaled automatically.

      I agree with this. I always create my wordmarks in much higher resolutions and then scale them down, which means I have to maintain two versions of them - one 250x65 image as the wordmark itself, and one larger image for when it needs to be placed in a template.

        Loading editor
    • So we know SVG wordmarks aren't supported?

        Loading editor
    • I've just seen the new menu in the wiki scrubs and I'm not very fan currently. Why is it on the middle of the page ? Why not put a burger menu on left ?

      By the way, on the middle, when the menu collapse, a part of the stuff (informations & text) on the page is hidden by it. And this is an aera of the page where the pointer finds himself regularly. I think that it would improve the distribution of the elements in the page if the menu was on the left.

      And like a lot of people, I find it currently pretty huge too.^^

      (Sorry if I'm not totally understandable, I'm not english^^)

        Loading editor
    • BlondeLegendaire wrote: Why not put a burger menu on left ?

      Burger menus are not actually very good - you lose a lot of clicks when important content like links to important content, and even links to categorised content (like 'Characters', 'Episodes') is hidden away.

      However, I feel that the 'Read' tab is nearly equivalent to a hamburger menu, we're hiding the most important part of the site - the articles - and forgoing that with less important aspects of the community. The Create menu specifically is too much in the spotlight when not many readers may not want to or have the time to contribute.

        Loading editor
    • Noreplyz wrote:

      BlondeLegendaire wrote: Why not put a burger menu on left ?

      Burger menus are not actually very good - you lose a lot of clicks when important content like links to important content, and even links to categorised content (like 'Characters', 'Episodes') is hidden away.

      However, I feel that the 'Read' tab is nearly equivalent to a hamburger menu, we're hiding the most important part of the site - the articles - and forgoing that with less important aspects of the community. The Create menu specifically is too much in the spotlight when not many readers may not want to or have the time to contribute.

      It would be very good for mobile/tablet users though.

        Loading editor
    • They're good to a certain extent on mobile and tablet, because there's limited real estate and you might want to display content first than navigation. Fandom already uses a hamburger menu for its mobile sites.

      It's a matter of testing out which format is better at achieving their goals - maybe they want to have more clicks into further content, or put emphasis on links within the article to continue going around the wiki.

        Loading editor
    • Noreplyz wrote: ...The Create menu specifically is too much in the spotlight when not many readers may not want to or have the time to contribute.

      I disagree. I think that the edit/read/discuss options are much better balanced on this header menu than in previous renditions updates. It does still need some tweaking, though.

        Loading editor
    • P.S. the edit button should go to the "create" list and the talk button to the "discuss" list.

        Loading editor
    • I think the dropdowns are little bit too big, maybe make them as small as the old ones

        Loading editor
    • Absolutely.

      The existence of the mobile site shouldn't detract from the experience on desktop browsers.

        Loading editor
    • FYI, I worked up some Javascript to insert a Recent Changes link before the Wiki Activity link in the Create menu on WikiTea.

      It was kind of tricky, but doable... Put the code below in Special:MyPage/wikia.js on a wiki with the new page header to test it.

      /* Add Recent Changes menu item link to Create menu before Wiki Activity */
      $(function () {
      	$('div.rwe-page-header-nav__create > ul.rwe-page-header-nav__dropdown-second-level > li.rwe-page-header-nav__dropdown-second-level-item:nth-child(3)').not('#RC').before('<li class="rwe-page-header-nav__dropdown-item rwe-page-header-nav__dropdown-second-level-item" id="RC"><div class="rwe-page-header-nav__dropdown-link-wrapper"><a class="rwe-page-header-nav__link" data-tracking="create-recentchanges" href="/wiki/Special:RecentChanges">Recent Changes</a></div></li>');
      });
      

      Update: I tested it on Scrubs wiki and it works there too.

        Loading editor
    • Fandyllic wrote: FYI, I worked up some Javascript to insert a Recent Changes link before the Wiki Activity link in the Create menu on WikiTea.

      It was kind of tricky, but doable... Put the code below in Special:MyPage/wikia.js on a wiki with the new page header to test it.

      /* Add Recent Changes menu item link to Create menu before Wiki Activity */
      $(function () {
      	$('div.rwe-page-header-nav__create > ul.rwe-page-header-nav__dropdown-second-level > li.rwe-page-header-nav__dropdown-second-level-item:nth-child(3)').not('#RC').before('<li class="rwe-page-header-nav__dropdown-item rwe-page-header-nav__dropdown-second-level-item" id="RC"><div class="rwe-page-header-nav__dropdown-link-wrapper"><a class="rwe-page-header-nav__link" data-tracking="create-recentchanges" href="/wiki/Special:RecentChanges">Recent Changes</a></div></li>');
      });
      

      Update: I tested it on Scrubs wiki and it works there too.

      Works great, thanks ;D
      One minor issue though:

      https://i.gyazo.com/4a16a77dfbb505fe21016a9b54619281.gif

        Loading editor
    • Andrey Andrey wrote:

      Works great, thanks ;D
      One minor issue though:

      https://i.gyazo.com/4a16a77dfbb505fe21016a9b54619281.gif

      Yeah I saw that, but it should go away, I hope. I seems to be some inherited JS event that doesn't attach immediately.

        Loading editor
    • Thanks for the continued feedback, it's much appreciated!

      Now that it's been live for a little while, we're currently reviewing the data from the test (along with everyone's thoughts and suggestions), and we're not currently planning on enabling this test concept on more wikis. Look out for an update soon.

        Loading editor
    • Kirkburn wrote:
      ...and we're not currently planning on enabling this test concept on more wikis. Look out for an update soon.

      Typo?

        Loading editor
    • Not a typo - we don't currently have any plans to expand this test. :)

        Loading editor
    • I'd still be interested in larger wordmarks, at the very least. 250x65 isn't enough.

        Loading editor
    • I briefly skimmed the comments. Just a few quick points:

      • I agree with the below concept here. It makes far more effective use of space and is not at all compromising of wiki identity.
      Scrubs navigation edit
      • The reasoning behind centering the wordmark, "We think placing the wordmark top and center will help emphasise your wiki's identity", is undermined by doing away with the navigation link button colour scheme. Like the current navigation bar, these links should retain the primary colour used by the buttons and footer toolbar, for both contrast and emphasis. This has a subtle subconscious effect that resonates a greater impression of 'wholeness' to the viewer, improving the perception of overall article/website quality.
      • Higher level menus should only become visible as they are manually accessed or otherwise navigation will seem forceful.
      • You must make a decision of whether you are going to include the search bar within the header bar or the page header. Using both is confusing and unrefined.
      • I also agree with the above comment. Now would be the ideal time to take the opportunity to increase the maximum size of the selectable wordmark, even just extending the available room for text wordmarks which often overflow due to long titles.
      • Indeed, the wordmark could do with an update.
        Loading editor
    • GIVE US SVG WORDMARKS!

        Loading editor
    • Agree with Super Robot, if fandom has a SVG logo then there should be SVG wordmarks, but i think the reason why they dont allow SVG wordmarks is because it would cost more data space

        Loading editor
    • Oo1oo2oo3oo4 wrote:
      Agree with Super Robot, if fandom has a SVG logo then there should be SVG wordmarks, but i think the reason why they dont allow SVG wordmarks is because it would cost more data space

      More likely it is a technical problem. An article takes more space than SVG wordmark would. In theory, they could hide the fact SVG isn't actually supported and convert behind the scenes but it just as easy for us to do the conversion and that gives us control of the end result.


      All that said SVG would have one major advantage for them. Scaleability! They could adjust the word mark to match the screen it is on. Which isn't a major issue on desktops but can be on mobile.  If either of you really care about SVG wordmarks give them(Fandom Staff) a line at Special:Contact/feedback   

        Loading editor
    • Oo1oo2oo3oo4 wrote:
      [...] the reason why they dont allow SVG wordmarks is because it would cost more data space

      SVG files are actually (on average) much smaller than raster file formats.

        Loading editor
    • Iiii I I I wrote:

      Oo1oo2oo3oo4 wrote:
      [...] the reason why they dont allow SVG wordmarks is because it would cost more data space

      SVG files are actually (on average) much smaller than raster file formats.

      oh... did not know that

        Loading editor
    • I'm not looking forward to these design changes since I think the current layout is fine the way it is, and it's going to be awkward to make new CSS for the new layout. Also I'm not looking forward to the more narrow page width.

        Loading editor
    • C.Syde65 wrote: I'm not looking forward to these design changes since I think the current layout is fine the way it is, and it's going to be awkward to make new CSS for the new layout. Also I'm not looking forward to the more narrow page width.

      What?

      As stated previously in the thread:

      • "The possible updates are in flux - the outcome significantly depends a lot on research, tests, and the feedback we receive from you."
      • "As an initial test concept, it is not a final design (indeed, work is still ongoing on this concept right now) and it is subject to significant changes. We could end up going in a very different direction, as other concepts are being explored."
      • "We're not currently planning on enabling this test concept on more wikis."
        Loading editor
    • Yeah, true. I'm just saying that should they take effect, I won't be impressed.

        Loading editor
    • It's been a little while since we've posted about this test, so it's time for an update!

      The quick summary is: later this week, we will be retiring this page header test concept and removing it from all wikis where it's currently displayed. To be clear, this was always the plan. It's part of an incremental approach to product development and releases to help us better gather your feedback and learn from tests.

      What have we learned?

      First, thanks to everyone who sent us feedback and to the wikis that tested this prototype. We received lots of interesting ideas and data as a result.

      In particular, analysis of the data showed us that this restyled page header had a lower rate of user interaction than the existing version. However, this had no effect on overall page views and interaction. We measured interaction here by comparing the clicks on the page header to the rest of the page, as well as on a broader scale to see if these changes made any difference in overall page views. This is to make sure that, as we test the page header, we don't hurt interaction on the rest of the page.

      Data historically shows that search and in-content links are the most frequently used method for navigating throughout a wiki. This remained true during the test. So while we didn't see an uptick in overall interaction, it didn't go down either. This is a good piece of data to have, because it shows us that smart change is not a bad thing for the page header.

      Previous A/B tests have shown us that simple styling updates and usability adjustments to the existing navigation can improve interaction rates, so we're still confident that there's room for improvements to make it a more modern-looking and useful navigation tool.

      What's next?

      We'll be looking at alternative concepts for the page header in the coming weeks, and we'll talk more about that when we have something to share. We'll also talk a bit more about it in an upcoming blog post about how we are approaching product development moving forward. That includes discussing what we've learned from tests, how we're using feedback like what you gave us here, and why we do or don't take certain pieces of feedback into account when we make decisions.

      Of course, if you have additional feedback on this test concept, please let us know!

        Loading editor
    • Honestly if staff was either trying to improve the previous header attempt that left a gap or found the idea from Fire Emblem or Golden Sun Universe (both NIWA network), for this logo placement idea to even work; the first thing staff must redesign is the skin. Moving the logo to the top and center of the page without allowing it blend in at all is foolish and will not display well to any audience.

      The other problem is staff hiding the useful menus and where things are located, its fine where it is currently.

        Loading editor
    • 35.20.144.189 wrote:
      Honestly if staff was either trying to improve the previous header attempt that left a gap or found the idea from Fire Emblem or Golden Sun Universe (both NIWA network), for this logo placement idea to even work; the first thing staff must redesign is the skin. Moving the logo to the top and center of the page without allowing it blend in at all is foolish and will not display well to any audience.

      The other problem is staff hiding the useful menus and where things are located, its fine where it is currently.

      Yes, I agree with this completely.

        Loading editor
    • I believe that that's what Staff are doing - they're updating the skin, but slowly because changing the whole interface is costly and hasn't worked well in the past.

      I like that they are trying to work out a good solution that fits in with the theme of the Fandom site, and that the header with moved logo is something that is styled with purpose - it puts the wiki into centre attention, rather than the Fandom logo on the top right.

      But yeah, there are problems with that, especially when there are ad units - your content is so far down the page that readers might end up leaving the site before the page even loads. Also, pushing everything into sub menus wasn't such a good idea if you want to expose more areas of the wiki that users can read and edit.

        Loading editor
    • My favorite option for the header is "random page" which takes you to a random page. You don't click on it, and you never know what's going to appear. Exciting!

      And I've seen the "new" header appear on Regular Show Wiki, what did it look like before?

      And in my opinion, I like the old header. Like I said, my favorite one was the "random page" and my second, the Fourms.


      I also disagree with this because that the reader might get blocked with the "drop-down header" (as I'm going to call it). So it may cause problems, and may prevent viewers from seeing valuable information.

        Loading editor
    • FireFlows wrote:

      And I've seen the "new" header appear on Regular Show Wiki, what did it look like before?

      I'm not sure what you mean - the test concept was live on there from just before Christmas until last Friday. It has now gone back to the normal page header style.

      If you mean that you didn't get a chance to see what this concept looked like there, it was like the screenshots of Scrubs Wiki above, but with Regular Show Wiki theming.

        Loading editor
    • Oh. I got a chance to see it different Live. Thanks, I haven't been there since Friday.

        Loading editor
    • JustLeafy
      JustLeafy removed this reply because:
      .
      14:25, February 21, 2017
      This reply has been removed
    • If this is to become a new feature eventually, then it should have an easier way to customise the menu. Also move the wordmark to the top left like before and allow higher resolution wordmarks. And I hope you can customise this more such as change the colour and font of the dropdown menu

        Loading editor
    • Squirrel719 wrote:
      If this is to become a new feature eventually, then it should have an easier way to customise the menu. Also move the wordmark to the top left like before and allow higher resolution wordmarks. And I hope you can customise this more such as change the colour and font of the dropdown menu

      Yes

        Loading editor
    • Squirrel719 wrote:
      If this is to become a new feature eventually, then it should have an easier way to customise the menu. Also move the wordmark to the top left like before and allow higher resolution wordmarks. And I hope you can customise this more such as change the colour and font of the dropdown menu

      Also, I would like it to be in Special:WikiFeatures.

        Loading editor
    • I would question the need for a Special:WikiFeatures option toggling a base design element (after they fix its issues). Navigating, globally customizing or personally populating two different styles across wikis does not sound so good.

        Loading editor
    • Speedit wrote:
      I would question the need for a Special:WikiFeatures option toggling a base design element (after they fix its issues). Navigating, globally customizing or personally populating two different styles across wikis does not sound so good.

      How, exactly?

        Loading editor
      1. If it comes back with a format change to the input for versatility, you'll get two explanations in the help pages. If not, there would still be people forking code for the wrong design, wrong code in CC threads etc.
      2. Dev Wiki needs either scripts of a higher complexity to ensure they work with both the old and the new style, or independent scripts applying to each. Making installation and/or maintenance more complex there.
      3. Consistency between wikis is underrated. If someone uses the spotlight feature to bounce between wikis, they'll probably have two wiki navigation designs to get used to. User customization globally is harder too.
        Loading editor
    • Maybe this top navigation can be available under a new, 3rd skin.

        Loading editor
    • I like the setup as it is right now. For the most part.

      On the Wiki, for one, I don't like. I feel it is mainly for frequent/hardcore users, not the average user. I like the change of seeing it at the end of the line up for anon. users. I, myself, would rather see it at the end even when signed in.

      Also, I would like to suggest changing the name of On the Wiki to simply Wiki, Wikia or Fandom, or (my favorite) This Wiki's:. The last would make it (if you read the first tier then the second...) read like This Wiki's: Videos, This Wiki's: Chat... for the second level items.

      Another thing, remove the Random Page from the header and turn it into a button and placing it along side the “Add New Page” or placing it above and moving PAGES ON THIS WIKI just to the left.

      However, removing it from the header also makes room for something else. Otherwise the second tier goes from being at least four to three items. What this would be is up to debate. But, as I said, On The Wiki is more for the hardcore editors, something like: Create and Expand, or, Create/Expand, then a drop down of: WantedPages, LonelyPages, FewestRevisions, ShortPages, Stubs... just to name a few, would be an appropriate addition. Maybe even put a Random in there too. A list of quick links for editors who may be looking for something to do, you might say.

      Overall, the centered wordmark looked better with a dark backround. Not so much on white, though. But, I do not care for centralizing the word mark, I like it where it is right now.

        Loading editor
    • I really enjoy the random page button.

        Loading editor
    • I agree that 'On the wiki' is useful for editors, and not so much for the regular reader (except for random page, maybe)

        Loading editor
    • The newly-proposed header is much better than the initial plan, but I'm still wondering whether SVG wordmarks are possible. 250x65 will effectively become less and less space as the years go on, because of higher screen resolutions.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.