Wikia

Community Central

Shifting to a fluid layout

  • Content is rightfully the heart of Wikia —  it’s what we’re all here for: reading, creating, editing, and administering the information you care about. Page views on tablets are increasing, and the current experience on these smaller screens is a “zoomed-out” version of the desktop view (which is hard to read, hard to click on, etc.) We also know that users with larger monitor resolutions can be better supported if we utilize the available space on those displays. And for the past few years we've heard strong feedback that the article content space on any device is too small. With Darwin, one of our goals is to make content be the “king” by giving it a better share of real estate on the page, no matter the display.

    Common convention on websites today is to use a responsive page layout, which means detecting screen resolution and delivering an experience based on that information. There are many types of responsive page layouts and a fluid layout was the best fit with our goals, as stated above. Darwin's fluid layout will be used on tablets and anything larger; smartphones will still use the ‘Wikiamobile’ skin as they do today.
    Here’s how fluid layout works on Wikia.

    RightRail300

    The right rail at 300px wide

    Right Rail
    We didn’t want to make the right rail fluid. Why? At the end of the day it only needs to be 300px wide to support our medium rectangle ad — an ad that’s a reality of keeping Wikia running because it’s the best performing ad we have. We determined that the right rail modules work just as well in a static 300px width, and we wanted to return extra pixels to the article content space (the current rail is 330px wide). So with Darwin, the rail will always stay at 300px wide, no matter what resolution you have.

    On tablets and other smaller displays, the right rail content will shift to display below the main content area, allowing the article to remain the focus.  The one exception is the Search box, which shifts into the wiki header area.

    Article Content
    This is where you’ll see the biggest impact. Long live the King! Darwin has a minimum article content space of around 700px, no matter what resolution you’re on. For instance, the most standard resolution for users on Wikia is 1366px, representing about 25% of our total visits. With the fluid layout, users on that resolution will see the increased minimum article content space of about 700px (an increase of 30px from today). 35% of Wikia users are on displays larger than 1366px and can support more than 700px, so those users will see an even larger content space. *This post formerly noted incorrect pixel amounts in the section above; these have since been corrected.

    A maximum is just as important as a minimum. There comes a point where readability and layout suffer from a content area that’s too big, and the text and images get stretched too far horizontally. With that in mind we’ve established the maximum article content space at 1270px. This gives a huge jump to the article content space on large resolutions (an increase of 600px from today!) but ensures that we don’t allow article content to stretch so big that it’s hard to read and edit.

    Font Size
    If we grew the content space but maintained the current font size of 13px, readability and layout would still suffer on the larger supported resolutions. So Darwin will increase the standard font size to 14px, for all displays.

    Embedded Media — Templates, Tables, Images, Videos, etc.
    What does fluid layout mean for article content that's not just plain text? It depends on several factors, like what type of content it is and how it was coded by the community. For tables, templates and other highly customized content, using percentage-width values in the code will often be a better strategy with the fluid layout. This means that instead of using a hard-coded width value like '150px', you use a different value like '75%' that isn’t associated with a concrete unit of measure, but rather is flexible value and can easily adapt to a fluid page layout.

    Tables will receive some great benefit from this change. I think we all agree that most larger tables would work better outside of the current 670px constraint. We solve this today by adding the jagged-edge “wide table popup” tool. With a fluid layout, tables will show as much as the content space on your resolution will allow. If the content space is still not big enough for the given table, we’ll continue to show the popup viewer.

    For some templates, like infoboxes, a static size is usually desired, and content coded to have a fixed width won't be affected by the shift to a fluid layout.

    Images and videos with standard coding will maintain their static size as well. However, tables with percentage-width coding can be used to display media so that it increases in size with the page layout.

    Main Pages
    The existing main page column tags will still function as they do today, with the right column simply reduced to 300px wide to match the right rail size on the rest of your pages. We know main page coding is often complex, with many containers and templates, and we've created help pages with some tips for making the transition easier when the time comes.  Here again, coding with percentage width is the best approach.

    Previewing Edits
    Readers on various displays will have different viewing experiences. But most editors only have one screen in front of them. To help the conscientious editor know what others will see, we're planning on introducing some additional preview options. In addition to seeing, by default, how the published content will look on your own display size, you will also able to see the page at its minimum and maximum size.

    This updated preview function is not part of the initial Darwin release, but will be coming soon! Watch for future blog post letting you know that you can check it out on the Community Test Wikia.

    What will I need to change?
    There will likely be changes necessary for wikias with heavily customized CSS. But since Darwin's wider release date is still to be determined, you'll have plenty of time to experiment with changes by using the Community Test Wikia and discuss options with other users in the Darwin Forum. We've prepared a help page on Darwin's CSS with some technical details, and as we approach a wide release, Wikia's Community Development team will be available to help out as needed.

    With regard to displaying general content, those who have a detailed eye may want to adjust their paragraph breaks, templates, tables, etc. to make them look as nice as possible. But you can be confident that in most cases, no updates will be needed on your article pages and your readers will only benefit when fluid layout arrives on your Wikia community.

      Loading editor
    • So "without the spin" you have two sizes to view articles in based on what you are seeing it on? How will size be determined, and can an editor (signed in editor anyways) choose one instead of the other? Looking at "Community Test Wiki" I can't even tell you'll changed anything. Perhaps, I should be glad I can't tell. (I'm not a fan of change, the less the better.)

        Loading editor
    • Devilmanozzy, it means the article width will grow smoothly as you increase the browser width, between the minimum and maximum. The changes will be most obvious on small screens (right column moved) and large screens (a wider content area).

        Loading editor
    • Cool Beans. I just tried "Control +" and "Control -" in google chrome, looks good zoomed out a bit. I am worried about tables and "constructed things" on wikis I edit with this feature. But I can't say I didn't see this coming as everyone but me and my cat has a cell phone of some sort doing the online thing. Adapt I will. I'll be following the developments of "Darwin".

        Loading editor
    • YES! The old space it has from Monaco will be back. This should have been done way long ago, and this is great news indeed. This brings our old style on our old wikis to return if this is implemented.

        Loading editor
    • This seems like a cool new feature. More content size is awesome, though this will be pretty annoying to organize content and files and infoboxes and navigation templates etc. because you can never have the perfect lay-out for every user for every screen unless you try out the page on every possible screen size. But apart from that, this is goooood stuff.

        Loading editor
    • Honestly, I'd prefer the fixed layout if it was simply bigger. But glad to hear their transitioning back to a fixed layout; this will make many editors happy, and many wikis display better on bigger screens.

        Loading editor
    • So I did some tests, and here's what I think I've found out: At the smallest without rail the min-width is about 750px. Now if I size up my viewport to the point the rail appears, the content width is about 670px. I would have thought if that's the width the rail appears it, then the minimum width without the rail would also be ~670px. Which is also a nicer figure as people, like me, may set a window at half-screen (though 650px might be the best... for my resolution anyway).

        Loading editor
    • I remember a few admins (maybe it was only one very vocal one, actually) that quit wikia because they modified some Mediawiki stuff specifically to create a fluid layout, but then were rebuffed by wikia because changing to a fluid layout was "against the terms of use" and interfered with ads being displayed. Have you got a response to this situation that I could pass on to the fellow? User:BBilge, I think it was.

        Loading editor
    • I can't edit

        Loading editor
    • This is a really good change, it makes the two areas of background uniform between users so it's easier to make a skin that can fit all screens. Not to mention, a much more efficient usage of screen real estate for higher res displays. Nice!

        Loading editor
    • TehAnonymous wrote:
      I remember a few admins (maybe it was only one very vocal one, actually) that quit wikia because they modified some Mediawiki stuff specifically to create a fluid layout, but then were rebuffed by wikia because changing to a fluid layout was "against the terms of use" and interfered with ads being displayed. Have you got a response to this situation that I could pass on to the fellow? User:BBilge, I think it was.

      In Fixed Width, if a user modifies the layout to make it fluid, it definitely would interfer with ads displaying properly, especially ad skins, because our ad serving system wouldn't be able to tell a user had made the layout fluid.  Since we're (Wikia) creating the Fluid Layout, we've also modified our ad serving system so that it will display ads properly, which is why it's not a problem for Darwin.

      Basically, we have to do work on our end to make sure ads still display correctly depending on the layout - and our systems can't serve ads properly if the layout has been modified by a user.

      Hope this helps answer the question.  :)

        Loading editor
    • Having a changing width isn't a completely new thing on Wikia. Occasionally, when I check up on my wikis during the day, I'll usually do it on my phone in the Oasis skin. That already resizes content for the (much) smaller browser by making the content area skinnier, and has meant I've been thinking about this for longer than maybe some other users have. I actually think it would be a pain in the backside to have to edit for a fluid background. Consider for a moment header templates like some wikis have to mark articles for deletion, as stubs, or even just to mention the type of content, such as real world. If those templates are currently designed to work beside a (static) infobox, how will using percentages help? In some skins, the templates will be too big and overlap the infobox. In other sizes, it will be too small and leave a gap between them. In other places, people have worked images so they fit in a certain way beside a body of text. Having longer line length could affect this as there will be fewer lines between images which, on an image heavy page, could look bad. Another example of where it would go bad for images is when using them on front pages. On the front page of w:c:drwho.answers, we use a full-width image as a sort of a background/heading, and that would look off if in a fluid layout because the image then either wouldn't take up the whole width or it will go out of the content area. If using percentages instead of pixels, the image then will look bad on bigger screens because the image will be pixelated from being grown too large. Also background size, which I see you're already thinking about. It will be just that much harder to try and make content layout look good on all window sizes that I think it's more trouble than it's worth. However, I wouldn't mind if Wikia updated its standard size to the bigger content width. In fact, that would be quite good. I just think having something fluid will just make things harder on editors. Also, working in pixels is much easier than working in percentages, imo.

      Also, I hate the pop-out table idea. I've seen a few around when people have made tables too big, and they look horrible. Better just to have the table resize with the window.

        Loading editor
    • One more critique of the new fluid layout as it is here in Central, now I am seeing it on my phone. Here in the forums, the latest forum activity module is forced to the bottom on the page. This is annoying. I actually prefer having the side bar while in my phone and just zooming around to see what I need to. A fluid latout is more of a pest than an advantage. Although I can understand not showing the background because of load times. It still feels weird though with forum threads being more on the right than in the left of the centre of the page.

        Loading editor
    • Imamadmad wrote:
      One more critique of the new fluid layout as it is here in Central, now I am seeing it on my phone. Here in the forums, the latest forum activity module is forced to the bottom on the page. This is annoying. I actually prefer having the side bar while in my phone and just zooming around to see what I need to. A fluid latout is more of a pest than an advantage. Although I can understand not showing the background because of load times. It still feels weird though with forum threads being more on the right than in the left of the centre of the page.

      Almost all phones get the WikiaMobile skin, so Fluid Layout won't effect that.  Forums are off to the right on phones.  On the Wikia skin (which you'll see on tablets and desktop) you shouldn't run into that problem.  Let us know if you do!

        Loading editor
    • Imamadmad wrote: Having a changing width isn't a completely new thing on Wikia. Occasionally, when I check up on my wikis during the day, I'll usually do it on my phone in the Oasis skin. That already resizes content for the (much) smaller browser by making the content area skinnier, and has meant I've been thinking about this for longer than maybe some other users have. I actually think it would be a pain in the backside to have to edit for a fluid background. Consider for a moment header templates like some wikis have to mark articles for deletion, as stubs, or even just to mention the type of content, such as real world. If those templates are currently designed to work beside a (static) infobox, how will using percentages help? In some skins, the templates will be too big and overlap the infobox. In other sizes, it will be too small and leave a gap between them. In other places, people have worked images so they fit in a certain way beside a body of text. Having longer line length could affect this as there will be fewer lines between images which, on an image heavy page, could look bad. Another example of where it would go bad for images is when using them on front pages. On the front page of w:c:drwho.answers, we use a full-width image as a sort of a background/heading, and that would look off if in a fluid layout because the image then either wouldn't take up the whole width or it will go out of the content area. If using percentages instead of pixels, the image then will look bad on bigger screens because the image will be pixelated from being grown too large. Also background size, which I see you're already thinking about. It will be just that much harder to try and make content layout look good on all window sizes that I think it's more trouble than it's worth. However, I wouldn't mind if Wikia updated its standard size to the bigger content width. In fact, that would be quite good. I just think having something fluid will just make things harder on editors. Also, working in pixels is much easier than working in percentages, imo.

      Also, I hate the pop-out table idea. I've seen a few around when people have made tables too big, and they look horrible. Better just to have the table resize with the window.

      Actually, working in percentages solves your problem of header templates and infobox templates colliding or overlapping. You just have to make sure that the header template + infobox is less than 100% (don't forget to leave a couple % for padding. This will cause the page to scale much better than using "infobox = 300px", "header template = 1060px" for your sizes. (BTW - I usually use infobox = 30% and notice (or header) templates = 65%)

      Once you get used to doing it, using relative sizes (%, em, etc) is actually easier than trying to get a ruler out and trying to figure out the size needed based on every resolution or screen size possible.

      You can actually fix part of your table being too big for your screen issue by giving it a width of 100%. Then, no matter how big/small the screen, it will always be 100% of the content area. You will still need to convince editors not to create tables that need "a million" columns worth of content, though.

        Loading editor
    • Susanolivia wrote:

      Imamadmad wrote:
      One more critique of the new fluid layout as it is here in Central, now I am seeing it on my phone. Here in the forums, the latest forum activity module is forced to the bottom on the page. This is annoying. I actually prefer having the side bar while in my phone and just zooming around to see what I need to. A fluid latout is more of a pest than an advantage. Although I can understand not showing the background because of load times. It still feels weird though with forum threads being more on the right than in the left of the centre of the page.

      Almost all phones get the WikiaMobile skin, so Fluid Layout won't effect that.  Forums are off to the right on phones.  On the Wikia skin (which you'll see on tablets and desktop) you shouldn't run into that problem.  Let us know if you do!

      WikiaMobile is an option, but a bad one. Any skin that can't be edited in normally is useless to me. Also, the forum layout is rubbish on WikiaWobile. Each post is so far over there is only a few words per line. Much more convenient to just use Oasis/Wikia and zoom in.

        Loading editor
    • My screen width is 1920 pixels. That means the text width is around 200 characters. That's very difficult to read. It becomes difficult for the eyes to maintain the precise horizontal movement. And it becomes even more difficult to find the beginning of the next line. Frequently the reader will get lost in the text. Reading efficiciency declines and so will the number of readers who make it to the last line. That's actually old news. There has been plenty of discussion and research about this topic. The Elements of Typographic Style specifically recommends 45 to 75 characters per line for block text. Granted, those recommendations were made with print in mind, but apart from wikipedia - which is a terrible example in this regard - I can't think of a single successful web site that does away with that recommendation completely. Unlimited character length is a bad idea.

        Loading editor
    • I think the fluid layout is a great idea

        Loading editor
    • Having the sidebar shift to the bottom on mobile is not a good idea. I use the siderail a lot. It would be a heck of a lot easier to just slide the entire screen to the left whenever I want to see/use the siderail, than to have to scroll, scroll, scroll down to the bottom. However, at least having the search bar go to the top in such instances is great, as is the wider article space!

        Loading editor
    • SpikeToronto wrote:
      Having the sidebar shift to the bottom on mobile is not a good idea. I use the siderail a lot. It would be a heck of a lot easier to just slide the entire screen to the left whenever I want to see/use the siderail, than to have to scroll, scroll, scroll down to the bottom. However, at least having the search bar go to the top in such instances is great, as is the wider article space!

      I'd like the idea of a side arrow or whatnot that can be touched and the side rail becomes visible.

        Loading editor
    • That means I need to f*** up my whole main page? Great.

        Loading editor
    • SpikeToronto wrote: Having the sidebar shift to the bottom on mobile is not a good idea. I use the siderail a lot. It would be a heck of a lot easier to just slide the entire screen to the left whenever I want to see/use the siderail, than to have to scroll, scroll, scroll down to the bottom. However, at least having the search bar go to the top in such instances is great, as is the wider article space!

      I agree with SpikeToronto and DEmersonJMFM. Rather than having the siderail move to some random location based on screensize, I would prefer to use left/right/bottom/top menus that are permanently anchored and can be expanded (from anywhere in the page) for permanent navigation features (like Search, Recent Activity, etc).

        Loading editor
    • Is it possible to enhance JPEG recompression, too? PNGs are too large for mobiles.

        Loading editor
    • Why not just force the whole large page size onto all wikis instead of having it so short, having a short wiki page is annoying for those who have infoboxes they can tell, for infoboxes take up half of the top area of an article. So I say it should be as long as Wikipedias page lenght is and not change as much as you zoom out

        Loading editor
    • I like this idea of a "fluid layout", but it would have been much better done before Wikia drove away a bunch of wikis because they didn't want to do it when they went to Oasis. Oh well, water under the bridge.

      I just wonder if Wikia will actually change anything based on feedback. Historically they tend to only respond to feedback if they were already thinking about it internally. Agility is not something I've seen alot of from Wikia. They just change stuff and try to fix the fallout before the damage gets too bad. Sometimes they do it too late.

        Loading editor
    • I was initially excited about this new layout, since I though it solved one of the problems of the Oasis skin. I was initially thinking it was going to expand the available width of articles on big resolutions. But that's not what actually does: On big resolutions, Darwin is exactly the same as Oasis (it doesn't even comes close to wowwiki increased width). Nothing changes. The only change is on small resolutions, where it moves the side rail so the view can srhrink without shrinking the content.

      That's very sad, and an incomplete improvement.

        Loading editor
    • Exactly!

        Loading editor
    • Ciencia Al Poder wrote: On big resolutions, Darwin is exactly the same as Oasis [...] Nothing changes.

      I don't know what you're talking about. On my laptop, there is a very obvious difference between the width of the content area on Community Central wiki (which uses Darwin) and the other wikis I edit (which don't). Is it possible that your screen or zoom level just so happens to make the content area the same size between Darwin and Non-Darwin wikis?

        Loading editor
    • The page is very much wider on a 1920*1080 monitor for me

        Loading editor
    • Darwin mozg.th.png

      Wowwiki x769.th.png

        Loading editor
    • Aww, I can see what Ciencia means now.

      On normal window, nothing has changed. But zooming your browser screen out and you'll see the width expand... something that we're not what exactly expects it to be.

        Loading editor
    • ikr

        Loading editor
    • Mckrongs wrote:
      Aww, I can see what Ciencia means now.


      Sorry. I don't :(

        Loading editor
    • Try wikitionary.org or dictionary.com

        Loading editor
    • Picture one on the original post is the normal browser window size. Picture two is how it will look like when zoomed out. I don't know on other browsers and on Macs but on Google Chrome and Firefox you can zoom the browser window in and out by pressing Ctrl and + (Zoom In) or Ctrl and - (Zoom Out).

      All in all that's just the change here. No width increase at all for normal window size.

        Loading editor
    • Here's what I see on my 1920 by 1200 display:

      normal zoom large zoom
      small window large window
      textarea is as wide as in Oasis textarea is ridiculously wide textarea is as wide as in Oasis
        Loading editor
    • Some strange stuff is happening on WoWWiki and I'm not sure if it is the new fluid layout or just usual strangeness of WoWWiki's unique skin. My window is about 1300 px wide, but the edit area (I think I have the wide mode turned on) is still bigger and doesn't quite fit.

      I'll have to find out whether this is fluid layout stuff or some other issue.

        Loading editor
    • Callofduty4
      Callofduty4 removed this reply because:
      duplicate
      15:10, September 1, 2013
      This reply has been removed

      What is "normal window size"? I am looking at Wikia on a 1920*1080 monitor and there is a significant width increase. On my laptop, which is 1366*768, there is no width increase because the current Oasis page width fits that screen pretty much perfectly. That's intended behaviour.

      I'm not really understanding your point about zooming in and out... that does nothing for me except zoom in and out like I would expect it to...

        Loading editor
    • Mckrongs wrote: Picture one on the original post is the normal browser window size. Picture two is how it will look like when zoomed out. I don't know on other browsers and on Macs but on Google Chrome and Firefox you can zoom the browser window in and out by pressing Ctrl and + (Zoom In) or Ctrl and - (Zoom Out).

      All in all that's just the change here. No width increase at all for normal window size.

      What is "normal window size"? I am looking at Wikia on a 1920*1080 monitor and there is a significant width increase. On my laptop, which is 1366*768, there is no width increase because the current Oasis page width fits that screen pretty much perfectly. That's intended behaviour. Here is Community Central and here is WoWWiki on my monitor.

      I'm not really understanding your point about zooming in and out... that does nothing for me except zoom in and out like I would expect it to...

        Loading editor
    • .

        Loading editor
    • Fandyllic wrote:
      Some strange stuff is happening on WoWWiki and I'm not sure if it is the new fluid layout or just usual strangeness of WoWWiki's unique skin. My window is about 1300 px wide, but the edit area (I think I have the wide mode turned on) is still bigger and doesn't quite fit.

      I'll have to find out whether this is fluid layout stuff or some other issue.

      It's exactly 1200px wide on my screen. That's what it says in the CSS too. Is that not what you see? Or is it supposed to be something other than 1200px?

        Loading editor
    • This is what i see. Note how the widest without rail is far wider than widest with rail. That just don't make sense.

        Loading editor
    • The expectations here were that we were going to get our old space back from how it was back at Monaco, but in reality the Darwin update only expands the width when zoomed in or out and we still get the same width on Oasis on normal screen (100%).

      I hope that clarifies what I was trying to say.

      That's because your monitor is at 1024*768; wider monitors, seemingly those over 1440*900, experience wider content areas. Ironically, the non-Darwin Oasis page is 1030px, wider than your monitor. I get what you mean now - you want the full width of your monitor to be used for content space, like it is when you are zoomed in 110%?

        Loading editor
    • Callofduty4 wrote:

      The expectations here were that we were going to get our old space back from how it was back at Monaco, but in reality the Darwin update only expands the width when zoomed in or out and we still get the same width on Oasis on normal screen (100%).

      I hope that clarifies what I was trying to say.

      That's because your monitor is at 1024*768; wider monitors, seemingly those over 1440*900, experience wider content areas. Ironically, the non-Darwin Oasis page is 1030px, wider than your monitor. I get what you mean now - you want the full width of your monitor to be used for content space, like it is when you are zoomed in 110%?

      I think I finally get it too. The margin is fine with me though. There's a lot of a wiki's flavor in that margin. Making it small is fine, but making it disappear would subtract too much from the design.

      Personally I think that Darwin is a clear advancement for smaller screens. I checked it out on my netbook and I'm quite happy with it. But at the risk of repeating myself once too often: At higher screen widths the content area becomes too wide. That's a step backwards from Oasis to the indiscriminate full screen width of Monaco and Monobook. I actually thought all this time that one of the main goals of Oasis was to fix just that. It seems I was mistaken.

        Loading editor
    • Hmm... what was happening to me must have been a glitch, because now it seems okay.

        Loading editor
    • Thanks to all for helping to clarify that some of this feedback was specific to when a browser is zoomed. We did not focus on the "zoomed" experience during initial development of fluid layout. Browser zooming within a responsive layout is tricky and different websites handle it in different ways (some better than others). This is the feedback period, as we've made clear, and the perfect time to bring up things like this. We'll take a look at the zooming behavior as we make adjustments to fluid layout.

      To circle back and clarify on the thread's main topic — as detailed in the initial post:

      Susanolivia wrote:
      Darwin has a minimum article content space of around 700px, no matter what resolution you’re on. If you’re using a display that can support more than the 700px minimum, your content space will grow. For instance, the most standard resolution for users on Wikia is 1336px, representing about 20% of our total visits. With the fluid layout, users on that resolution will see an article content space of about 816px, an increase of 146px from today.

      So at any screen size (where the user has not zoomed in or out), there is an increase in article content space from today's 670px width. Bigger resolutions will show a more substantial change.

        Loading editor
    • BertH wrote: To circle back and clarify on the thread's main topic — as detailed in the initial post:

      Susanolivia wrote:
      For instance, the most standard resolution for users on Wikia is 1336px, representing about 20% of our total visits. With the fluid layout, users on that resolution will see an article content space of about 816px, an increase of 146px from today.

      This isn't true from the screenshots I've taken (where my screen size is 1440px wide). Please clarify if this is something it's going to change in the future or if there's a bug in the current implementation.

        Loading editor
    • Ciencia Al Poder wrote:

      BertH wrote: To circle back and clarify on the thread's main topic — as detailed in the initial post:

      Susanolivia wrote:
      For instance, the most standard resolution for users on Wikia is 1336px, representing about 20% of our total visits. With the fluid layout, users on that resolution will see an article content space of about 816px, an increase of 146px from today.

      This isn't true from the screenshots I've taken (where my screen size is 1440px wide). Please clarify if this is something it's going to change in the future or if there's a bug in the current implementation.

      Seconded. I'm using a 1336px display on my laptop, and I am seeing the old fixed width as well.

        Loading editor
    • Ciencia Al Poder wrote:

      Please clarify if this is something it's going to change in the future or if there's a bug in the current implementation.

      This is not a bug or a pending change. Unfortunately, some of the pixel amounts noted in the initial post were simply incorrect; an earlier draft of this post detailed more screen sizes and the wrong figures were left in the final version. The amounts in the initial post have been corrected. It remains true that there is an increase in article content space from today's 670px width, at any display size, which was a requirement from the start of this project. The changes are most apparent on tablets and larger screens.

        Loading editor
    • Will you fix the readability problems that arise when the content area becomes too wide?

        Loading editor
    • Pecoes wrote:
      Will you fix the readability problems that arise when the content area becomes too wide?

      Can you be more specific about the problems you are seeing? As noted in the inital post, the maximum width, and the font size increase, were established to prevent such problems.

        Loading editor
    • There's apparently no upper limit for the width of the content area. On larger displays that results in a text width that makes reading very uncomfortable. Take a look:

      Too-wide

      To quote myself:

      Reading efficiciency declines and so will the number of readers who make it to the last line. That's actually old news. There has been plenty of discussion and research about this topic. The Elements of Typographic Style specifically recommends 45 to 75 characters per line for block text. Granted, those recommendations were made with print in mind, but apart from wikipedia - which is a terrible example in this regard - I can't think of a single successful web site that does away with that recommendation completely. Unlimited character length is a bad idea.

      And:

      That's a step backwards from Oasis to the indiscriminate full screen width of Monaco and Monobook. I actually thought all this time that one of the main goals of Oasis was to fix just that. It seems I was mistaken.
        Loading editor
    • As noted in the initial post, there is a "maximum article content space [of] 1270px". It is not unlimited.

      Our Design team did a good deal of research, looking at studies on this issue, responsive layout design trends on the internet, industry standards and past feedback from Wikia users. They also considered common use cases on Wikia (text-heavy articles, articles with and without images and infoboxes, etc.) and we feel confident that the current maximum in Darwin is a good middle ground.

      Do you yourself find the Darwin maximum uncomfortable as a reader? Or was your concern related to the notion that it was truly unlimited?

        Loading editor
    • Ah, yes, I missed the fact that there's an upper limit. Sorry about that!

      Still. I'm not convinced that your design team did enough research, as the upper limit for CPL (charactes per line) lies way outside the norm. I honestly cannot think of any major web site (disregarding Wikpedia for a moment) that has more than 120 CPL. The standard seems to be somewhere between 60 and 80 CPL. The 200 CPL of Darwin is an extreme outlier. Reading lines that are so overly long is uncomfortable and I usually leave web sites that force me to read such overly wide texts immediately. Maybe I'm alone in this, but the fact that I was taught never to set text this wide in art school and the fact that it violates common practice leads me to believe I'm not.

      On top of that Darwin doesn't handle zoom gracefully. The layout jerks around and reproportions every time I hit Ctrl-Minus or Ctrl-Plus. That's rather disorienting and unsightly. If you do want to set the text in a way that forces me to zoom, you should at least make the zooming comfortable.

        Loading editor
    • Pecoes, I think you should really distinguish between reading a book and reading a page with images and templates on one or both sides and wide tables with lots of information.

      The standards you talk about are probably good for blog posts, not for the rich-content articles we have in our wikis as we already demanded since Oasis was first introduced.

        Loading editor
    • BTW: Are you about to increase the standard size of image thumbnails, too?

        Loading editor
    • Pecoes wrote: Ah, yes, I missed the fact that there's an upper limit. Sorry about that!

      Still. I'm not convinced that your design team did enough research, as the upper limit for CPL (charactes per line) lies way outside the norm. I honestly cannot think of any major web site (disregarding Wikpedia for a moment) that has more than 120 CPL. The standard seems to be somewhere between 60 and 80 CPL. The 200 CPL of Darwin is an extreme outlier. Reading lines that are so overly long is uncomfortable and I usually leave web sites that force me to read such overly wide texts immediately. Maybe I'm alone in this, but the fact that I was taught never to set text this wide in art school and the fact that it violates common practice leads me to believe I'm not.

      On top of that Darwin doesn't handle zoom gracefully. The layout jerks around and reproportions every time I hit Ctrl-Minus or Ctrl-Plus. That's rather disorienting and unsightly. If you do want to set the text in a way that forces me to zoom, you should at least make the zooming comfortable.

      I actually like having a large amount of content area. If a page has too much text, break it up -- use paragraph tags, images and other content.

        Loading editor
    • I don't really have an issue with large content areas personally, but I do understand where Pecoes is coming from. Overall, I think that large content areas are appropriate for encyclopaedic sites... so I am glad Darwin allows for larger content spaces.

        Loading editor
    • Pecoes wrote:
      On top of that Darwin doesn't handle zoom gracefully. The layout jerks around and reproportions every time I hit Ctrl-Minus or Ctrl-Plus. That's rather disorienting and unsightly. If you do want to set the text in a way that forces me to zoom, you should at least make the zooming comfortable.

      We are taking a look at the zoom behavior, based on similar earlier feedback.

      Defchris wrote:
      BTW: Are you about to increase the standard size of image thumbnails, too?

      There's no plans for that at this time. Is that something you'd like to see?

        Loading editor
    • BertH wrote:

      Defchris wrote:
      BTW: Are you about to increase the standard size of image thumbnails, too?

      There's no plans for that at this time. Is that something you'd like to see?

      Well, if the content area grows, I think it might be worth thinking about. (Together with lowering the jpeg compression a bit) ^^

      180 pixel standard width - which can be overridden, of course - seems to be a bit low if the font size grows, too.

        Loading editor
    • It seems Muppet wiki has this. I use Monobook primarily and saw the effect, everything is squished.

        Loading editor
    • Decembirth wrote:
      It seems Muppet wiki has this. I use Monobook primarily and saw the effect, everything is squished.

      Thanks, we're checking with the Muppet Wiki admins about this, it's not related to Darwin. Fluid layout does not inlcude any changes to Monobook.

        Loading editor
    • Okay. Thank you.

        Loading editor
    • Thankfully all this seems to be is a scaling thing rather than some retarded layout change. Although I have never noticed any differences on a square monitor or a widescreen before.

        Loading editor
    • The change is only notable from a tablet or a large screen

        Loading editor
    • Can you please tell me how to get this layout? Because I want it on my 4 wikis.

        Loading editor
    • It should be active there and on every other wiki already as of today.

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

Around Wikia's network

Random Wiki