Not editable
 | Please leave your comments on Talk:Reading/Web/Desktop Improvements. Thank you! |
@AHollender (WMF): Is there some reason why not to do the screenwidth toggleable in same way than the sidebar is collapsible? In that way you could dart most of the critic and also you could get actual data how many users are using narrower or wider screens. It would be also an useful feature.
Second question is that if you arent doing it by yourself then would it be possible that somebody else would do it submit a patch?
Hey @Zache — I agree that we should offer the ability for people to toggle the content width between a more narrow and more wide option. In terms of how we might achieve that I think there are at least two ways:
1) a bit further along in the project our team is going to look specifically at the use case of people with large screens. The same way that we want people with small screens to have a good experience, we also want people with large screens to have a good experience. There's a chance that at that time we would work on the type of toggle you mentioned
2) a developer could certainly build this type of functionality as a gadget. I think it would be great if this happened sooner rather than later because it would help us understand how many people would want/use this kind of thing, and could help with our own prioritization process. And even if we didn't get around to building a more "official" version of the feature it would at least be there for people who know how to use gadgets.
Also, to keep in mind, we are still developing an improved table of contents experience and there's a chance that it will sit to the left of the article (on LTR languages). So from that perspective it might make sense to wait a bit longer before developing a gadget to toggle the content width.
Thanks for the answer, I actually made an added an gadget it to fiwiki's settings (Pienoisohjelma lisää sivun yläreunaan napin jolla uuden Vector-käyttöliittymän version saa koko näytön levyiseksi) after I readed discussion in fiwiki which included complains on the width limitation.
However, problem with user scripts and gadgets is that the gadgets javascript is executed after the page is loaded so there will be a visible "flicker" if the content is resized by the gadget. This will limit how well "toggle" can work in terms of user experience. It would be a lot better for the if the wanted state would be stored as a setting and it would be already in CSS when page is generated.
@Zache oh wow that's so cool. I've just tried it out. I understand your issue with the "flicker". I pinged @Jdlrobson who might be able to advise you on how to fix that.
I was able to least partially fix the flicker. I splitted it two different gadgets. One for toggle button and clicks. Second gadget is CSS-only and for initial "wide state" when page is loaded. The button will resize the page, but also toggle the CSS-gadget on/off.
Btw, do we have any stats how many users are using the new Vector in finnish Wikipedia? (or is there any method how to get weekly stats etc)
@Zache awesome — glad you have been able to make progress on that. Regarding the number of people using new Vector on Finnish Wikipedia, I've pinged @OVasileva (WMF) and @SGrabarczuk (WMF) who might be able to provide that information.
Limiting content width was tried in 2014. Other than 960px vs. 715px, what is being done differently this time?
@Pelagic — I have just re-read the 2014 discussion about 715px (link), which I assume is what you're referring to. I believe the main differences are:
- we are not limiting the width of special pages and other pages such as History
- we are updating the entire page layout such that a) the content is always centered on the screen, b) the sidebar never gets too far from the content, c) overall there should be less awkwardness
- we have a plan to experiment with a persistent table of contents further along in the project (link to more info)
- we are using the same width limitation on the editor so that the page you see while editing resembles the page a reader would see (not sure if this was part of the original design)
We realize that this is going to be a controversial change. It seems clear from past discussions that the preferences of certain users around information density is almost opposite from what we believe will be most beneficial to most readers: limiting the width. I hope that this can be resolved eventually, either by the introduction of gadgets/user-scripts that allow logged-in users to modify the width, or the introduction of "reading accessibility" features that provide this functionality.
I am curious to hear your thoughts and suggestions on this matter. Thanks.
Thanks for the reply, Alex, and my apologies for neglecting to link the page.
I was was interested to learn from that 2014 discussion that some editors purposely make the page really wide because they’re not reading the article but skimming its structure.
A recurring theme there was "if you want the lines shorter, then just make the browser window narrower". I do that myself when working on a large screen. But in real life I see a lot of users who always maximise their windows even when it's counter-productive. I could rant at length about that, but it deserves a separate topic/thread.
Something else that was controversial previously was defining the max-width in pixels rather than ems.
Right so regarding "just make the browser window narrower", I agree with the response that was something to the effect of: well we don't want people to have to adjust their window in order to have a good reading experience, it should just be good from the start. Also we might consider that there are people who would prefer a narrower column of text but wouldn't think to adjust the size of their window.
We're definitely making the assumption that the vast majority of people visiting the website want to read in a traditional manner (so to speak), which unfortunately means people who want a full-width experience are in the minority. We're also making the assumption that the page is still skim-able, though I think we should follow up with more research on that.
Still that just sucks. Period. I use a 1920x1080 for a damn reason, and this reason is NOT in order to have a 50% middle space with contents and two 25% blazing white column with absolutely nothing. It's just burn my eyes and annoy me a LOT, much more than a brick of text. I hate wasted space... and it's totally what it feels like. Images still sticking inside the goddamn content column while there are 50% free space all around. I feel like scrolling unnecessary, it's fill me with angers and frustration.
''Also we might consider that there are people who would prefer a narrower column of text but wouldn't think to adjust the size of their window.''
Fuck them. Fuck this people, plain and simple. We can't prevent tard to be tard, not at the cost of preventing other regular "smart" users from fully using their screens if they want it and, more important, NEED IT. Period.
And yes I'm a bit mad cause now I'm forced to log in just in order to read properly Wikimedia's project on my desk, but not only. Because I also see what will occure next. First you let us the option to go back to previous skin version and then, in couple months / years, you'll just stop do the maintenance on it (like you did for the default buttons bar) and if bugs or shits occure on previous version rendering you'll simply say something like "use the vanilla version or try your best to patch it yourself" and FUCK THAT.
When WMF devs will ever learn to listen their community ? Read the comments from 2014, almost no one want this.
I can tolerate 10~15% max of white space from each side, and it already means 192~288px waste blank column each side in my case. If you really want ease the reading so maybe think about a toggle button that switch it to a reader mode, like does some tablets.
It's not against personnally you AHollender, just against the whole dev bureaucracy system that want to absolutely push that nonsense while a lot of users don't like that.
@Vive la Rosière I can understand why this has upset you, and I am sorry that you are angry. Though I don't think the aggressive language you are using to communicate is necessary. Perhaps it is the result of some auto-translation, I am not sure. But I can hear you just fine without the curse words, I promise :)
People have different preferences, plain and simple. You want the content to take up your whole screen, others do not. At the end of the day the layout is not going to be perfect for everyone. As a starting point, when talking about line length, I think it's important to recognize that someone on a wide monitor might currently see lines that are over 18 (or 19, 20, ec.) inches long. According to the research we have found thus far, and in my personal opinion, this is not a good reading experience for most people. And we have been hard pressed to find other popular content websites that offer such an experience. So we strongly believe there needs to be some sort of limitation on how wide the content can get. Now of course some people, yourself included, disagree entirely and say that they content should always fill as much space as possible. That's fine, everyone is entitled to their own preferences and experience. However we do believe that the people with a preference for full-width content are in the minority. And again you may disagree, but until we've taken a proper survey from logged-in and logged-out users we cannot take the opinions of those who have written negative comments to be representative of the majority of users.
Secondly you commented upon some users who you call "tard" (which again, at least in English is an offensive term which I don't see the need for) and others who you call "regular" or "smart". I think it's important to state that we must include and support all users regardless of their technical expertise, language abilities, intelligence level, or any other criteria. I recognize that this might upset you further, but ultimately I think that the burden of customizing the interface to meet your needs is going to fall on the more experienced users, not the less experienced. Some people may not be familiar with how to adjust the zoom level, or perhaps they are using assistive technology which makes clicking the mouse difficult. We must make sure these people are well supported by the default experience. In short: we can make some improvements that the majority will appreciate, and then over time build back in some of the customizations and configurations such that most people can get exactly what they want.
Lastly you mention "I hate wasted space". I can understand that perspective. However I don't think it makes sense to fill the space just so it isn't wasted. We should create the best interface we can, and "wasted space" isn't a criteria I think is worth anchoring on. We focus on elements that add value, and whatever space is left over afterwards is fine. Perhaps you can make your window smaller and open another browser window to the side of it if it bothers you so much :) Other contributors have already begun to come up with constructive ideas for elements that could live in the margins. I encourage you to also think about that. Let's be constructive and collaborative and work together.
There are more notes on these topics on our FAQ page: Reading/Web/Desktop Improvements/Frequently asked questions#Why is the width of the content limited? Why is there so much white space?
Here is a user script that will allow you to toggle the content width to be wider: https://en.wikipedia.org/wiki/User:Jdlrobson/vector-max-width-toggle.js
I understand the need to provide a good reading experience to everyone, regardless of screen size, and I think that overall this is a good approach. However, I personally prefer to use a wide screen, and I do find it rather irritating that I'm unable to make use of its available width even when I want to. I typically have a browser with multiple tabs open, set at my preferred reading width so that I can have part of the destop or other windows visible at the side. With the new layout, my preferred reading width is effectively overridden within the Wikipedia tab only.
Following up on the comments within the FAQ, I would like the ability within Preferences to define my own default reading width.
When making substantial edits I normally pull in the window to make sure that what I've done will look OK on a smaller screen, and I'd be supportive of a feature that could easily show me what my edits would look like in the default layout for most users, even if I want to have my own personal default set to something different.
Empty space to the left and to the right of articles is really annoying. And this max-width is less than half the width of my 1920x1080 screen, thus text looks overly compressed and fused together to me which makes my reading experience in new vector theme mostly uncomfortable. Perhaps making line width a bit smaller than the default one would be good, but forcing it to take only as much as half of the screen is... Ugh. And I don't really want any elements that live in that excessively huge margin as I usually tend to remove such in text editors. So, I hope there will be some easy way to opt-out from this uninvited care of my reading experience and adjust custom width as I like.
@Adamant.pwn thanks for your feedback. The recommended line-length is not dependent on the size of your screen. So yes, the larger your screen is the more white space you will see. Eventually we will be experimenting with adding a table of contents and/or page tools to that area. You can opt-out of the entire experience simply by turning on Legacy Vector in your preferences. You can also opt-out of the max-width by using this gadget: https://en.wikipedia.org/wiki/User:Jdlrobson/vector-max-width-toggle.js. I hope those options are helpful to you.
What happens when I enlarge my font to make the screen readable?
Does the WMF assume that everyone has the same visual acuity? DragonflySixtyseven (talk) 18:44, 13 October 2020 (UTC)
Yeah, gadget makes it better, but it's not persistent and has to be toggled on every time I change pages...
I confirm, the margins are superannoying. And if you think the full HD is bad, I can send you a print screen from a WQGA monitor. :D I am having it hard to imagine how bad it is on some modern, 4K display.
I am having an impression that designers' aim would be much better achieved with some proper adaptive scaling.
This looks awful. I see "just use widgets" as a potential solution for users who don't like the new reading experience. Anonymous users don't have this luxury. This feels backwards, there should be a widget that allows users to turn 50% of their screen into whitespace if they want to. Please don't go make this garbage the default design that unregistered readers will be stuck with
Tl;dr - please ditch the margins and bring the auto-scaling, because the proposal makes things worse on a modern desktop.
Dear All,
MediaWiki has a very archaic UX based on hardcoded numbers of pixels, small font, clutter and laughably small thumbnails with the 220px width coming from an era of 15", 800x600 monitors in the year of 2004. It is high time to improve.
Unfortunately, this very proposal goes in a very '''bad direction''' and makes life on a modern desktop only worse. Instead of improving the paradigm and giving a website adaptive to the users' devices, it is trying to recreate and already old tablet look of 2010 - with hardcoded pixels, unadequate for modern desktops. It is a lazy design, copying the worst errors of today websites.
Firstly, it ignores the nature of the website and the latest design trends. The fad of tablet-friendly, wide-margin design has been very noticable in the "content consumption" pages, especially when the high hopes were placed with a new form factor (tablet) and cost-cutting with the "mobile-first" design. But it never made it right.
It has never landed so well in the "workspace", where every bit of space is being apreciated; and nowadays you can see some calls for a retreat to different paradigms in design. Moreover, we can afford to not follow the mobile-centered design, and provide the UX adaptive to the users' device.
Secondly, it is not bold enough. The proposal disappoints me personally, because it keeps the MediaWiki archaic where it is really, REALLY long in tooth (non-responsive design based on fixed pixel numbers, UX clutter, too small thumbnails on modern desktop), while it is blindly following a yesteryear's trend, adding superficial hurdles to read and write the content because of IMVHO misguided pursuit for legibility. It is like taking the worst from the two worlds.
The most glaring problem is the usage of fixed px and wide margins instead of auto-fitting on a computer screen. This issue will be only growing with the growing pixel width and physical sizes of the desktop screens. Even already on a WQGA or 4K monitor the proposed page '''looks ugly''' with nonsensical wide margins. And it will get only worse.
The pursuit is IMHO misguided, as it is focused on "limiting the text width", rather than on the overall experience (especially font SIZE, spacing) and the general UX of a person using a modern, large desktop screen.
The proposal quotes some random text of an IBM researcher. It is not even a scientific paper, it does not seem to be even reviewed or reproduced; we don't know which year it is from and what actual environment does it represent. Are these thoughts based on a 14" VGA screen, 14" 1368x768 laptop, or a 28" WQGA setup? Was font scaled as well? What was the font, actually? We don't know.
I was honestly trying to find a source of these margins and "up to 75 characters in line" space, but all I got was an echo chamber with no contemporary, real research to back it. But I failed, I encourage everyone to provide me some papers.
What I got was the insight that actually:
* it's the size, font, spacing which really matter
* long lines seem to be pretty fine on monitors
* some claims are rooted in the old guidelines from the times of printing press and paper - not really relevant for e.g. contemporary use cases, sharpness and e.g. distance from the screen.
https://www.viget.com/arti.../the-line-length-misconception/
https://pielot.org/pubs/Rello2016-Fontsize.pdf
https://uxdesign.cc/legibility-how-to-make-text...
As you can see, the 18pt font was recommended for Wikipedia. No margins or artificial limits. Just size.
Any contemporary research on actual, contemporary desktops (Full HD, WQGA and 4K screens of 24"-29" size) would be appreciated.
On top of that, please test on some modern desktop: 27", 28" WQGA and 4K monitors, as well as on modern 14" laptops with the same WQGA or 4K. These are the standards in the beginning of the decade; not complying with them makes any proposal irrelevant.
When you will have tested, you will know that the proposed page is actually uglier. :/
Thus, as it has been mentioned before - we desktop users have our high pixel density, large screens for a reason. And we will be having them more and more often, because these are current IT trends. Instead of imposing silly margins, please work on proper auto-scaling and an adaptive UX design.
@Aegis Maelstrom it would be great if you could provide examples of the user experience you envision. I understand that you disagree with the approach we're currently taking but I am unable to fully understand your proposal. It would be awesome if you could reference other sites that, in your opinion, properly balance readability (across a variety of screen sizes) with density/utility. Or better yet provide some mockups or a prototype. We have done an extensive review of popular information/content sites and have found nothing along the lines of what you describe, unfortunately.
Regarding your statement: "The proposal quotes some random text of an IBM researcher. It is not even a scientific paper" — you can find details about the research we've quoted here: https://link.springer.com/chapter/10.1007/11555261_59. It was a conference paper, presented at the IFIP Conference on Human-Computer Interaction in 2005.
Regarding not being "bold enough" — we do not have a goal about being bold. Nor is it a project goal to ensure that 4K monitors are filled with content. We are trying to make small, considerate improvements to the reading experience. Limiting line-length is a critical aspect and therefore we have decided to tackle it up-front. There are many more changes to come.
@AHollender (WMF) hi there, and thanks for the detail of the research you are using. Let me focus on this one now. I am afraid you it is proving my point, and I encourage everyone to revisit the paper you quote, as it 1) is quite anachronic 2) actually says it is far from being conclusive.
Firstly, the experiment setup is quite distant from the use case of 2021, or 2030. The paper from 2005 describes an experiment performed with two IBM T41 laptops (model from the year of 2003), with most probably standard 14" screens with an aspect ratio of 4:3 (nothing like contemporary 16:9 or 16:10) and XGA screen resolution (1024x768). What is more, a somewhat limited part of the screen was used (80%/9" vs. 40%/4.5") with a too small, 10 pt Verdana font. This is a setup nowhere near a modern desktop, or even a modern laptop. It is several generations behind the screens we need to address in the 2021-2030 decade.
Secondly, even under these circumstances the experiment was not really conclusive. "Making the paragraph width wider reduces the number of return sweeps required for reading [and increases the probability to read to the end!], but increases regressions and decreases [information] retention." The reason of the higher retention despite the shorter reading was not entirely clear, and "It would be interesting to repeat the histogram analysis...", as the text says. I can only repeat this call for more research, while recommending using contemporary and future screen sizes, also looking for a proper font, font size and spacing.
Besides these two points, I think the research itself is in some strong need of a replication, as e.g. results in the retention tests (average 1.25 and 1.75 good answers out of 3 questions!) say that something went REALLY wrong with the legibility of the text or the quiz itself - regardless of the line width).
Summing up: we need a contemporary, adequate test, with contemporary people, contemporary computers and some proper typography. 10 pt Verdana on some 17 years old XGA laptop is FAR from being a "modern desktop" or anything we should be aiming for.
@Aegis Maelstrom I agree entirely. I setup this phab task for that very reason: https://phabricator.wikimedia.org/T261174. I wish that we had greater resources at our disposal, however I am optimistic that we can find some clever way to do more research in an inexpensive way. I'm curious what gave you the impression that we are satisfied with the current research? The tone of your message, to me, feels like you are accusing us of not doing our research properly. I have tried to be specific about the limitations of the research we have found thus far, and try to always mention that we want to do more research.
Secondly I am curious what you think about this — do you think these are valid assumptions?
I agree that more research should be done and/or found. We are indeed making some assumptions however I think it is worth being specific about the assumptions we're making. The first assumption is that if longer line lengths were beneficial to reading we would see them out in the world more often. I am hard-pressed to find a popular website, or any printed material, that exceeds the suggested line length range. I am not saying that everyone else is automatically right about line-length, but I would expect to at least find ''some'' examples of line lengths in the 200+ cpl range if that was indeed better for reading (if you can find some please post them here). The second assumption is that the extensive amount of research on this topic has intentionally been focused on the optimal range. Without speaking to the folks who conducted the research (and I have started to reach out to them) there is no way of knowing why they didn't study longer line-lengths, but I do feel like this is a relatively safe assumption again considering how many studies are conducted within the same range. Lastly I think it would be valuable for you (and others) to further investigate your own personal aversion to the max-width. We have had some great conversations with those willing to dive a bit deeper on this topic and a few folks have found that there are other factors (mainly frustration about blank space) that are informing their opinions, rather than an actual dissatisfaction with shorter line-lengths in and of themselves.
(originally posted here)
Thanks for your thought partnership on this matter
I like the line length limitation. I am older and my eyesight getting worse.
I would like to be able to scale up the font to fill the window's width rather
than add blank panels on the sides which is useless space for me. ~~~~
Automated fontscaling and barscaling would make an actually useful improvement, increasing both legibility and the aesthetics.
The proposal at hand is a precise contradiction, as it makes the UX only worse. Not only it keeps the archaic, non-responsive pixels-hardcoded design, but also it imposes a very small font size on a modern desktop (esp. WQGA, 4K), and imposes these silly margins which even make the manual upscaling (zoom) impaired, as the resulting space is too narrow.
Did anyone on the team actually test it on some real desktop, with 27", 28" WQGA and 4K monitors, as well as on modern 14" laptops with the same WQGA or 4K? I guess not.
@Robert.Harker thanks for your question. Based on the lengthy discussions that took place during the 2014 Typography Refresh we thought that changes to the font-size would be even more controversial than changes to line-length. I agree that font-size is a critical aspect of readability and we do hope to experiment with improvements later on in the project, so please do stay tuned and please continue to share your thoughts and opinions. Thanks so much!
I tried using the French WIkipedia and narrowed my browser window to about half the screen width (I often do this if I wand to see two windows side by side). Rather than a nice responsive behaviour it keeps the fixed width and introduces horizontal scroll bars which is not great for UI. Image attached.
@Salix alba thanks for pointing this out, and for the helpful screenshot. We are aware of this issue and are working towards removing the minimum-width that is currently there. Once we've collapsed the user links and made a few other changes we will make that update and the site will be nice and responsive : )
