Explore Wikipedia's New Look
wikimediafoundation.orgDetails on the design process: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
-
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
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.
> mostly because scrolling is fundamentally incompatible with columns
How so? You just scroll horizontally rather than vertically. Even actual scrolls come in both vertical and horizontal (column-based) formats.
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.
Mouse wheels. That‘s the issue. They mostly scroll only vertically. Horizontal scrolling frequently is a massive pain for everyone involved.
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].
> , I have to move my head.
I don't.
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.
This really should be the top comment on this post. Incredibly useful, and the last link shows that most of these skins are being actively maintained.
All of those skins are open source and their repos are browsable on Wikimedia's Gerrit. Here's good old MonoBook: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/ski...
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.
For example, MediaWiki 1.35 added Mustache templating: https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWik...
So here's the commit to MonoBook converting it to use Mustache: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/ski...
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.
You might be interested in the sections "WE MADE IMPROVEMENTS TO BACKWARD COMPATIBILITY" and "WE IMPROVED THIRD-PARTY SUPPORT" on https://jdlrobson.com/posts/2023-01-17_the-new-wikipedia-app... which have a few more links that might be of interest.
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).
I think you are specifically referring to https://phabricator.wikimedia.org/T325009 (still awaiting discussion) and https://phabricator.wikimedia.org/T318013 (resolved next week) ?
Thanks, used this in conjunction with a url editing add-on [0]
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.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/*?*[0] https://addons.mozilla.org/en-US/firefox/addon/redirector/
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.
I find so much whitespace to the left tries to grab my attention and makes it harder to focus on the content.
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 have been using a user script to do just the opposite, because the interface is so much poorly delineated and the content much harder to read.
I guess I'll be modifying it to plaster ?useskin=vector at the end of every link as well...
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
https://en.wikipedia.org/wiki/GeForce_30_series?useskin=vect...
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 find the old width fine. The font size was too small, I adjust that locally, but the length was ok.
Why not just have multiple columns of text instead of half a screen of emptyness and stuff users rarely interact with?
You could arrange the different wiki sections to be side by side.. in a dynamic responsive way depending on device/screen size
I find multicolumn on digital screens especially in the browser to seem very clunky.
And with an arbitrary article length, multicol would require pagination, right?
Do you have any examples?
I see some examples on MDN:
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
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
Text width is important, but this is not a solution, zooming and changing browser window geometry is.
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.
You could also just log in to an account and set your own theme. My account is still one the 2005 theme as it works best for me.
Plus if I change the browser geometry, that messes up the other pages I have open in other tabs. Not to mention the other apps my TWM manages.
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.
But zoom is only for the current tab, so no need to keep resizing
Increasing zoom to reduce words per line is a hack though. Why would I want to read Wikipedia in a larger font than I read other websites?
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.)
[1]: https://practicaltypography.com/page-margins.html#on-the-web
> 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.
https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...
> 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.div.article-text { max-width: unset !important; width: 100% !important; }
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.
If you create an account on Wikipedia then you can go into preferences and define custom CSS styles.
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.)
Interesting.
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.
Desktops and laptops. I do see more Mac users with maximized and/or full screen windows on particularly small laptops.
(And I'll note that in my own usage, when I'm on my 11" Macbook Air I full screen most apps. But that's a weird edge case due to the screen size.)
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”.
Agree, and this is one of the things that infuriates me with macOS. The new "Settings" app can't even be maximized horizontally anymore.
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.
I have a 4K monitor and I have Wikipedia at 200% zoom at all times. It works fine and I prefer it to the alternative.
What an absolutely absurd thing to say.
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;
}
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.
Simple userscript to add the tags from https://news.ycombinator.com/item?id=34431533 to the end of wikipedia URLs.
https://greasyfork.org/en/scripts/458494-old-wikipedia-layou...
This assumes you control your browser, which may not be the case in a corp setting.
I'm upvoting this to counteract the downvotes.
Basic customizations should never be blocked behind an accountgate.
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.
1: https://en.wikipedia.org/wiki/Wikipedia:IP_edits_are_not_ano...
2: https://en.wikipedia.org/wiki/Help:I_have_been_blocked
3: https://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption
>I really hope any website could be as flexible as Wikipedia to allow users to write their own CSS.
Once upon a time, there was an initiative for websites to add a unique CSS ID to the <body> tag so users could customize them with user stylesheets.
For example: <body id="news-ycombinator-com"> for this website, and then users can apply CSS rules as they see fit via the user stylesheet.
Sadly, the initiative never took off and most browsers nowadays don't even know what a user stylesheet is.
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
Boy do I have good news [1] for you.
How do you make the max-width apply permanently to a website on chrome?
If you're logged in to wikipedia you can add custom css (and js) in 'Preferences > Appearance'
You can use an extension such as Stylebot: https://chrome.google.com/webstore/detail/stylebot/oiaejidbm...
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..mw-page-container { max-width: none !important; } .mw-content-container { max-width: none !important; }> This seems like an excuse to force JS to enable ads
No, it's an accurate description of most users' reading preferences, myself included.
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 can zoom in on current wikipedia just fine using browser "zoom in", and the size of the column of text increases accordingly.
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:
.mw-page-container,.mw-content-container{max-width:none!important;}
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.
So you have trouble reading books?
I used to have trouble with some books. Now I read them on a screen with longer lines.
Office documents seem to default to somewhere in the region of 90 – 100 characters, interestingly.
Isn't it because people are used to read pocket books?
Anecdotally, I'd say it has no relevance.
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.
I don't think "every" designer does that.
And not everyone wants all content crammed into a little area.
All in all, it should be up to the user decide how much content density they want on websites.
I really like it.
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.
https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWik...
Good:
- Sidebar for navigation
Bad:
- Wasted screen space
- 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')`
> Wasted screen space
Don't fall for that mental trap. White space is not wasted space.
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.
The text is huge, but it at least fits with screen. I do have the monitor set back, but not so far that text at 100% is unreadable.
That suggests to me that you're either not sitting the correct distance away from your display, and/or your display's DPI settings are wrong.
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.
> - Wasted screen space
Don't worry, it will soon be filled with solicitations for donations.
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.
Also for some reason they made links even brighter blue
it does not only break your bookmarklet, but even vimium [1] is unable to focus the language selection. this is awful.
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.
Thank you! I first went back to vector legacy, but then I saw monobook which is the wikipedia of my memories and have swapped there, so now I'm happy.
Kudos to WM for keeping the option for that theme in MediaWiki. Now I have a reason to browse logged in all the time.
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.
Or you can just use custom CSS, which works not only here but on every site, and has been my preferred way of fixing/reverting horrible decisions.
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.
Unfortunately this only works if you have javascript enabled on the site, too, and the awful popups they added made me disable it.
Why is everyone moving to so much white space? I wish there was more of an emphasis on information density on the modern web.
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.
A border line emphasizes distinctions quite intuitively without wasting space.
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.
Because human eyes and brains aren't computers, and it's actually hard to read small text on long lines and low vertical spacing.
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.
[1] https://twitter.com/tuomassalo/status/978717292023500805
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?
Screenshot: https://cloudflare-ipfs.com/ipfs/QmaovnEHiCo6knhTPpp4XJyr5x9...
This actually increased the line length.
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.)
It’s just a silly font, still a work in progress. Inspired by https://mastodon.gamedev.place/@Nifflas/109330930338202763
Could you share what font editor you used, and whether you're using ligatures?
FontForge, despite its antiquated interface, and liberal use of ligatures:
https://cloudflare-ipfs.com/ipfs/QmVMS6LFUEqJJdnXDVuVZWRDSHT...
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.
I just noticed that "L" and "R" are left and right arrows respectively. That's delightful.
Lovely, thank you! Thinking of giving this a shot. Let me know if you post about the font anywhere.
Apparently I only gave it a quick glance because I thought it was Arabic
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.
You can even turn off responsive design in the settings. I should have checked earlier.
Do you have to log in?
It seems you do need to log in, but just unchecking 'responsive' makes everything load a lot faster and become a lot more usable.
yay, I need to get an account so I can browse it normaly. great...
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?
Closed subsections break page search (at least on iOS Safari), which I find very frustrating.
I always prefer the full article, but this is a matter of opinion. The issue is that the behavior is not consistent.
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.
So Much White Space
Its also off-center which
is annoying on an 15"laptopBut they added the donate button in a prominent position top right. At least no one will miss that when they're looking for a context menu ;)
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.
Everything decays, especially software.
> 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 don't normally read books that are anywhere near as large as a 27" monitor, and when I do they often have pretty massive margins (or "whitespace").
I mean seriously, a 27" diagonal monitor is 24"x17". Do you routinely read on 12"x17" paper with near zero margin?
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.
Books aren’t as big as monitors.
Long lines of text force you to move your eyes and/or head side to side every time you go from one line to the next.
To be fair, the book example isn't really a 1:1 comparison because white space on a page translates to wasted $$.
It's a common accessibility requirement. For example, WCAG suggests limiting the max width of blocks of text to ~80 characters (40 for CJK).
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?
This is why newspapers and magazines (if you remember those) have a columnar layout instead of just filling the whole page side to side.
Yes, it's extremely common UX practice. Lines really should be no longer than 80 characters at an absolute maximum. 50-60 is ideal.
> 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):
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.Computer text line lengths affect reading and learning Peter Orton https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf[1] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
[2] https://www.scienceopen.com/document_file/671b2d53-73ce-4a91...
[3] https://sci-hub.se/https://link.springer.com/chapter/10.1007...
Appreciated, thanks. Just expected footnote marks in the article similar to Wikipedia or hyperlinks
Gut reaction: I hate it. But I'll probably get used to it...
Same! I absolutely hate the amount of empty space everywhere on my 1080p screen.
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.
> probably get used to it...
Since it is on some language version for some time I already did. But it took some time.
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.
Thanks I hate it.
I hate that sides want to control how "wide", I mean narrow the text can be. Sorry, I prefer longer lines and not a bunch of empty space on the sides.
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.
Great, now it takes two clicks to switch languages
old.wikipedia.org when?
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.
Looks nice on desktop, have yet to see how mobile has changed. Oddly, I find that it still shows the old UI on certain pages? Eg:
https://en.wikipedia.org/wiki/Does_not_compute https://en.wikipedia.org/wiki/Combinatorics https://en.wikipedia.org/wiki/Stable_Diffusion
And I guess my one complaint is, it now takes 2 clicks to iterate through random articles.
Now I have to log into Wikipedia just like reddit in order to get the non-atrocity user interface experience. How nice.
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.
I don't like it. It was fine the way it was. I like the new table of contents though. Thats kind of useful
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.
Oops, I'm an idiot, the new theme isn't the default yet!
just tested this, and it seems to be the default (at least when i navigate to the english-language wikipedia in a new incognito browser tab).
Dictionary app still seems to be working fine, though.
my guess here would be that they probably don't access the HTML at all, but instead go through MediaWiki's API.
Wow, an improvement to a website that is actually an improvement. Reads way easier. Can I get Confluence to look like this?
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 :(
You can set a fixed width view in the preferences which might help a lot.
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
I was really hoping for a built in dark mode with the update. The mobile app is fantastic about this.
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.
Unfortunately the new design seems to break the extension's ToC sidebar
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.
Love the new ToC links on the left.
The new look seems to mess up some inline images.
In the following links, the histogram chart under section Historic Population has an unnecessary horizontal scrollbar for the chart image.
https://en.wikipedia.org/wiki/Bern (New vector-2022 look)
https://en.wikipedia.org/wiki/Bern?useskin=vector (Previous vector look)
Note: I am viewing this on my surface tablet in landscape mode.
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.
I really like it
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.
Why can't you just resize the window to a width that is comfortable for you?
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.
They could have made a responsive multi-column layout to keep the readability of reasonable line lengths while keeping information density high.
Now, is there a dark mode like on the app?
A max line width is welcome from me, I'll be able to remove my tampermonkey script for wikipedia.
I'll still need to keep the generic one around that I use on demand to fix other unreadable pages though.
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.
(1) https://addons.mozilla.org/en-US/firefox/addon/mobile-wikipe...
I guess they have to justify their e-begging banner somehow even though a tiny proportion of the donations actually get spent on Wikipedia.
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.
You can fix these errors if you want to. Anyone can edit Wikipedia.
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.
I added {{failed verification}} to the French toast article. That was immediately reverted. What's the process for correcting Wikipedia again?
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.
Just let me link to a content section (named anchor) on mobile. It makes sharing specific parts kinda difficult.
Another irritatingly unnecessary change.
For those who don't like the new skin. I have created a user CSS to make it more compact:
https://gist.github.com/kool-user/457cbf0100e075cc83977c1fe8...
I didn't like the look of it from that GIF but after visiting it I don't mind it at all
I think it's nice actually. It also works great with JavaScript disabled! Thanks Wikipedia.
> also works great with JavaScript disabled
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.
Should use white for the text colour to give the design a consistent theme.
Does anyone have any CSS/JS code to always expand the ToC sections?
I prefer Wikiwand over the redesign, but this is still a massive step in the right direction.
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.
But how does it look with a massive charity drive ad banner?
Thank god for wikiless.
1) Awesome, didn't know about this, but
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.
My first instinct was: how to get rid of the left menu and get the text wider again.
Magnify to 150% and it's readable again.
I don't know if they're rolling it out in phases or what, but the new design seems to work only on some articles.
As of right now (UTC 4:50 am):
- Hanlon's Razor (new design) https://en.wikipedia.org/wiki/Hanlon%27s_razor
- Dunning-Kruger effect (old design) https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
both show the old design to me so seems more like some servers in a group have the new design elements and some have the old?
... Got to admit, seeing the headline, I was assuming I would hate it, but... it looks pretty good.
oh goddammit
(sorry)
Is there a way to change it back?
If you are signed in you can change to any of the historical themes and a few others. That is the easy option for switching.
Bless you noble stranger!
~2005 was peak Wikipedia aesthetic. All these flat, border less design decisions take away from intuitive UX and make things more... globally homogenous.
It's not like old UX wasn't "globaly homogenous" either
something is definitely wrong with firefox on linux. There is no margin on the left side.
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.
You suppose wrong.
Yeah, I don't like it either, and I don't see a way to disable this apart from user's defined bookmark script, like kill sticky[0]:
But unfortunately, it renders the header useless in this case.javascript:(function()%7Bdocument.querySelectorAll(%22body%20*%22).forEach(function(node)%7Bif(%5B%22fixed%22%2C%22sticky%22%5D.includes(getComputedStyle(node).position))%7Bnode.parentNode.removeChild(node)%7D%7D)%3Bdocument.querySelectorAll(%22html%20*%22).forEach(function(node)%7Bvar%20s%3DgetComputedStyle(node)%3Bif(%22hidden%22%3D%3D%3Ds%5B%22overflow%22%5D)%7Bnode.style%5B%22overflow%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-x%22%5D)%7Bnode.style%5B%22overflow-x%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-y%22%5D)%7Bnode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D%7D)%3Bvar%20htmlNode%3Ddocument.querySelector(%22html%22)%3BhtmlNode.style%5B%22overflow%22%5D%3D%22visible%22%3BhtmlNode.style%5B%22overflow-x%22%5D%3D%22visible%22%3BhtmlNode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D)()%3B%0AI 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.
This sounds like the perfect application of customization. Why chose one, when you could have both at nearly no cost. :)>> I don't need a header to follow me down the page, in fact I'd prefer it not to. > I find the persistent ToC to be very helpfulIt 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.)
all these changes are geared at mobile. I imagine thats the majority of their traffic now
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)
It is described specifically as "desktop improvements".
The maximum line width is specifically applicable to Very Large Desktop Displays, not mobile.
Several other changes ... seem fairly agnostic.
> Feels like they're introducing a persistent UI element without a benefit.
guess what else will be persistent when donation drive banner gets turned on
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,
[0] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
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.
> 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'm here to read. Stop interfering with that.
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.
It's been in use for ages in other languages which I read a lot. It isn't "different". It is concretely worse to me and many others here.