It sucks, I really dislike how that sidebar works, the old inline one at the top of the article was so much nicer to use. (It's pretty clear this was a "make it pretty update" without much care for how it works)
I think a big assumption of the new design is that you use it to use wikipedia itself, generally most of my wikipedia usage is as a reference for the main thing that I'm actually doing, where by having a wide modern monitor, I can put wikipedia on half (or less!) of the screen and have it be useful. Now with this sidebar thing it's much more annoying to do.
Glad to hear I'm not the only one who can't stand the new design.
Fortunately, I found that Wikipedia allows to select the old design in the account preferences when you're logged in. You can even switch back to the very old pre-2010 theme.
And I like the floaty bar - makes it easier to skip sections, needs less scrolling :shrugging_emoji: I will stay with the new version because of it (and shorter line width too).
The previous Wikipedia design was so good that I never ever noticed it until they changed it. I personally dislike the new one.
The pinnacle experience for me is the “printable version” of the old layout. It was beautiful and simple.
I actually don't mind the mobile version today. I can't tell what changed, which is probably a good sign. It feels fine to me.
I think the prominence of the "Edit" button is interesting. It's a noble pursuit to democratize ownership of these documents. To empower anyone to be able to edit them. In that way, making Edit a first-class element when designing the layout is great. But in practice, I've experienced it to be daunting to edit anything. It often feels like I'm impinging upon the territory of some Wikipedia clique. Perhaps just a bad few experiences. I should try again.
"In other words, Wikipedia — a major, legacy website (top 10 ranked, for 10+ years) — had an interface that hadn’t been changed for 15 years." It shocked me that what came next was effectively: "so let's change it!" You'd think the very facts in that sentence scream not to: it's been a top 10 website for 10+ years and hasn't been changed. I forget the exact quote, but something Bob Ross once said in an episode stuck with me: that it's very difficult to know when to stop; to know when your painting is done; to put the brush down.
I have an (oftentimes undeserved) bias against designers where I feel like they can be stuck between a rock and a hard place: it's difficult to say to your employer, "yeah you don't really need me to do any major work here. Studies conclude that it's still a good design. Don't change it." It's so much easier to return with a list of recommendations. Even better if that means more work for you.
Trivially: I thought it was amusing that the 2.1MB image of the two monitors from 19 years ago took many seconds to progressively load. I had to check if that was intentionally coded (it was not). Tangent (sorry I'm wandering): I miss the non-scanline progressive loading, where an image would slowly get sharper as it loaded. Is that still a viable option?
> It might honestly be a once-in-the-history-of-the-internet kind of situation. Exciting, but rather difficult.
Difficult to do a good job on it. Which I really don't think this was.
> the line length had no limit
The limit was based on the viewport. So a user-defined limit. It would be nice if people could easily keep this behavior.
> the many versions of Wikipedia are not centralized. The Wikipedia you read (whether it’s English, Bangla, Telugu, Kyrgyz, Korean, Persian, or any of the 300 others), is actually a separate website from all of the other Wikipedias that exist. Sure they share a lot of code, use the same servers
Using the same servers is one meaning of centralized. What type of decentralization do you mean? Perhaps define it beforehand.
Tolerable line lengths are largely determined by human biology:
* Short lines are exhausting to read because you have to move your eyes more
* Long lines are exhausting to read because you lose track of where the line is
There's no reason for this to be user defined. Just pick a reasonable line width for your given viewport and fill the remaining whitespace with useful information. Wikipedia did this very well and I genuinely do not understand why every top-level comment on HN is bashing the redesign.
Ser I'm not always reading on Wikipedia, I am often skimming. Also I'm in my 40s now and I can still read long lines pretty well. Or perhaps I can still read short lines pretty poorly and I'd rather have the tradeoff of having to shift my view less often but at a longer distance.
Of course, the studies that you're (not) citing to back up your opinions were conducted decades ago on printed media, but never mind that. We Know Best (tm).
I disagree because reading is just one use case. Sometimes longer lines make it easier to skim because you aren't needing to read everything, just letting your brain pattern match as you move along. In that case it can be better to fit more blocks of text in the viewport.
This mentality is exactly why UX designers suck. It's all about some developers forcing their weird vision on everyone with no regard for user choice even when it wouldn't cost much to include because X study claimed something.
Studies on line length are all over the place, I think the only consistent conclusions are that shorter lines (between 30-60cpl) are beneficial for readers with poor literacy skills (including non-native speakers) or for people with dyslexia or some visual disorders.
I bring this up because recent studies have managed to account for the saccade error associated with return sweeps and have found that reducing said error does not increase reading speed or comprehension.
It's also worth noting that studies done on print line length aren't applicable to screen line length, and that most studies deal with lines of 30-100cpl, sometimes up to 130cpl, which isn't enough most websites rendered on a 16:9 screen or even the current Wikipedia design (on my 1080p monitor at least).
I just wish they’d tested it at my viewport width. The new design gives me clumsy, obfuscating UI elements that would be appropriate for a phone, but stretched comically large across half my laptop screen. In a side-by-side comparison with the previous design it looks like they needlessly made the website less usable.
- The search box and main menu are now hidden, and on every page load the menu briefly fills half the screen in a FOUC.
- The table of contents is now hidden, taking away one of the critical first pieces of content I read.
- The sticky hamburger menu covers up the article text.
- Text lines are even wider than before, a particular irony given how celebrated the reduction at other viewport widths is.
I like it. It isn't the most aesthetically pleasing site on a wide monitor but narrow column widths are optimal for reading. Plenty of studies have shown that people have difficulty reading beyond 50-60 characters and 9-12 words per line, so I'm happy they put content over design in this case. There's nothing wrong with blank space and wide margins. People will just get used to it. Old wikipedia was impossible to use at a 4K resolution.
One problem is if if you use a narrower browser window in the first place, for exactly the reasons you are citing, then now the TOC is hidden by default, whereas previously you could simply hit the Home key and/or use other normal in-page navigation to get to it.
Also if you really hate the "wasted space" on the sides and you're on a giant resolution, find the expand button and the content stretches out. It's a horrible reading experience, but nobody can argue about wasted space when it's in expanded mode!
I don’t know how you’re so sure. That whole page is describing an experience I don’t have.
> the table of contents is located next to the article so that you can see it immediately when you land on the page
No, it’s hidden behind a hamburger menu, no longer immediately visible.
> Why is the table of contents hidden sometimes? this should no longer be the case.
No, now it’s hidden for all articles.
> Why is the article width limited to 960px?
Not applicable; 960px is already the width of my viewport.
> Why is there so much empty space?
This is the reverse of my experience; due to the widening of the main column and removal of the inline table of contents, there is now less empty space.
> Case 7 (default for all below 1000px)
Sounds to me like I got lumped in with the phones.
Increasingly many websites exhibit this mode of failure so it’s not implausible for it to be a common blind spot.
When I first saw the new design, I thought something in the lines of "oh, again, changing what wasn't broken for no good reason". Then I started to get used to it... and realized it _is_ better than the old one.
First of all, English is not my native language. Common pattern when reading Wikipedia for me is to check native version, then switch to English if there was not enough info. In the previous design I had to re-Google English version of the page. Now it's one click in the toolbar.
Then, the content narrowing. It wasn't until I got some pages in the old design that I felt reading full-width text (on a 16:9 display) uncomfortable.
Table of contents on the left also helps and makes experience more uniform across different sites and software (Google Docs, PDF viewers, and so on).
Overall, the changes just "clicked" right. Don't even have anything to rant about, the design gets out of the way after the first five minutes of reading.
> In the previous design I had to re-Google English version of the page. Now it's one click in the toolbar.
That's because it was a different page about the same thing.
Pages in other languages aren't and shouldn't be translations.
Now the Spanish page for Cheems is probably at risk of being merged into the Doge page because that's what happened on the English Wikipedia because Cheems isn't as popular with English speakers.
there's no language switch, they're different pages unless they're determined to be about the same thing. shoehorning them into a 1:1 mapping is toxic.
> That's a straw man. I didn't say they are or they should be.
I didn't say or imply you said that, just that it could be a result of the new policy.
> This has always been the case, and the rollout of a new skin certainly hasn't changed that.
Often concerns are about things that haven't happened before, and yet they still come true. For instance the pandemic was full of firsts.
> Now the Spanish page for Cheems is probably at risk of being merged into the Doge page because that's what happened on the English Wikipedia because Cheems isn't as popular with English speakers.
Why would you think that?
Each language's Wikipedia is a separate project with its own administration and its own criteria for notability. This has always been the case, and the rollout of a new skin certainly hasn't changed that.
...because a contingent of people think there should be an easier way than a search engine to switch which language you're viewing a page in, even when it hasn't been marked as being the same. This prefers (but doesn't necessarily mandate) a 1:1 mapping.
Interlanguage links on Wikipedia have existed since 2002. They are not a new feature.
Literally the only thing which has changed about them with this skin rollout is that they are now shown in a dropdown at the top of the page, rather than on the sidebar or at the bottom of the page.
Your reaction here is a bit overblown. Do you often have concerns about imagined futures? If so, you might want to look into a condition called "anticipatory anxiety."
> In the previous design I had to re-Google English version of the page. Now it's one click in the toolbar.
No, this feature had always been one click in the toolbar. Now it needs at least two clicks, and usually also a bunch of scrolling. Definitely a regression in my eyes.
I have exactly the opposite experience with the new language button. In the old design, all of the main languages for the page were easily available in a list on the left, so there was much less clicking and scrolling required. You could also see at a glance which topics were most well-documented in which language. Now you have to scroll all the way back to the top of the page to change it, and you have to waste a click just to see which languages are available in the first place.
Putting the table of contents shortcuts on the left instead of the top, on the other hand, seems pointless to me, since if I wanted to jump to a particular section, I would already know that at the top of the page, and I wouldn't need to do it after I was already halfway down. Putting languages halfway down makes more sense to me, since it's exactly halfway down where if I find some controversial text or a disappointingly slim section, that's exactly when I want to see which other languages are available and if those versions contained more details or a different point of view.
I read a lot of Wikipedia, so literally every day since the redesign I've found myself annoyed at all the extra scrolling and clicking I have been required to do while this new floating sidebar sits there providing negative value. Negative because it's both wider than the old one, and because it constantly distracts my reading as I scroll by changing the color. I do like the idea of providing a floating sidebar, and I am not opposed to putting the table of contents in there for people who want it, but removing the language navigation functionality was really a big miss for me.
"As the comments/votes started coming in, I became frustrated at how unrepresentative of the general public the people voting were. It was a very small group of editors, potentially making a decision for billions of readers. It was also unclear if the people who were voting had participated in past discussions, and/or had taken the time to read through the project documentation, research results, data, etc. It seemed like we were getting a lot of first reactions (as it turned out, only ~28 of the 159 people opposing the new interface had previously engaged in discussions, feedback, etc.). There was a lot of arguing about white space and icons, and people saying they simply didn't like it, rather than discussions of user needs and/or key metrics.
The volunteer communities are generally very change-averse (in some ways for good reason), and changes developed by the Wikimedia Foundation can be particularly challenging to get acceptance for. However I was still left feeling a bit weirdly about the vote. Did we just get lucky? Did all of the previous interactions we had with volunteers actually build support? Did all of the feedback we incorporated lead to a better design? And why do people think whitespace is an indication of a failed design (like holy shit, some people hate it so much)?"
I'm confident this comment section will be the same as it has always been. The 0.01% complaining that they liked it better before.
Actually, plenty of users here seem to like the new Wiki design. The volunteer community did a great job of keeping the changes focused wrt. actual usability improvements and avoiding pointless churn. Most remaining complaints were about "too much white space looks bad", which is hard to avoid in this case since the main point of the redesign was to have a shorter line length on wide screens.
What if it's a majority of users and you're simply trying to minimize their point of view by implying it's just a vocal minority? That's what I think you're doing.
One of the reasons I stopped doing UI work was the aggrevation of dealing with crap like this. I can fake being patient until I can't. Then I'm just done.
People like Hollender who can humor all POVs -- because stakeholders, experts, trolls, eeyores, and hairballs must all treated equally by the process -- are nothing short of saints.
What I don’t like that how they put the languages of the article behind a drop down menu button.
Personally I find the available languages are a good indicator about the “reach” of the article.
In the previous design it was just a glance on the sidebar to see if translations are available or not. Now I have to click and sometimes even scroll too if I want to see all languages.
I frequently switch between different language versions, and it’s annoying that (a) you can’t see at a glance anymore which other language versions are available, and (b) it now takes two clicks to switch language, plus usually some scrolling in the language dropdown. Furthermore, there’s no reason for the dropdown to have a limited fixed height, instead of being able to extend to the height of the browser viewport.
It would be nice if one could at least configure a set of “favorite” languages that would be displayed directly when they exist for the page.
The click-through flow for switching language versions is great for most readers. The previous sidebar listing was obscure, now the number of translated versions available is front and center, right next to the title.
What annoys me the most about the new design is the highlighting of the “current” section in the now fixed-positioned TOC. It always distracts me when scrolling through an article, like some blinking element.
Executing a major redesign or feature launch in an open source, consensus-driven project like Wikipedia is an exceptionally difficult and often frustrating experience for any design/engineering/product person.
The team that worked on this did an outstanding job of being patient, empathetic with users, and methodical (over years!) to make this happen. Every RFC and discussion they showed up to listen and act on feedback, incrementally improving it bit by bit. Even as a regular editor, I find it much faster to navigate Wikipedia thanks to the redesign.
Very little of this sounds definitively positive. Are more clicks better? Why? Are more searches better? Why? Is not opting out evidence people prefer it? Maybe they didn't know how to opt out or 'wanted to give it a chance'. Who's to say pageviews, edits, or account creation is good or bad?
The new theme could be better in every measurable way but still not be worth moving to because billions of users are already brain-trained on the old theme.
In fact, the new theme caused me to log in with an old account just so I can change the theme back to the old one.
59 comments
[ 2.6 ms ] story [ 115 ms ] threadI think a big assumption of the new design is that you use it to use wikipedia itself, generally most of my wikipedia usage is as a reference for the main thing that I'm actually doing, where by having a wide modern monitor, I can put wikipedia on half (or less!) of the screen and have it be useful. Now with this sidebar thing it's much more annoying to do.
Fortunately, I found that Wikipedia allows to select the old design in the account preferences when you're logged in. You can even switch back to the very old pre-2010 theme.
Very highly recommended. I agree that the new design is really frustrating to use.
The pinnacle experience for me is the “printable version” of the old layout. It was beautiful and simple.
I actually don't mind the mobile version today. I can't tell what changed, which is probably a good sign. It feels fine to me.
I think the prominence of the "Edit" button is interesting. It's a noble pursuit to democratize ownership of these documents. To empower anyone to be able to edit them. In that way, making Edit a first-class element when designing the layout is great. But in practice, I've experienced it to be daunting to edit anything. It often feels like I'm impinging upon the territory of some Wikipedia clique. Perhaps just a bad few experiences. I should try again.
"In other words, Wikipedia — a major, legacy website (top 10 ranked, for 10+ years) — had an interface that hadn’t been changed for 15 years." It shocked me that what came next was effectively: "so let's change it!" You'd think the very facts in that sentence scream not to: it's been a top 10 website for 10+ years and hasn't been changed. I forget the exact quote, but something Bob Ross once said in an episode stuck with me: that it's very difficult to know when to stop; to know when your painting is done; to put the brush down.
I have an (oftentimes undeserved) bias against designers where I feel like they can be stuck between a rock and a hard place: it's difficult to say to your employer, "yeah you don't really need me to do any major work here. Studies conclude that it's still a good design. Don't change it." It's so much easier to return with a list of recommendations. Even better if that means more work for you.
Trivially: I thought it was amusing that the 2.1MB image of the two monitors from 19 years ago took many seconds to progressively load. I had to check if that was intentionally coded (it was not). Tangent (sorry I'm wandering): I miss the non-scanline progressive loading, where an image would slowly get sharper as it loaded. Is that still a viable option?
I like it overall, slightly, because I often read wikipedia on mobile.
Difficult to do a good job on it. Which I really don't think this was.
> the line length had no limit
The limit was based on the viewport. So a user-defined limit. It would be nice if people could easily keep this behavior.
> the many versions of Wikipedia are not centralized. The Wikipedia you read (whether it’s English, Bangla, Telugu, Kyrgyz, Korean, Persian, or any of the 300 others), is actually a separate website from all of the other Wikipedias that exist. Sure they share a lot of code, use the same servers
Using the same servers is one meaning of centralized. What type of decentralization do you mean? Perhaps define it beforehand.
* Short lines are exhausting to read because you have to move your eyes more
* Long lines are exhausting to read because you lose track of where the line is
There's no reason for this to be user defined. Just pick a reasonable line width for your given viewport and fill the remaining whitespace with useful information. Wikipedia did this very well and I genuinely do not understand why every top-level comment on HN is bashing the redesign.
I disagree because reading is just one use case. Sometimes longer lines make it easier to skim because you aren't needing to read everything, just letting your brain pattern match as you move along. In that case it can be better to fit more blocks of text in the viewport.
As Alistair Cockburn said in his excellent post-mortem for his cohort's CASE tool efforts (paraphrasing):
People hate change.
No, seriously, people really hate change.
This mentality is exactly why UX designers suck. It's all about some developers forcing their weird vision on everyone with no regard for user choice even when it wouldn't cost much to include because X study claimed something.
I bring this up because recent studies have managed to account for the saccade error associated with return sweeps and have found that reducing said error does not increase reading speed or comprehension.
https://link.springer.com/article/10.3758/s13414-019-01742-3
It's also worth noting that studies done on print line length aren't applicable to screen line length, and that most studies deal with lines of 30-100cpl, sometimes up to 130cpl, which isn't enough most websites rendered on a 16:9 screen or even the current Wikipedia design (on my 1080p monitor at least).
- The search box and main menu are now hidden, and on every page load the menu briefly fills half the screen in a FOUC.
- The table of contents is now hidden, taking away one of the critical first pieces of content I read.
- The sticky hamburger menu covers up the article text.
- Text lines are even wider than before, a particular irony given how celebrated the reduction at other viewport widths is.
https://www.mediawiki.org/wiki/Skin:Vector/2022/Design_docum...?
> the table of contents is located next to the article so that you can see it immediately when you land on the page
No, it’s hidden behind a hamburger menu, no longer immediately visible.
> Why is the table of contents hidden sometimes? this should no longer be the case.
No, now it’s hidden for all articles.
> Why is the article width limited to 960px?
Not applicable; 960px is already the width of my viewport.
> Why is there so much empty space?
This is the reverse of my experience; due to the widening of the main column and removal of the inline table of contents, there is now less empty space.
> Case 7 (default for all below 1000px)
Sounds to me like I got lumped in with the phones.
Increasingly many websites exhibit this mode of failure so it’s not implausible for it to be a common blind spot.
First of all, English is not my native language. Common pattern when reading Wikipedia for me is to check native version, then switch to English if there was not enough info. In the previous design I had to re-Google English version of the page. Now it's one click in the toolbar.
Then, the content narrowing. It wasn't until I got some pages in the old design that I felt reading full-width text (on a 16:9 display) uncomfortable.
Table of contents on the left also helps and makes experience more uniform across different sites and software (Google Docs, PDF viewers, and so on).
Overall, the changes just "clicked" right. Don't even have anything to rant about, the design gets out of the way after the first five minutes of reading.
Thanks to Alex and team!
That's because it was a different page about the same thing.
Pages in other languages aren't and shouldn't be translations.
Now the Spanish page for Cheems is probably at risk of being merged into the Doge page because that's what happened on the English Wikipedia because Cheems isn't as popular with English speakers.
I don't see how being "different page about the same thing" justifies lack of the language switch.
> Pages in other languages aren't and shouldn't be translations.
That's a straw man. I didn't say they are or they should be.
> That's a straw man. I didn't say they are or they should be.
I didn't say or imply you said that, just that it could be a result of the new policy.
> This has always been the case, and the rollout of a new skin certainly hasn't changed that.
Often concerns are about things that haven't happened before, and yet they still come true. For instance the pandemic was full of firsts.
Why would you think that?
Each language's Wikipedia is a separate project with its own administration and its own criteria for notability. This has always been the case, and the rollout of a new skin certainly hasn't changed that.
I think a search engine is appropriate.
Literally the only thing which has changed about them with this skin rollout is that they are now shown in a dropdown at the top of the page, rather than on the sidebar or at the bottom of the page.
No, this feature had always been one click in the toolbar. Now it needs at least two clicks, and usually also a bunch of scrolling. Definitely a regression in my eyes.
Putting the table of contents shortcuts on the left instead of the top, on the other hand, seems pointless to me, since if I wanted to jump to a particular section, I would already know that at the top of the page, and I wouldn't need to do it after I was already halfway down. Putting languages halfway down makes more sense to me, since it's exactly halfway down where if I find some controversial text or a disappointingly slim section, that's exactly when I want to see which other languages are available and if those versions contained more details or a different point of view.
I read a lot of Wikipedia, so literally every day since the redesign I've found myself annoyed at all the extra scrolling and clicking I have been required to do while this new floating sidebar sits there providing negative value. Negative because it's both wider than the old one, and because it constantly distracts my reading as I scroll by changing the color. I do like the idea of providing a floating sidebar, and I am not opposed to putting the table of contents in there for people who want it, but removing the language navigation functionality was really a big miss for me.
So it goes.
"As the comments/votes started coming in, I became frustrated at how unrepresentative of the general public the people voting were. It was a very small group of editors, potentially making a decision for billions of readers. It was also unclear if the people who were voting had participated in past discussions, and/or had taken the time to read through the project documentation, research results, data, etc. It seemed like we were getting a lot of first reactions (as it turned out, only ~28 of the 159 people opposing the new interface had previously engaged in discussions, feedback, etc.). There was a lot of arguing about white space and icons, and people saying they simply didn't like it, rather than discussions of user needs and/or key metrics.
The volunteer communities are generally very change-averse (in some ways for good reason), and changes developed by the Wikimedia Foundation can be particularly challenging to get acceptance for. However I was still left feeling a bit weirdly about the vote. Did we just get lucky? Did all of the previous interactions we had with volunteers actually build support? Did all of the feedback we incorporated lead to a better design? And why do people think whitespace is an indication of a failed design (like holy shit, some people hate it so much)?"
I'm confident this comment section will be the same as it has always been. The 0.01% complaining that they liked it better before.
> whitespace is an indication of a failed design
One of the reasons I stopped doing UI work was the aggrevation of dealing with crap like this. I can fake being patient until I can't. Then I'm just done.
People like Hollender who can humor all POVs -- because stakeholders, experts, trolls, eeyores, and hairballs must all treated equally by the process -- are nothing short of saints.
Neither urbandictionary, wikipedia, nor duckduckgo reveal whom I've unintentionally offended.
I mean more specifically than "everyone". While I consider myself a (part-time) misanthrope, I'd be mortified to be called a racist.
EDIT:
You wrote elsewhere:
> Whitespace is what happens when the ignorant play at design.
Hysterical.
I love the invective, even though I totally disagree.
Because it is. Having an unreadable column of micrographic text on a sea of white is useless.
Whitespace is what happens when the ignorant play at design.
Personally I find the available languages are a good indicator about the “reach” of the article.
In the previous design it was just a glance on the sidebar to see if translations are available or not. Now I have to click and sometimes even scroll too if I want to see all languages.
It would be nice if one could at least configure a set of “favorite” languages that would be displayed directly when they exist for the page.
Rather distressing from a person we're apparently supposed to be taking seriously on the subject of designing websites.
The team that worked on this did an outstanding job of being patient, empathetic with users, and methodical (over years!) to make this happen. Every RFC and discussion they showed up to listen and act on feedback, incrementally improving it bit by bit. Even as a regular editor, I find it much faster to navigate Wikipedia thanks to the redesign.
Very little of this sounds definitively positive. Are more clicks better? Why? Are more searches better? Why? Is not opting out evidence people prefer it? Maybe they didn't know how to opt out or 'wanted to give it a chance'. Who's to say pageviews, edits, or account creation is good or bad?
The new theme could be better in every measurable way but still not be worth moving to because billions of users are already brain-trained on the old theme.
In fact, the new theme caused me to log in with an old account just so I can change the theme back to the old one.