Looks like my analysis on the other post using Wikiless for comparison is wrong: the new theme does transfer about 50% more data and has double the uncompressed "weight" that the previous one did, for this article. Memory use similar, bouncing between about 215 and 230MB.
Yeah, I hate it, it introduced lots of white space (I'd say about 20-25% of the screen) on the right-hand side. I don't see how this new version [1] is better than this old version [2]
The reason for this is readability. Long lines of text are empirically bad for readability, making it hard for readers to find the correct next line.
However, the line length Wikipedia picked seems to be a bad compromise. At around 120 characters per line it‘s double the recommend line length (60 characters).
If you look at newspapers, magazines and books you will see the 60 character rule of thumb adhered to pretty exactly and thoroughly. It‘s just a typographical best practice.
On the web and on wider maximized screens the issue is always the white space. Newspapers solve this issue with columns. However, that‘s not a realistic solution on the web (not so much for technical reasons, mostly because scrolling is fundamentally incompatible with columns).
60 characters is way too short for comfort. Too much vertical movement makes it hard to keep track of the line I'm on. 120 is better but still too short in my opinion if the page is wide enough for longer lines.
> However, the line length Wikipedia picked seems to be a bad compromise. At around 120 characters per line it‘s double the recommend line length (60 characters).
Unfortunately, Wikipedia uses a lot of right-side floats, some of which are quite wide. They are also frequently referred as “on the right” in the main text, which can be quite jarring on mobile/minerva where they might be above or below.
I could imagine a breakpoint where those floats would turn into margin notes, but that sounds extraordinarily fiddly.
That is actually a nice idea (and I’ve seen designers’ personal pages that do do that), but would probably look too artsy on today’s web. Gestures on mobile are also quite married to the vertical direction, so unless you’re willing to switch directions depending on screen size (way too jarring) that’s going to be somewhat broken as well.
To read one full line on [2] moving my eyes is not enough, I have to move my head. It's tiring, and when you're at the end of a line it makes it harder to come back to the beginning of the next line. Just reading a few lines on your screenshot, I ended up reading the 3rd line 2 times because my eyes went back to the wrong line, and because the lines are long I forgot the beginning of the line I just read.
So yeah I'd say [1] is strictly better for readability than [2].
It seems like Monobook is the only skin whose styling matches all the boxes and tables used in articles. (Minerva makes a valiant attempt to restyle infoboxes but doesn't touch other elements like https://en.wikipedia.org/wiki/2020_Masters_(snooker)#Main_dr... .) It's forward-thinking, placing the search box in the sidebar where it doesn't take up valuable vertical real estate on widescreen displays. It doesn't try to shove controls in between the title of the article and the content of the article. It's even got a responsive layout for mobile devices!
I say they should have bumped up the font size a notch, added a max width option, and saved themselves thirteen years of redesign work. Web design truly did hit its peak in the early 2000s.
I find timeless most visually pleasing - it does bring some professional look to Wikipedia. And it also provides direct access to pages in other languages without additional clicks, which is important for me because it's the feature I'm using all the time.
I think "timeless" is ugly, unprofessional and not very usable. i'm happy about vector 2022, i think they did a really good job. but, of course, de gustibus non est disputandum.
For most old Wikimedia-maintained skins, the maintenance commits are largely automated build and translation changes, though they do still keep them kind of viable for modern features like notifications, or major architectural changes.
Hey there, developer here and I can confirm that we are still actively maintaining those skins and preserving them. We have around 101 skins that work with MediaWiki and 7 skins deployed in production.
Hey! What happened with the AFBTL a11y feedback on focus-order issues, like closing or hiding the language menu throwing focus back to the top of the page, or the ToC menu problems? Those seemed like a11y dealbreakers, but they made it through to GA.
Hey there. As I mention in my blog post, there are still remaining issues that we are aware of and will fix. We got some consultancy on the remaining accessibility issues, and they were graded with priorities. We took care of all the ones that were flagged as blockers, and are working through the rest of the list over the next three months. You can track progress if you are interested in https://phabricator.wikimedia.org/T318373.
Some of these are made a little more complicated as they involve different teams - for example the language button is owned by a team who works on a Asia/Europe timezone (compared to our US/Europe timezone).
Thanks, used this in conjunction with a url editing add-on [0]
Description: Wikipedia Vector Skin
Example URL: https://en.wikipedia.org/wiki/Joseph_campbell
Include pattern: https://en.wikipedia.org/wiki/*
Redirect to: https://en.wikipedia.org/wiki/$1?useskin=vector
Pattern Description: Auto Redirects to vector skin version
Advanced Options:
Exclude pattern: https://en.wikipedia.org/wiki/*?*
Feel free to toss a better way or an improvement for this if you end up doing the same. I'm sure the include and exclude patterns can be tuned, the add-on supports regex, otherwise you'll want a second rule for searches and such, but this should get a person started.
I've made a Regex Version, which should support international wikipedia articles once the new skin arrives for them too.
Description: Wikipedia Vector Skin
Example URL: https://en.wikipedia.org/wiki/Joseph_campbell
Include pattern: ^(https?://)([a-z0-9-]*\.)wikipedia.org\/wiki/(.*)
Redirect to: $1$2wikipedia.org/wiki/$3?useskin=vector
Pattern type: Regular Expression
Pattern Description: Auto Redirects to vector skin version
Advanced Options:
Exclude pattern: ^(https?://)([a-z0-9-]*\.)wikipedia.org\/wiki/(.*)\?
My initial take: I actually like this a lot. The body text is narrower which makes for easier reading. The sidebar with an updating highlight of current place in document is really nice too. I don't mind the "wasted space": Wikipedia is primarily about reading, and any well typeset book or web page should have generous margins so the line length is not too long.
My first take: it’s different so it sucks. The lack of visual separation between the main content and the menu on the left is atrocious.
Second take: oh wait, the menu in the left was completely useless and they replaced it with the table of contents for that particular entry. That’s actually a welcome change. I’ll get used to “different so it sucks” soon enough anyway, that’s my fault not theirs.
It’s kind of fascinating when you catch yourself having knee-jerk reactions and “watch” your brain correct them.
It says something about how we've (all) been trained to read the web that you find an empty margin more distracting and grabbing of attention than the previous thing that occupied that area of the screen -- a fairly useless list of wikipeida navigational links we had all learned to ignore.
I've been using Redirector for the last few years to redirect Wikipedia links to the mobile site because the interface is so much cleaner and the content so much easier to read. I'm super excited about this change because I can finally get rid of that browser extension.
I was worried about the narrow body impact on table data since wikipedia often has the most concise charts for comparison. Although the styling looks broken, at the least the data isn't hidden inside an inner scroll area
For 16:9 screen sure, old wikipedia is too wide but I use side tabs in browser so my browsing area is closer to classical 4:3 monitor and the old one fit very well (for me) on that.
I imagine there are a few ways to do it. I'd just have columns break at section headers. It'd also jive well with the wiki pic/quick-info right hand sidebar that's common
I'm sorry, but zooming is just... dumb... at least for me, sorry. Having a giant text doesn't help the readability - at least for me :( And it's not like changing window size only when visting Wiki is a good solution too - it's nuisance to change window size when you came for a quick 30 second read. At least for me.
Accessibility is individual. I'll be reading Wikipedia articles at 200% now, like I do for virtually all one-column layouts. And this Wikipedia layout has good responsiveness, so no worries.
I'm not saying you are wrong, but it is wrong for me. I have a browser with say 8 tabs open. When I switch between tabs, I don't want to have to keep resizing the browser geometry.
I think if you really want full-width text, you could write a little custom CSS to make it work how you want it. As it stands, I think the new design is a much better default for most people.
Also, zooming and changing browser window size is, while only a keystroke away, isn’t something I want to do just to make a site that should be optimized for reading text more legible. It should just default to that way.
In short, I’m sorry this doesn’t fit your flow. That’s frustrating. But I think this is a better design. Matthew Butterick’s Practical Typography seems to support this view. [1] (MB is a lawyer, typographer, and Racket programmer for those not familiar with his work.)
> I think if you really want full-width text, you could write a little custom CSS to make it work how you want it.
How? Seriously, if you have a way to do this that works for pages in general I'll be extremely grateful. I tried using a user stylesheet that said * { max-width: 100% !important } for a while, but that breaks too many non-root elements on all sorts of sites.
Whereas making the page narrow when it doesn't set a max-width seems very easy to do with a custom stylesheet.
I use the Stylus extension for Chrome (also available on Firefox) to write user styles for sites, mostly to improve the legibility of text, but for sites like HN and Reddit that I browse a lot I've customised their look and feel extensively to match my tastes. Creating a custom style for a site just requires you to click the Stylus button in the toolbar, click on the site name at the bottom of the menu to create a new style and open the editor in a new tab and then add your CSS and hit save. You can also search for existing styles for your current website that have been published online.
You can have one style apply to multiple domains, I have a simple one for making text black and setting the font size and line spacing which works on a dozen sites or so. You can even use SCSS or Stylus instead of plain CSS if you want.
> I use the Stylus extension for Chrome (also available on Firefox) to write user styles for sites, mostly to improve the legibility of text, but for sites like HN and Reddit that I browse a lot I've customised their look and feel extensively to match my tastes. Creating a custom style for a site just requires you to click the Stylus button in the toolbar, click on the site name at the bottom of the menu to create a new style and open the editor in a new tab and then add your CSS and hit save.
Yes, I'm talking about that kind of thing. It's trivial for people who want narrow sites to put a max-width on the root element that way. As someone who wants wide sites, how do I do undo all these designers' narrow widths without having to figure out manually what each individual site has done?
I use the dev tools to find the containing element with max-width by using inspect, clicking on the text and then finding which ancestor has the width, and then it's something like
which works in most cases. It's totally a pain to have to do on a new site, but once it's done then you never have to do it again - at least until the website does a redesign lol.
I don't do this personally, so I'm fuzzy on the details. I know of no way to make this work in general (how would you do that?) across sites, but Wikipedia pages follow a consistent format, so that shouldn't be too hard. Furthermore, someone[1] here on HN showed how you can control how the theme works.
My point: if you care that deeply about how Wikipedia in particular is laid out, you likely have the tools to force it to work that way. Meanwhile, the rest of us plebs get a better (from a typographical standpoint, not necessarily a case-by-case basis) default.
Not all uses of Wikipedia are the types of reading supported by works and research in long-form reading. Hell, many, many Wikipedia articles aren't long-form, and paragraph text is a minority of content on some table-heavy articles.
The issue isn't with width but a lack of user preferences, logged in and not. You don't need user accounts, cookies, persistence, or frankly even Javascript to change the content width on an article. The skin designer can set the best practice for a contrived ideal use case as the default, and still let anyone with other use cases expand the content's max-width to fill more space.
EDIT: Looks like they added one — there's now a "Toggle limited content width" button now appearing for me in the bottom-right corner of the wider desktop views.
Mac OS (and some linux desktops) seems to really expect you to manage windows by having them always be full screen and swiping between desktops. Which makes changing browser window geometry sub-optimal.
Even on desktops where it's reasonably easy, it's pretty annoying to have to resize the window when you go to different sites to get them to format properly.
> Mac OS … seems to really expect you to manage windows by having them always be full screen and swiping between desktops. Which makes changing browser window geometry sub-optimal.
That hasn't been my experience at all, in fact for me macOS works better when windows are mostly sized to fit their content. Windows and Windows-like Linux DEs is where I feel pressure to maximize everything.
I agree. Anecdotally, I also see more PCs with maximized windows in the wild, and more Macs with smaller windows. (I don't really see many people using Linux in the wild.)
I'm curious if you're seeing this on desktops? My sample of mac users is very heavily biased towards laptops (and I've only used macos on a laptop) - but I've seen the exact opposite.
Considering how the macOS maximize button works I’d wager this dichotomy is at least partway intentional by Apple, to stop you from falling into the Windows habit of “maximize everything even if it means half your screen is blank”.
It's not necessarily a function of the linux desktop. I use xfce, but it would be entirely easy to work with non-full-screen windows for my browser, emacs, clementine etc. However, I choose not, and use workspaces to spread things out.
Have been using this new theme since beta. I love the much cleaner look more than the previous one. One can always tune the CSS yourself at the user's preference near the theme selector. The only thing I need to adjust to my liking is to limit the line width:
main#content {
max-width: 40em;
}
For those who hate it: you will always have the option to switch back to the old theme.
I really hope any website could be as flexible as Wikipedia to allow users to write their own CSS.
> you will always have the option to switch back to the old theme.
The only issue is, you need to log in to do this. I don't want to have to log in to a website that I read, and never edit, to get rid of the giant distracting table of contents.
Also, VPN users who create or log in to accounts are radically limited or indiscriminately blocked.[1][2] Getting out of that state requires manual intervention.[3] Many VPN users don't use accounts as a result.
Firefox does. You have to go enable it in about:config, but it still works fine. Even has per-___domain filters so you don't even need the body-id attribute you mentioned. See top example in the README here: https://github.com/NapoleonWils0n/firefox-css
I don't like the extra padding that every designer is adding into every web site and application. I need to keep multiple sites/apps on my screen as I need to look at references, work on my tasks, and communicate with others. but every designer thinks I should maximize their site/app. It's forcing me to resize and move windows all the time.
The article addresses this by mentioning that they referenced research demonstrating text that is too wide causes people to read less comfortably and retain less information.
The page gets much less padded when you reduce the size of the window, because the padding isn't there to make blank space, it's there to enforce a maximum line width.
> text that is too wide causes people to read less comfortably and retain less information.
This seems like an excuse to force JS to enable ads & what should be the default that is toggled with the fullscreen button in the bottom right. It does not justify wasted width as the user can more easily set the text to the appropriate zoom than applying some custom CSS:
Zooming in now decreases the padding on the right, but has an offsetting increase in the wasted padding on the left contents until it completely disappears with huge text.
You're seriously expecting Wikipedia users to set up custom css to apply their reading preferences, just so that you personally don't have to deal with a different amount of padding?
Do you realize the level of entitlement and absurdity here?
One of the two options has to be chosen for the no JS, no query param / no login default - there is no entitlement and absurdity in that expectation. Using the max-width: none or similar as the default option has the benefit of allowing the user's browser keep the ability to monotonely scale the text density along with size using zoom as the displayed area would be nearly constant. It's rather arrogant & condescending to choose for a user a width that overrides what control they have with their window's dimensions, screen size, viewing distance & vision capability.
I don't understand the nature of your suggested link between ideas about maximum comfortable text column width are related to forcing JS. The size of the text column is generally set with CSS and not JS, no?
Ideally, CSS and not JS would be used to set the size of column text. But, that is not what Wikipedia is doing by default. Observe the behavior of the table on this page with & without JS: https://en.wikipedia.org/wiki/Binary_relation that occurs on not just that page, but all of the Binary relation pages. Note the dangling "in" at the top without JS with limited CSS styles on the table, but with JS the table becomes collapsed by default & the page text does not jump. The other JS only functionality that extends the page width that does not cause the page text to jump when the table is opened is the previously mentioned fullscreen "Toggle limited content width" button in the bottom right. Also, since I cannot edit the original comment here is the previous CSS condensed:
For whatever reason, especially with a bigger screen, I find that wider text becomes uncomfortable and somewhat exhausting to read. I'm not sure what the right portions/ratio are, but with a 27in screen it's definitely noticeable.
This has been studied a lot in design. Most people prefer line lengths in the 50-60 character region. Some studies show lengths up to 75 to be appropriate, but that’s about the limit. Past that people have a hard time keeping track of where they are and find reading to take more effort.
That's way too short for me. Somewhere between 120 to 150 seems a good minimum, 200 or maybe up to 250 are much better maximums, maybe even a bit higher. I lose my place easily when I have to change lines so damn much.
Even when I only have one maximized window up I hate all the empty white space. I've taken to just zooming in until the text fills the window. The new design handles the zoom so much better than the old one.
Mostly the repurposing of the left side for the table of contents, but also the width reduction. I only use half of my screen for my browser already, and on many pages, lines are just insanely long.
Personally, I nevery really minded having open space on websites. I never felt it made reading worse. Contrary, pages with little whitespace felt cramped and I lost my position now and then. But I understand that other people will feel differently about that.
I'd stil like the language selector below the table of contents in the sidebar.
I wish they'd let the old sidebar display as a third column if the viewport's wide enough. However, this:
> I'd stil like the language selector below the table of contents in the sidebar.
would also cover most of the reason I wish they'd do that.
[EDIT] Incidentally, what ever happened to 3-column layouts? They could keep the site menu on the left and stick the TOC on the right (keeping it visible all the time is definitely an improvement, and the thing I like most about this redesign). We used those layouts a ton when 800x600 4:3 was still a common monitor resolution & ratio, so surely it'd be fine on 16:9 and 16:10 monitors with 3x or more the pixels.
> They could keep the site menu on the left and stick the TOC on the right (keeping it visible all the time is definitely an improvement, and the thing I like most about this redesign).
Interestingly, the work toward implementing this new version of Vector allows any skin to decouple the TOC from the page content in MW 1.38+. It wasn't possible to move the page-generated ToC out of the content body before without resorting to JS/CSS hacks or implementing a parallel ToC generator in the skin or as an extension.
- Other languages are not available as a simple anchor tag anymore. They are hidden behind <button> elements. It's annoying for readers who consult their own language and en.wikipedia.org in the same session. It breaks my bookmarklet to change languages, which depended on something like `document.querySelectorAll('a')`
Not always, but it often is. Zoomed to 200% the new design is fine though. Content fills the entire screen and the floating table of contents disappears. Works for me at least.
And now the text is huge. Sounds like you either are sitting too far away from your monitor, or need to have your eyes tested if that actually feels comfortable.
I don't know if there's a "correct" distance, but I do have the monitor set fairly far back. Text is still perfectly readable at 100% it just doesn't fill the screen.
Humans read best when a line is around 10 words long. Longer, and it's easy to lose which line you're on when you go to the next one. The sidebar collapses if you resize to a narrower window, so I wouldn't call it wasted.
Yes, switching languages not being a single click any more is a major usability regression. They should at least allow to configure a set of “favorite” languages that can be directly accessed.
Even in the new design the line length is way too long. I get complaints about wasted screen space, but you really don't want lines of text blasting all the way across the screen either.
Fully agree. I always downsized my window to read a Wikipedia article (I use fairly large desktop monitors, but not a widescreen). The sentences were comically large making it really hard to see what the next line is.
Even in the new design they're still a bit larger than what I'd like.
And if they ever decide to add side banners you could probably permanently disable them in your preferences, just as you can disable the top banner asking for donations.
For people who don't like the new look, you can go to preferences->Appearance and select 'Vector (Legacy)'. It does require you to login first which is annoying but at least you can easily go back to the old look.
Edit: You can also have it take up the entire width by hitting the button in the bottom right. Doesn't seem to remember the change for me though so hopefully they add that in soon.
IIRC, the button in the bottom right is intended to not remember the change. To make the full width setting persistent, when you're logged in, go to Preferences -> Appearance, and disable "Enable limited width mode".
> You can also have it take up the entire width by hitting the button in the bottom right. Doesn't seem to remember the change for me though so hopefully they add that in soon.
Ooh good spot. That fixes my one issue, the bizarrely narrow column width.
Thank you! I think this is the first time I've logged in for 10 years.
I don't mind the current UI change, but I wish significant changes would come with a toggle button to let me look at the old and new renderings. I don't think it's possible to mentally "place" the improvements without side-by-side comparisons and affordances for finding edge cases where the new UI may be lacking.
Because it emphasizes the distinction between different parts of a website which in turn makes it easier to focus on individual things.
Why are so many people against white space when it hasn't been overdone? Obviously "overdone" means different things to different people but in this case the information that matters is still pretty dense.
I took some quick measurements. The previous version leaves 2% of my browser window as whitespace containing no images or text. By comparison, the new version is 53% whitespace. That seems pretty extreme to me.
You must be referring to the constrained width of the page, you can change that in the preferences if you really prefer having the text cover your whole screen.
There's a reason we have a character limit per line when writing code - it's much easier to read and understand short chunks of vertical text. Personally, I find it far more comfortable reading text which doesn't go above 600-900px in width and this has been a well known UX/UI guideline for the last 10 years. Having your eyes go from the far left to the far right of your screen is also very straining on any >21" screen.
These kinds of objections are predicated on the idea that white space is inherently wasteful.
But the real question is, why is it good to strain the eyes darting them across distances that large. What is gained by filling in the white space just to fill it?
I find shorter lines difficult to read, they require so much more eye movement than longer lines. When a site will let me I prefer the whole length of my monitor as the line length. In my experience I can read on my monitor for 12+ hours a day without eye strain.
Yes, though it also contributes to that "busy" look if you try to cram as many things as possible on the screen. The content might have a logical separation but spatially multiple types of that content would still be close to your focal point which makes them a distraction.
We live in an age where attention is a valuable currency and most people would likely leave your site if they can't quickly find the thing they're looking for. The fewer things you have on your screen at a time, the easier it is for them to find what they're looking for. It doesn't apply everywhere but I think it applies to a good amount of cases which is why lots of white space has become the norm.
Plug: I made https://github.com/phil294/density-userstyle which is a global userstyle to remove unnecessary paddings on common websites. Will probably have to add Wikipedia soon.
What, excuse me, the fuck. It's almost like all lessons from the Windows 95 era were forgotten (see e.g. [1], and the top comment of the HN discussion is worth a read as well [2]). No borders visually separating areas of different function, no visible indicators where the clickable area of an UI element (e.g. a button) is, and the content jumps to the right when opening the main menu.
> These improvements will make Wikipedia more welcoming and easier to use.
Above quote from the notification, which, again, has no visual borders. Just an insanely contrast-less sky blue on a white background.
Whoever has thought of this being a good idea should just go and resign in shame. Not every questionable design "trend" has to be followed.
I appreciate the table of contents moving to the left-hand sidebar, needing to scroll back to the top in order to navigate a long page or get a permalink was always an annoyance.
Sigh, yet another site that contorts into an absurd distortion of a mobile layout at a still spacious viewport width. Am I the only person with two windows up?
Pardon me asking, but what font (cipher? language?) are your tab titles and menus in? I don't recognize it, and I'm familiar with quite a few ciphers. (I initially thought it was another language, but it's clearly a transliteration of English.)
The biggest challenge has been keeping it legible while dense. Ultimately I’d like to give it aesthetics similar to a roman serif, but for now still experimenting with the basic construction.
Thanks, I hate it. Everything I loathe about "modern" web design made manifest here, and switched on without warning! At least I can turn it off in settings.
I browse with Safari on iOS with JS disabled by default. I do this for privacy and accessibility reasons (gotta stop those annoying popup modals, trackers and other annoyances).
One thing I noticed with Wikipedia with JS /enabled/, all the sub-categories of a topic are by default, closed.
But when I browse with JS disabled, all the sub-categories are /opened/ and I have the full article.
Since most people browse with JS enabled, this means they have to make additional clicks just to read the sub-categories.
Which leads me to question: which version is better? The JS where you have to make additional clicks, or the no-js version where you get the full article?
Floating table of contents on the left is a nice feature, but why is the styling so plain? It's just links floating in a void. Why do modern designers hate borders so much?
Because it works well without borders. You need to have a justification for adding things - what does a border add here? Other than making it feel more boxed-in?
Because it works without borders. Do you have any trouble differentiating the sidebar from the content? I'm gonna guess no. Hence, no need for a border.
Ewww what's with this terrible trend of wasting the majority of the screen space on a 16:9 monitor like this. Let it fit the window width, if someone needs it to be narrow let it adjust itself appropriately.
White space isn't wasted space. It makes the page infinitely more readable to limit line lengths. Yes, you could have reduced your window width before. No, you shouldn't have to do that to get a comfortable reading experience.
Making more than half the screen white space is wasted space. The point of resizable windows is to be able to adjust the content as desired, so it's pretty ridiculous to argue that everyone else should suffer wasted space because long lines are scary.
The Second Law of Interface Thermodynamics means that the software can't get more usable with time, nor can it even retain its previous level of usability.
> Research has shown that limiting the width of longform text leads to a more comfortable reading experience, and better retention of the content itself.
Is this actually true? I'm curious if anybody has sources for this and if it's a common UX practice. I tend to use wider windows than traditional 8:9 half-screens and this max-width practice drives me nuts.
Anecdotal, but personally I can’t stand reading overly long lines and don’t keep my browser window maximised. I’ve written user styles for certain sites in order to keep lines sufficiently narrow, and I’m one of the few people I know to use an 12.9” iPad Pro in portrait mode regularly.
I guess it depends on the person. I'm happy to accept that I'm strange, but I'd much rather read lines that mostly fill my screen with normal margins on each side than short lines in a long narrow column surrounded by an ocean of empty whitespace.
I can't be the only one who feels this way. I have yet to buy a book where 90% of each page is blank and there's just a tiny column of words down the middle of the page.
I hold books much closer to my face making it much larger in my field of vision than my monitor ever gets. Maybe there are people who have to physically turn their head from side to side in order to see the edges of their screens, but I'm guessing that's not terribly common and the amount of effort involved in sweeping your eyes across a page in a book is pretty similar to moving them across a screen
You're not the only one. I was also comparing this new design with what you get in books, I'd hate to have lots of blank space in a book (no matter the width of said book).
Thanks for the reply. I guess I am also strange, but I share your perspective.
At the very least, I feel like responsive options to toggle some of the various max-width CSS settings as an opt-in feature is worthwhile at least for reading-heavy sites like getpocket.com and news websites. I end up toggling these in Firefox / Chrome debugger and wish I could install extensions to apply custom code automatically but my employer does not allow this.
Aha, I was aware of the 80-character line limit for source code files, but wasn't aware it was a general accessibility recommendation. Thanks for the link!
Sure thing! I only know about it because I've worked on more AX bug reports related to text layout than I care to admit...
I think the 80 characters-per-line for code was a holdover from when IBM punch cards had 80 CPL, but I could be wrong there. I know American typewriters had about 80 CPL, so from a typography perspective maybe that's why 80 is the accessibility sweet-spot? If it's the ballpark equivalent to what we'd see on an 8.5x11 sheet of paper?
> Is this actually true? I'm curious if anybody has sources for this and if it's a common UX practice.
As far as I can tell, the people who say this are citing each other. And can't wait to reply when you say you find it unpleasant that it's actually scientifically ideal.
> Research has shown that limiting the width of longform text leads to a more comfortable reading experience, and better retention of the content itself
Surprised they did not include a citation for this research...
It seems they link to a discussion page [1], which references this document (I can't find a published version):
Computer text line lengths affect reading and learning
Peter Orton
https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf
But it seems that Peter Orton has published quite a few works in this area [2], [3]. Specifically [3] seems to note that with a less wide text column width readers are not statistically significant faster (but are a bit), but do see that for difficult reading content, the shorter width requires less re-reading then a wider one along with significantly better retention of the contents of the document.
Yeah, same reaction for me... I've always liked the small gradients on the top and the long list of things down the left side which I never click. Felt homely. I'll miss it.
I pray that one day colors other than just white and light grays return to the backgrounds of elements on the web. The zealot inside of me also wishes for skeuomorphism to make a glorious comeback, but I may not see that in my lifetime.
Lots of whitespace, lots of unnecessary animations, and lots of floating bars I'd never click occupying screen space. Hopefully this isn't too hard to fix with browser extensions.
The new layout style, most notably the centrered text blocks, has already been the default on a few other language versions of Wikipedia most notably fr.wikipedia.org.
Plus it now requires typing input, or you have to scroll through an annoying menu that sorts them by region and not importance.
Judging by the rave reviews this gets though, it seems that people who use the site as opposed to just wanting pretty design are in the minority. If most users don't even switch languages or such, I wonder how many readers check the citations and discussions before blindly believing what random anonymous authors tell them.
feels modern, but modern in a very web center way that i feel like very 2020s. it feels overly minimalist in a way that looks good in design sheets. love the table of contents on the side dont care for the modern trend of removing any and all color separation between distinct portions of the page.
Not that it matters to most people, but I'm surprised this didn't break the Dictionary app on my 10-year-old version of OS X (10.9 Mavericks). Wikipedia inside the Dictionary app looks basically identical to how it did a week ago, even though aiui it's basically just rendering the Wikipedia page (in a now terribly outdated browser engine) with some custom CSS. I wonder why it's still working.
My personal problem with it: the sidebar became wider. Now I have to disable it, but when I disable it, it disappears and makes the text lines much wider than what I'm used to. I'm one of those few people who don't maximize the browser to get a good acceptable line width. Wikipedia simply broke this :(
Oh, it's still hideous. Years ago I used to have a Safari extension that made Wikipedia look absolutely beautiful, with vastly improved readability. Such was the shock when that extension finally stopped working that I can still remember where I was when I suddenly saw the full horror of its regular design.
I would be curious to know what your beautiful version looked like. I find Wikipedia's styling so inoffensive that I don't understand how you could consider it "hideous." It's pretty much just black text on a white background. What about that causes such a strong reaction from you?
>When you are logged in to Wikipedia, the updated header will move with you as you scroll. You will no longer need to scroll to the top of the page to find what you are looking for, and you can focus on reading and editing instead.
How do people write things like this with a straight face
This reminds me of the Modern Wiki browser extension, which seems to have a lot of the same things but looks better to me at a glance. Also configurable, dark mode, etc.
It seems fine. I'm glad they didn't use a useless watered-down mobile design with excessively rounded components like Xfinity and other businesses have lately been doing. On larger monitors, there should be a full width option though.
I like it but I wish I could still have the available languages on the left column instead of having to click a button at the top. It would be great to pick some languages to be displayed on the left if there's a version available.
Finally. I have a big monitor and the line width is insane, glad they made it a more reasonable column layout, moving my head from end to end was getting very annoying that I had to use custom CSS instead.
I use all my applications in full screen mode usually, so resizing just for a single tab or moving Wikipedia into its own window would be annoying too.
The table of contents is a great addition! Whitespace/minimalist styling is of little importance as it will change with design fashions, while the table will stay a net positive.
A little odd though, that there is no left-padding in the table of contents, so the text is jammed right up against the left side of the page. Or is that just me?
I wish the search was better, you basically have to know the exact spelling of the thing you're looking for, and there doesn't seem to be any partial word results.
This is all fine and dandy, but it baffles me that in the Year of Our Lord 2023 Wikipedia still insists on separate domains/URLs for mobile v. everything else.
Agreed so much with this. The "mobile version" should be triggered by the viewport size, not by the subdomain. I was hoping this site redesign would have unified the mobile and desktop sites.
I've been using the Mobile Wikipedia extension(1) for Firefox which achieves the same effect. Actually mobile Wikipedia is lighter and loads faster than the new design.
Wikipedia is really becoming awesome, and for me is really a Wonder of the modern world.
Combined with tools like ChatGPT (or improved variants) for high quality translation of any article in any language, or combining submissions in several languages, or to get summaries or interactive explanations on some subject, this will become the most powerful tool of knowledge in history.
Lots of Wikipedia articles have become well-cited but that façade begins to break down as we dive into more niche topics. Editor wars are real and impossible to resolve most of the time due to how obsessive the involved parties are. Some of them are rather damaging to what narrative is being shaped on some of these articles. The power to control edit access rests in a small group of administrators/moderators who are relatively anonymous. This has served the site well so far but could be a weak point should something occur in the future that fundamentally challenges the integrity of Wikipedia.
> Lots of Wikipedia articles have become well-cited but that façade begins to break down as we dive into more niche topics.
A lot of the time they're just making the citation up. Wikipedia's page on French toast says this:
> The earliest known reference to French toast is in the Apicius, a collection of Latin recipes dating to the 1st century CE, where it is described as simply aliter dulcia 'another sweet dish.'[8] The recipe says to "Break [slice] fine white bread, crust removed, into rather large pieces which soak in milk [and beaten eggs] fry in oil, cover with honey and serve".[9]
The problem is that the reference to eggs doesn't exist in the Apicius. It comes from an "augmented translation" that was written in 1936; the eggs are original content from that "translation". The sidebar's claim that French toast originates in the Roman empire is a lie, and so is the claim that French toast appears in the Apicius.
This has been noted on the associated talk page forever, but (apparently) so what?
More on the obscure end of things, I'm also annoyed by the page on Chen Shimei ( https://en.wikipedia.org/wiki/Chen_Shimei_and_Qin_Xianglian ). It claims that Chen Shimei, a stock dramatic character which the page itself dates to 1594, is represents an attempt at character assassination against an official of the Qing dynasty, which began in the mid-17th century.
The claim (that the fictional character is based on a historical person) used to be cited to a newspaper article which did not itself cite anything. That citation has since been removed, but the claim lives on in the page without even a fig leaf citation.
Great examples and I absolutely agree. The problem here is the lack of visibility/attention due to these topics being extremely niche and largely inconsequential to the real world, yet a matter of principle for a site that tries to present its contents as factual knowledge. Sometimes it takes just one extremely dedicated user to completely lock down any changes on a particular topic and I've experienced this too.
How would I fix the errors? I know Wikipedia is lying to me. I can delete the information, which is pretty likely to get reverted. But I can't replace it with correct information; I have no idea when the idea of bread fried in eggs is first documented, and I have no idea whether or not the stock character of Chen Shimei is based on a historical person. For all I know Wikipedia is lying about the publication date of the story they cite. It's more likely they're lying about the character being based on a historical person, or the time when that person lived, but I can't tell, because there's no reference to anything I could look up.
You can add a "not in citation" or "dubious" tag to the reference that's there, or another cleanup tag: https://en.wikipedia.org/wiki/Wikipedia:Template_index/Clean.... A lot of Wikipedia articles are waiting for someone with the right references to come along (or for the right reference to come into existence), and until then the best anyone can do is insert warnings that the article is poorly cited.
Generally agree, although I've noticed a lot more normative language creep into articles ("unfortunately", "unluckily", "helpfully", etc) that really have no place in a resource purporting to be encyclopaedic.
I sense part of what drove this redesign is the fact that 4K and Ultrawide monitors are now common enough that designing to accommodate them cannot be ignored. That being said, I much prefer left-justification instead of centering the content and having massive whitespace islands to either side. I wish there was an option to left justify.
I'm the reverse of you in that I prefer content in the middle, as I sit in the middle of my screen and prefer to not have to be constantly looking to the left. I agree, personal choice would be nice.
That was my primary concern. Last thing I need is to have a JS-only Wikipedia added to the seemingly ever-groing list of websites that try to squeeze as much data from their visitors as possible and using "functionality and features" as an excuse.
Never occurred to me how better it feels with the table of content on the side, even though that's a common thing in document processors. UX is the ultimate one-way function. Hard to make right, easy to judge.
Worst choice ever all it makes is for 1 second of being able to read it then it goes all blurry and not to mention I have to put it on full screen width everytime.
2) Are they ingesting and modifying raw WP pages, and haven't updated for the new design? I ask because on desktop Safari there are tons of major layout errors (search field completely overlaps left menu; top logo image missing; page stretches one full, empty screenfull past the end of the footer; some text sits on top of section dividers rather than within the boundaries of a section) and wonder whether that's normal or just a temporary issue.
~2005 was peak Wikipedia aesthetic. All these flat, border less design decisions take away from intuitive UX and make things more... globally homogenous.
I don't need a header to follow me down the page, in fact I'd prefer it not to. On the very rare occasion when I need to scroll all the way to the top of the page, I have no problem figuring out how to do that. Feels like they're introducing a persistent UI element without a benefit. Benefit to me, anyway. Maybe they heard from a lot of users who were having trouble remembering where the header was, I can't say. I don't log in to Wikipedia, so this doesn't affect me much at present.
I'm not sure what value the collapsible table of contents is. Maybe it's useful on mobile, to help save screen space, but on desktop it would just be extra work for me to collapse the sections (which appear to be expanded by default). I have not found the length of the table of contents to be a problem, and I see the value of this structure as being that it allows me to see everything at once.
I get why having a maximum line length is good for readability. My reaction to this feature is negative, but I wonder if it's because I've gotten good at sizing Wikipedia articles the way I like them to be, by upping the font size and shrinking my browser window. Maybe I will come around on it, but my initial reaction was that I don't trust them to make the right decision for me, so I'd rather they just kept it flexible.
> I don't need a header to follow me down the page, in fact I'd prefer it not to.
I also don't need a header following me, but that's not really what they're talking about. They've moved the "section header/outline"-table-of-contents-links from the top of the document (where they would scroll off the screen) over to the left side, so what follows you is not the old set of headers to other parts of wikipedia that you never clicked, but rather the in-document, titled, relative links up and down the current page.
it's actually pretty useful. (which does not mean I'm embracing what the designers have done; given the general track record of designers and all the spurious white space here, I must assume that this useful bit was only accidentally left in :)
I don't need a header either, but I suppose for people editing wikipedia it might be pretty useful. It probably makes sense for wikipedia to optimize for the people providing the free labour slightly more than they optimize for the readers.
I usually use my adblocker to simply remove fixed headers. Hopefully there isn't anything critically important in that thing, because whatever's up there just isn't going to be seen. They're far too distracting.
I love the new design when not logged in. After logging in however...
> I don't need a header to follow me down the page, in fact I'd prefer it not to.
Edit: I wasn't logged in before, and thus wasn't shown the header you are talking about. Now that I see it, I'm with you and don't like it. Everything there could have gone in the sidebar above the ToC instead of wasting vertical space. I also dislike the extra non-persistant sidebar box shown when logged in that pushes the ToC down off the screen. That should be one side or the other, not in place of the ToC.
I find the persistent ToC to be very helpful, and the space is uses would have gone to waste anyway in full-screen mode, so it doesn't cause any harm. I don't love the menu button in half-screen (and presumably mobile) mode. I feel like they would have been better off with a full-width bar at that point since it blocks reading those top few lines anyway.
> I'm not sure what value the collapsible table of contents is.
For some articles the full multi-level ToC is longer than will fit on a single page, so you either need to allow collapsing, or scrolling of the side bar which never works well.
> I get why having a maximum line length is good for readability. My reaction to this feature is negative ...
I was nervous when I read this as well, but I like the results. They didn't over do it like so many websites to today with tiny newspaper-like columns, and will be more readable for the majority of people who never resize the browser. For me, I keep all my browser windows half-screen anyway and the redesign has smaller gutters than before, which is a win.
It is customizable. If you are logged in you can choose any of the designs they have had since the site was created, and if you don't like any of those, it lets you add your own custom CSS.
Reading your comment I got worried that there was going to be this giant banner permanently affixed to the top of the view. Taking a look, the actual implementation is very small and unobtrusive.
I don't know that I prefer it, but I also don't think I hate it. I feel indifferent.
I definitely love how they put the ToC off to the left. It's a great use of all the horizontal space on our 16:9 screens, and will make zipping around to different parts of a large article a lot easier. I'm willing to put up with the small banner in exchange for this.
Note to those not liking this, there is an option in the preferences to revert to the old Vector skin. No idea how long this will be but setting that preference may give them feedback that some users prefer the old layout.
The overwhelming majority of people will simply accept defaults.
To what extent Wikipedia's UI/UX assessment team are aware of this and can note a strong defection from any new features even where that defection represents only a small fraction of visitors I don't know.
Worse: sufficiently annoying / offputting features can simply lead to defection from a site entirely. A major problem with A/B testing is that if the cumulative effect of features has been to drive away those preferring the path not taken, then all your A/B tests are doing is validating survivorship bias.
(I'd give my experience with Reddit over the years, which has lead me to all but entirely avoid the site, or more recently a rather drastic turn in Twitter's dynamics affecting many long-term participants, as cases in point.)
Of the specific changes Wikipedia are putting into place, the maximum line length is a style change I've applied myself for about a decade now using various CSS browser extensions. I'm not much a fan of pinned headers, though that would be less an issue on desktop than my e-ink tablet. For that, I prefer the Desktop layout generally, but zoom the screen to cut off the left-hand sidebar entirely, which works fairly well until such time as I want to view an image fully zoomed.
I do find the sidebar useful on desktop. The present Mobile layout is annoying in multiple regards though it might be useful on a smaller device (I'm using a 13" e-ink tablet, which is generally not constrained for space.)
Are they? Wikipedia has great apps for iOS and Android.
I feel like some of these changes are meant to make better use of the landscape aspect ratios typical in laptop and desktop setups (i.e. moving the ToC to the left)
Initial reactions from watching the gif, coming in cold, having not seen the new design:
2003: Ouch. Yeah, that's bad.
2005: Great.
2011: Not worse. Maybe a little better. I have a vague recollection that some things that aren't well-showcased by a still got better with this one, but the still is at least not-offputting compared with '05.
2022: LOL are you serious? You cannot be serious. Please tell me this is unfinished.
All that padding. WTF. Someone accidentally hit "0" too many times in their CSS editor.
[EDIT] I mean I guess you need enormous swathes of empty space when you remove all other indicators of section division, but... like... just don't do that, then?
[EDIT 2] OK, I was like, "whatever, it sucks, but I'll get over it" until I read this: "When you are logged in to Wikipedia, the updated header will move with you as you scroll." Thank god when I try it on the site this doesn't actually work, since that'd force me to have custom CSS for Wikipedia. {ah, I see now it's because I'm not logged in. Great, easy to avoid then, no problem} Also: I'd love a before-after on page weight. Everyone always seems to add like a full MB of junk to the damn page when they add smart search like that, for some reason, even though it shouldn't require anywhere near that much (see: Github, whose pages bloated a ton when they made their search field "smarter"). One of the nicest things about WP is that it's semi-usable on a potato connection and I wouldn't want to see them sacrifice that in the name of almost any other improvement.
[EDIT 3] Being the change I want to see in the world: I checked with caches disabled and it looks like transfer and weight are damn near identical compared with the "wikiless" site that someone else linked, for the same article. Very nice, happy to see that. However, it appears to use double the memory of the Wikiless version (which I suppose represents something closer to the old design?) which seems pretty bad to me.
> When you are logged in to Wikipedia, the updated header will move with you as you scroll
We need to stage some kind of intervention with web designers. There can't be a single person on the planet who actually likes this anti-feature. Why on Earth do they keep doing it?
Because most people like it and it improves metrics.
From the discussion on sticky header [0],
> Our preliminary results show that an overwhelming majority of test participants reported positive experience with a sticky header. Participants mentioned they enjoyed the ability to access important functionality from any part of the page.
> Overall, there was an average 15% decrease in scrolls per session by logged-in users on the 15 pilot wikis in the treatment group (with the new sticky header), compared to the control group (without the sticky header). This indicates that our hypothesis was correct - adding the sticky header to the page reduced the need to scroll to the top of the page significantly.
> there was a 2.8% and a 6.8% increase in the percent of people who were able to successfully complete at least one edit using the edit button within the sticky header,
It might improve stats for people who use the header, but I'm pretty sure that's a tiny fraction of users. I just want the screen space and consistent scrolling behavior, not a header popping in and out as you scroll around or reach the top of the page.
If it's static, at least it's not the worst kind (though I still "select element -> remove" when I see those): the ones that bounce down when you scroll up even one notch, covering the very thing you were scrolling up to see, are the web design equivalent of someone slapping you in the face.
Could you explain to me why this is an anti feature? It seems harmless at worst and useful at best to me, e.g., having access to the search feature and lagnuage select during scroll here. (Serious question, I feel like I am missing something after reading this thread.)
I guess I dislike it on mobile when it takes up too much space.
Mostly this. I visit a website to view its content, not its header. I don't need to waste 10% of the screen on something I will almost never use. On Desktop, I can press "Home" to get to the header in the rare instances I want to. On Mobile, screen space is even more valuable, so it's even more annoying to have to waste screen space on the stupid header (and no, web designers, the style that pops up and covers up the content you are trying to read when you scroll up one pixel is not a solution).
I just gave some thought to why it bothers me and I actually think some of it might be because they trigger a kind of "oh shit a 'search bar' add-on, kill it with fire!" reflex from the bad ol' days of most computers being full of malware and spyware (now the OS and most programs are spyware, so... progress?).
Of course the big ones are simply obnoxious wastes of space, and any that have a drop shadow on the content bother me for what seem like obvious reasons, but even the small ones bug me and I think that might be why.
[EDIT] That's just for the static ones—the ones that pop in and out based on scroll behavior are one of the worst design trends in the entire history of the Web, which is saying something, and are in an angry-making category all their own.
If you hate it, it's probably because it's different. You'll get used to it. It's similar to how every time a company re-designs their logo, there's always a huge backlash solely because it's change, and people do not like change.
It's a really nice improvement from the previous design.
> If you hate it, it's probably because it's different.
No, the only thing I actually hate is that the main page has plenty of space on the side to show the sidebar, yet I still have to click it in order to get it to open up and see "Current Events".
I don't dislike it because it's different, I dislike it because it is measurably slower to do something I used to do in one click. THERE IS NOTHING THERE WHEN THE SIDEBAR IS COLLAPSED.
-
On Wikipedia, and any MediaWiki installation, you can add the useskin query parameter to the URL to change skins on a page, even when not logged in.
Current (vector-2022): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ve...
Previous (vector): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ve...
Older (monobook): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mo...
Older alternative (modern): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mo...
Older alternative (cologneblue): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=co...
Mobile (minerva): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mi...
Responsive alternative (timeless): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ti...
Installed skin list: https://en.wikipedia.org/wiki/Special:Version