Wikipedia is getting a new look | Hacker News Reader

Wikipedia is getting a new look

diff.wikimedia.org

649 pointsAmorymeltzer512 comments

If someone asked me to critique the UX of Wikipedia, the first two things I’d point out would be that I almost never use the left hand side bar (and I have a feel almost no one does) and that when paragraphs are that wide they become harder to read (especially when they snake around floated images).

Not changing for 10 years, watching as some trends fade and others become law-of-the-land, and then making two changes that are backed by a fair amount of data strikes me as a great way for Wikipedia to operate.

I’ll also note that they definitely have changed some UX stuff over the past 10 years. The fullscreen expandable thing for images is pretty good, clean and JS-light (although this is HN so I have to note it would be better if it didn’t break the back button).

I use it very often, just because i check articles in multiple languages.

I use it for the same thing. This allows me to learn what specific word is used for [obscure thing] in a different language. Eg computer hardware related words for my native language.

Yes! I found Wikipedia article names are fairly reliable as a translation reference, especially for technical terminology. In my language, translations of technical terms in Wikipedia article names are often more accurate than the vast majority of random blog posts and articles on the web, and occasionally even better than some technical dictionaries, which may use old-fashioned or outdated terms.

Languages - yes, all the other links - almost never.

Given the image on the blog post, I thought it didn't include the languages, but looking into the wiki page about the change, it does include the language bar as well.

Damn. I use that all the time. Wikipedia is one of my favourite dictionaries.

This has also been my only use of the sidebar. It looks like the new design takes this into account and moves the language selection to a more prominent location at the top right next to the title.

I agree very much in principle. The wikipedia desktop site is beautiful, functional, fast, and doesn't change every 6 months to chase trends (unlike every god-damn website today it seems).

That being said I don't understand why the sidebar should be collapsible (and collapsed by default). It's just an extra click to access functionality with some people rely on (languages, for example, being probably one of the most used).

Design should not be trendy. It is not fashion.

I hope we don't bloat up wikipedia pages with too much whitespace. Getting of borders, "minimal" looks bother me so much because they're sacrificing layout for aesthetics. There is a reason why borders exist. It is a line segment that separates logically laid out content into groups.

I want Wikipedia to stay the same even if it is not ideal. There is a lot of legacy and "learned" behavior.

We need to add the familiarization factor to any UI changes. The amount of changes should at the minimum exceed the accrued familiarization of the UI...the longer the design remains the same, the higher this factor. It is crazy to think that we should not make a change if it is for the better, but there are a lot of people ... millions that use this less-than-ideal UI. There is something to be said about that.

Typographically, Wikipedia pages have too wide of a column width. This is a common problem not just with webpages, but with magazines and newspapers. There is a reason why the dimension of a book (such as a novel) is smaller than a magazine and that has to do with how wide of a column is comfortable for reading. We need to look at how magazines and newspapers solve this problem. They use columns. Larger fonts is not the answer nor is excessive whitespace because you're not solving the layout issue. It is just magnification.

If newspapers didn't exist and if web designers today were tasked to design a physical newspaper, it would be bloody 80 pages long and full of massive margins and fonts with no understanding about density of presentation. The web needs to be treated like physical media (yes, I said that, fight me). It is a rectangular 2D space that presents text - no difference to my retina whether it is a magazine, newspaper or LCD monitor in terms of spatial representation (not talking about contrast/backlit aspects). This was different a while ago, but today, the pixel density is great and we can almost treat monitors like paper (again, not talking about backlit issues).

Web designers today won't be able to design a physical telephone book. It would be called "Too overwhelming" for the user and it would be insanely big in 17 volumes.

With regards to line width, I don't understand 100% what you're saying. You agree that it is a problem, not because of aesthetics but because of readability. But then how do you propose to solve it? The only solutions are either increase font size (messing up things since now font size is tied to monitor width), or pad the sides with whitespace (what they're doing).

Or do columns like a newspaper, but it's unusual on the web.

Increasing font size is magnification of the entire column, so you sacrifice the vertical space along with it. Line height can't go lower after a specific point - Arial for example, with font size of 12 points needs to have enough line-height of 16 points.

Again, increasing the font size is not the solution.

The second point about padding the sides with whitespace causes waste of screen real-estate for no reason other than to give comfortable width to read. This is what NYtimes articles do: https://www.nytimes.com/2020/08/21/business/goldman-sachs-fo...

So left and right sides are unnecessarily wasted. The solution I am proposing is to use multiple columns. At desktop size, you get 3 columns. At tablet size, 2. On the phones, its single column. There might be better solutions to this but I can't think of any. Columns are how Magazines do their layout of text. It is also part of the international style in graphics design.

Counter point: Magazines had to use columns to conserve space and page count. Each page adds cost. In digital media, we don't have such limits. The only down side is the user has to scroll a lot. But we have devised a scroll wheel and most users have this tool.

> At desktop size, you get 3 columns. At tablet size, 2. On the phones, its single column. There might be better solutions to this but I can't think of any.

This is makes it hard to handle flowing content. Do you add artificial pages to break up the content or does scrolling cascade up each of the columns?

Then there's the issue of typesetting being an NP hard problem. Even Word needs a lot of hand-holding when using multi-column layouts because it often produces poor results.

I don't necessarily mind the excessive whitespace when I'm reading, because I prefer to not have to move my head and eyes too while reading. But having a lot of content on the page at once, like you're proposing, is really beneficial in technical situations, where I need to move between different pieces of information, like taking notes.

Print media also doesn't have to deal with: resizable windows, accessibility, user styles, navigation, mixed media, comment sections, SEO, browser compatibility, load times, or security.

I understand we are just talking about page layout, but web designers still have to simultaneously contend with everything I've listed.

You mention a solution for 3 different sizes (desktop, tablet, and phone), but a responsive site often has to subdivide further. Even so, "tablet" does not have a standard size. Rotating a tablet/phone also changes the view size.

Size is not the only usability difference between desktop and mobile devices.

Columns in such a way would likely be hell in terms of accessibility (remember, the user can change the font size).

Of course, there are (potentially) ways to solve each of those, but they will depend heavily on the individual sites' and users' needs. This brings us right back to the issue of non-standard design across sites.

I wouldn't expect well-designed print media from a web designer any more than I would expect a well-designed site from a print professional. They are different professions and problem spaces that sometimes overlap.

Instead of disparaging all web designers as unprofessional morons, perhaps consider that they balanced all of the above along with your points and still landed on a different conclusion from you.

tl;dr the user can (rightfully) control a lot of factors in how they view the web that traditional print and graphic design do not have to deal with.

You make good points. There is a wiggle room between column widths. https://graphicdesign.stackexchange.com/questions/13724/reco...

Somewhere between 80-110 cpl should be adequate to satisfy most deviations in sizes. This "buffer" factor can be accounted for when designing for resizeable interfaces. Column sizes don't have to be absolutely rigid and pixel perfect.

Scaling can be tackled by basing everything on em-units. Scaling using Ctrl + can effectively "zoom" the UI. The relationship between elements should stay the same.

None of this is difficult. We have tools to tackle these problems. Uninformed designers are the problem IMO, but I don't have data for this. My gut feeling is that most designers follow trends, UI frameworks (bootstrap, tailwind), and have stopped building CSS from scratch.

Why are columns hell for accessibility? Given the fluidity of 80-110 cpl, we should be able to account for any size from a phone to large displays. This is a solved problem.

Again, I am not saying there aren't challenges and may be there are better ways to handle all the variables. We should not throw the towel and not think, discuss and debate about it.

Also very good points.

I'll admit I'm not up to speed with a lot of CSS, myself. I'll definitely be looking into how to better use columns.

While I think frameworks can be helpful to keeping a standard look and feel to the web, I would definitely agree that they're often used as a crutch.

Personally (I would probably get shot by saying this) but responsive design is a real problem, it is not a feature, but its a bug - a horrible one.

By appeasing to many screen sizes, we create worse UI for all 3 sizes because no one really designs them for each size separately. Widths are in percentages, flex layout allos collapsable columns and the whole thing is not built from ground up. Either the designer starts with Desktop first and then mobile is a second thought (Bootstrap), or all class names are mobile first (Tachyons).

If we design UI from scratch for each of the 3 or 4 classes of screen sizes, it would be so much better. Completely, from scratch. Not taking the Desktop layout and collapsing the columns. But doing things like button sizes should be smaller for Desktop (mouse) and larger for mobile (finger). Not a single framework does this.

Overall, I agree it's a problem, but I see responsive design as a (perhaps poor) solution to the convergence of three more fundamental problems.

The first being screen size fragmentation. Most tablets fall into a similar size/scale category, so you can have buffers (kinda like how you were saying). However, there are still corner cases where (e.g.) a tablet in landscape mode happens to trigger a different size category. The fact that resolution helps in fingerprinting users is pretty indicative that fragmentation is a huge problem.

The second being the lack of a good way for a page to know exactly what type of device it's displayed on. There are hints/etc. to get close enough. However, it's still a fundamental truth of web development that the browser can always lie to you. Not necessarily a bad thing, but a design challenge regardless.

The third is less of a technical or even a design problem, but I personally think it's the worst. More and more, companies are making increasingly complex sites with no real thought to user implications. I believe this will always be true in a web where the real customers are ad companies and search engines and the user is the product.

On the lines of another point you've made, I'm not suggesting we give up; there are still plenty of ways we could and should improve designs and frameworks (you've outlined some really good ones).

I don't understand why people complain about line length when that really means you should just resize the window to your preference.

On the other hand, pages that stay in a narrow column in the middle when I widen the window really infuriate me, because I explicitly asked for wider columns and am not getting it.

I thought about resizing the window, but then most websites slap you with a hamburger menu and neuter the interface.

The web is such a shit place in terms of design. This is probably why I like reading books and magazines in print. At least the lay out is done by a professional who doesn't have a title "UX/UI" designer and doesn't have a Behance/Dribble portfolio. These people are professionals and they conduct themselves as such.

> I don't understand why people complain about line length when that really means you should just resize the window to your preference.

Different people have different workflows. Many people I know only have 1 browser window open, always maximized, with a ton of tabs open in it. They definitely won't go about resizing the window for no good reason. I don't think any mainstream website relies on the user resizing the browser window for, what I think are, good reasons.

Who does that? I think most people browse the web with many tabs open at once, and switch between them constantly. I don't think it should be on the user to resize their browser viewport every time they switch tabs to maintain a comfortable measure. That's the website's responsibility.

On Windows you can do it with a single keybinding. Windows key + left or right arrow.

every time they switch tabs

The whole idea is that when you have the window at a comfortable width, the content in all your other tabs should also be.

... no? You can switch between YouTube, magazines and wikipeida in a browser. Most written content sites enforce max widths for their content, so you can switch to them in a maximised window in which you were watching youtube without having to resize your window. Wikipedia is an outlier in that, and for no good reason.

Me. I do that.

I disagree. I want to be able to set the width to whatever I want; it is the user's job to set it to what they want. The website's responsibility is to not needlessly override the user's settings. If you want many tabs at once and switching, possibly with different widths, I think the best solution to that is split-screen (implemented in the browser), which solves many other problems too, actually.

My experience is that most people who were raised on Windows will just full-screen everything. Long-time Mac users are more likely to use sized-to-fit windows.

Why do you think is that? Genuinely curious. There's nothing in Windows that prominently wants you to have everything maximized (ignoring the semi-new tablet mode; windowing behavior stems from a time long before that).

macOS, on the other hand, explicitly advertised having an "immersive" fullscreen mode (with a dedicated button in the past).

> I hope we don't bloat up wikipedia pages with too much whitespace. Getting of borders, "minimal" looks bother me so much because they're sacrificing layout for aesthetics. There is a reason why borders exist. It is a line segment that separates logically laid out content into groups.

Wikipedia is difficult to read due to the small font and large column width. Even with the updated versions (I checked French and Hebrew since I can read them) - the column width is in the acceptable range, but the font is too small to be comfortable on a 4k screen. 14px font is a thing of the past. I see Medium, with their thinner columns and 21px font as much more readable.

Use Ctrl(Cmd) and + sign to zoom.

I'm aware, thanks, I'm a developer. That makes the column width wider as well. What you want is a thin column and a large font size, and you can't expect regular users to zoom in.

Ah, so the problem is that the designer used rem or a mix of em/rem units. I personally use Pixels in everything that way the entire thing zooms and all relationships are proportional.

My takeaway from your comment and my experience is that CSS is a mess of a technology. Oh well.

Regular users won't have a 4k display, or they would have detected the problem in testing. If you have unusual requirements such as a very high ppi display, you can set a minimum font size in your client browser, just as the web was intended to be used since the beginning.

The original idea of the web as a publishing medium was that visualization could be determined by the needs and preferences of the final user, and thankfully the technology still allows for it.

Interestingly, that does work on new wikipedia (good on them) but not on many other sites I tested and has some weird results in some places (for example, it doesn't change the regular text size on HN but makes the "reply" link larger). It seems this doesn't have the desired effect or support and could break things for general use. And unfortunately, as a web dev, I have to primarily work with default settings on.

But those sites would be broken according to spec, no? And certainly they won't satisfy any accessibility guidelines.

> Wikipedia is difficult to read due to the small font and large column width.

Narrow columns make text hard to read due to the eye being unable to see whole sentences at once. It's like the "Dick and Jane" books of old: "See Spot! See Spot Run! Run Spot Run!" Books for adults aren't written like that (as print novels attest) and there's a good reason.

Books for adults aren't given narrow columns in the sense of a newspaper column, but they're absolutely typeset with attention paid to line length -- it's customary to aim for around 55–75 characters per line. On most displays, Wikipedia's lines are, by conventional typography standards, just too darn long.

What? That's the exact opposite effect that happens with wide columns. With a wide column, your eyes have to scan all the way left to right. With a narrow column, you don't have to scan as much.

Also the largest "adult" books (non-textbooks) that I have take up about 1/5 of my 43" 4k monitors screen. If you aren't adding a healthy text margin, my eyes have to scan left to right twice as much as with a book. If you want to talk about novels - my screen is 8 times as wide as them, so they are naturally using much narrower columns than most websites.

This is the change I understand the least. If it was about actually collapsing the sidebar I'd understand, but it seems to literally just hide features and replace them with a useless grey area.

Same here, I hate it. Here's a userscript that expands the language sidebar: https://github.com/ayyrx/userscripts/raw/master/wpfix/wpfix....

Edit `const enableLanguageSidebarAltView = true` to `const enableLanguageSidebarAltView = false` to make it look exactly like it used to do before that dumb button was implemented

This is how I use the fullscreen expandable images:

1: Go to a page.

2: Click on an image.

3: Close the image.

4: Click the browser back button.

I am now at the image again. This is surprising and I cannot seem to learn this.

Update: This is no longer the case. I can not reproduce this any more. Great!

The worst part is when you eventually make it back, it loses your position on the page. They made this change years ago and it still drives me nuts.

I disable all sorts of features on Wikipedia (and MediaWiki sites in general; why can't it support a cookie to automatically change these settings, so that you (the end user) can copy your preferences between MediaWiki instances merely by copying a cookie?), and would want to disable some others as well, such as the custom widgets and most animations. I do want some of the features that use JavaScript, but not all of them. The browser should have a better way for the user to adjust individual scripts.

I think the only times I use it is to go to random articles, which can be quite fun if you're in the mood to discover new things. However,I couldn't tell you a single other function they have on that side bar even with a gun to my head. Just went to check it and apparently they let you print pages out as PDF, news to me. Wikipedia really doesn't advertise its features much.

Ooh! I recently discovered the "Print to PDF" feature too. I used it to print out some pages for offline reading when I took the kiddos on an adventure outside cell network range. It worked really well.

It's actually an obsolescent feature. With modern browsers, you can just use the native "Print page" feature and the content will be styled in a paper-friendly way.

Like almost every MediaWiki feature, there's a massive pile of Wikimedia drama behind it. They went through at least three major iterations, almost all behind the scenes, for exporting content for offline viewing, including PDF at all stages, and eventually kind of gave up.[1][2][3][4]

This also encompassed the mostly ill-fated PediaPress system to get printed books of wiki content collections, the Collections MediaWiki extension,[5] and various back-end rendering engines that came and went (some without ever being fully deployed in production).

All to have a link that, in the span from OCG to Proton, was made mostly redundant by browsers implementing "Print to PDF".

[1] https://www.mediawiki.org/wiki/Offline_content_generator

[2] https://www.mediawiki.org/wiki/Extension:ElectronPdfService

[3] https://phabricator.wikimedia.org/tag/proton/

[4] Confusion over knowing who owns or maintains the PDF service: https://phabricator.wikimedia.org/T247310

[5] https://phabricator.wikimedia.org/T256071

Reducing maximum column width would also be my #1 suggestion.

Maybe that can be taken care of through themeing/browser plugins? If anyone has good ones to recommend, suggestions appreciated.

They are reducing maximum column width, but perhaps not as drastically as you'd wish:

https://www.mediawiki.org/wiki/Special:MyLanguage/Reading/We...

Yeah, I don't think 900+px is ideal for reading on a desktop computer. Better than nothing, though!

Resize the window yourself then. I get far more annoyed at sites that refuse to flow text to the desired width.

This is a good strategy called "blaming the user" and means you should never design computer interfaces! Full width site text means the creator has no understanding of basic HCI

Full width site text means the creator has no understanding of basic HCI

No, it means the creator thinks of users as knowledgeable and able to take care of their own personal needs, and not as idiots who don't know how to use their computer's window manager.

Perfect example of the former? HN itself.

a) People don't know their own needs until you show them what their options are. Are you familiar with the literature on optimal line length that is quoted in the OP? If so, good job. I think it's fair to say 99% of people aren't. Consequently, if you asked people if they wanted an optimal reading experience, then they would have to concede that they are not knowledgeable about what that means, and thus that they should adopt different settings than what they would instinctively pick.

b) The alternative is not that people are "idiots who don't know how to use their window manager." I don't want to have to use my window manager. Manually resizing windows for each tab to get the right line length is a huge waste of time and seems idiotic to me. I want a professional designer to make it so I have the best possible reading experience on the websites I'm browsing. Because I'm humble enough to know I couldn't reach that standard by "using my window manager".

That argument completely falls flat if you consider the actual result: https://i.imgur.com/7mAQy5H.png It enrages me to no end that this is sold as an improvement.

• Who wants to read four to five words per line? THIS LINE SIZE IS ACTUALLY UTTER ASS.

• In the good design, it was easy to resize to window to make the line length narrower. However, in the bad design, there is no recourse to make the line length longer.

The "actual result" looks nothing like that in my browser, so I can't really judge, although I agree that it looks terrible on your screenshot (text overlapping in links, etc.).

However, the line length, while suboptimal there, is pretty commonly encountered — pick up a newspaper and look how many words fit in a column.

> I almost never use the left hand side bar (and I have a feel almost no one does)

Editors do. The sidebar contains tools useful for maintenance works. Just to name a few, I use "What links here" to check links and redirections, "Wikidata item" to update metadata - these two are the most used features by editors: after contributing a new article, you need to add/fix some inbound links, and to link it to editions in different languages. Also, there's "Page information" to see statistics, and checking "recent changes" for spams and vandalism is a hobby for some people who need to kill time.

The current website works for me, I hope Wikipedia will keep it as an option.

If you're an editor doing editing, you'll be logged in, so presumably they will just remember your preference, or give you an option.

I use those functions too, although there are accesskeys for those commands, so the side bar is not needed. That is also the case for editing, talk pages, history, etc; there are accesskeys for those too. So, all of the commands can be hidden, in order to make more room for the article text instead.

> I almost never use the left hand side bar (and I have a feel almost no one does)

If you speak different languages, the left hand bar is very useful to switch between different language versions of an article.

True. But the gif in the article indicates they intend to move the language selector to a more prominent location.

While the language selection on mobile Wikipedia is in a very prominent spot, I often struggle to find it, because it’s just some Asian sign I can’t make sense of. I hope they don’t do this on desktop too.

I use that quite a lot, because google periodically just refuses to acknowledge that I usually want my links in English despite living in Germany. English quality is often times a bit better, but it is also useful to check in multiple languages, as sometimes you get different information, especially on more controversial topics.

or regional ones. topics that relate to the german area are usually more detailed in german. same for other areas and languages to the point that it can be worth it to use machine translation to look into a foreign local topic

That's how it should be at least, but not always! - Probably the best department for german literature is in Princeton, and my favorite scholar on german existentialism, Walter Kaufmann, also an American at Princeton.

try changing your IP address, OS language/region and browser language to English

I'm not aware IP addresses have language settings associated with them? since when is this the case? any links for further information?

For a bunch of different reasons, many sites will try to guess where you are located based on your IP address. One misguided thing some sites do is select language based on that lookup.

Although it wouldn't surprise me if some countries try to legislate about that and everyone with an international presence has to do it.

the technology is called IP Geolocation. IP addresses are able to be resolved to countries, cities, towns and in some cases more granular than that, depending on the ISP. since around ten years ago but databases have matured since then. what I was trying to get at was masking your actual IP address by way of proxy server or VPN, to make it appear as if you are connecting from another place. it also aids anonymity and bypassing geoblocked content

I have the same problem, so I just save English UI as bookmark/search engine and start from there.

https://www.google.com/webhp?hl=en

It would prioritize English result.

I actually have three languages of Google on my bookmark bar precisely because of this, and they work like a charm.

This. And it’s the one thing that annoys me to no end about the mobile version, that the list of language editions isn’t there at all.

The language button is right at the top of the page. If anything its more accessible on mobile?

Well, it's secret on mobile. I had the same problem - I wanted to switch languages on mobile wikipedia, but the page appears to provide no way to do that. Functionality that has been carefully designed so you won't find it isn't really an improvement over functionality that isn't there.

> Functionality that has been carefully designed so you won't find it

The button is labeled 文A, which is quite common for translation service, and is just under an article title so it’s literally the most visible UI element. It’s difficult to make it more accessible than that...

Pretty sure 99 out of a 100 don't know what "文A" means. I've had the same complaint, - never once did it occurs to me that "文A" meant translation.

This to me is a testament to the fact that most buttons should actually be text unless extremely common like the hamburger menu, but even that's debatable.

> This to me is a testament to the fact that most buttons should actually be text unless extremely common like the hamburger menu, but even that's debatable.

I agree, especially on mobile (even in 2020, many users — who often just got used to the hamburger menu — don't realize that the vertical ellipsis is a symbol for "menu" or "more options", it often just looks like a random decoration to them), although on a desktop website or app you (hopefully) have the option of hovering the mouse pointer (even accidentally) over any unfamiliar bit of UI gubbins to get a clue.

I'll note though that the specific example of "文A" is, in fact, a text label. The first Chinese glyph even translates as "text".

> I'll note though that the specific example of "文A" is, in fact, a text label.

Only in the sense that those glyphs are used in certain writing systems. It's not text in the more important sense of expressing a linguistic message. It's just random characters. "文A" is a text label to exactly the same degree that ":-)" is a text label.

Note in particular that the Chinese glyph does not translate as "language". That would be 语/語. As you accurately note, it translates as "writing".

That's not quite true - 语 as in 汉语 is a spoken language or dialect. 文 is used for written language, and can mean a language in general, a writing system, or an entire culture, depending on what you combine it with.

> depending on what you combine it with

It's standing alone here. I'm aware of words like 文明 and 中文, but here are the 14 glosses for 文 in the 现代汉语规范词典:

1. (verb) to tattoo or paint patterns or words onto a body

2. (noun, literary) a pattern, particularly as of wood grain

3. (noun) ancient rites/ceremonies

4. (noun) non-military affairs (opposite of 武)

5. (adjective) gentle; not fierce

6. (noun) indicating phenomena of nature or of human society

7. (noun) writing

8. (noun) an essay

9. (noun) the humanities and social sciences

10. (noun) an official document

11. (noun) Classical Chinese (the language that is to China as Latin is to southern Europe)

12. (measure word) used for the copper coins of traditional China

13. (verb) to cover; hide

14. A surname

Most of these senses come from words that include the morpheme 文, not from uses it permits alone, but "language" is still not even listed.

新华字典 has a gloss of "language" with "written language (文字)" and "foreign language (外文)" given as examples. That's where I'm getting it from.

Well, it has one merit at the very least: regardless of the interface language, you will find that button.

That isn't true either. The button has no borders nor any other indication that it's a button; it appears to be a simple decoration on the mobile page.

I only learned about it when somebody pointed it out to me in an HN thread a couple of years ago, like the parent. The button is small and I think since I don't speak Chinese or Japanese my brain tends to skip Chinese characters as I assume that whatever they convey is not aimed at me. It's also alone on the left-hand side, with no decoration or styling showing that it's interactive.

A flag icon or simply some more explicit text would be vastly easier to understand for me, especially if it actually looked like an interactive element.

Flags are for countries not languages. I don't like the current solution too much but I'm glad it's not flags.

Okay but that's an issue with UX and discoverability which is very different from "language editions isn’t there at all".

How would you solve this given the limited space? A label saying languages is the mosy obvious but real estate is a little limited.

I'd hope that if the icon was prominent in desktop with a label that would reinforce its discoverability.

> How would you solve this given the limited space? A label saying languages is the mosy obvious but real estate is a little limited.

Try looking at a wikipedia page on your phone. You could replace the 文A button with one that said "antidisestablishmentarianism" and there would still be plenty of space. It's floating at the left of an empty row.

I agree it totally could be improved. Perhaps they're being careful? Elsewhere in the comments, someone showed that logged in users have more items in that bar (https://imgur.com/llv2rtc). That might not work so well in portrait.

I have 5 items in that bar on my Samsung Galaxy and I have no space for a label. As the screenshot shows the labels are there, just not visible until a certain breakpoint

I agree that the UX could be improved and there is plenty of evidence to support that. On the other hand the edit icon is super discoverable and used without the label so I think the challenge with the language icon is 1) there are not many multilingual sites and 2) the other icons there potentially cause the user to ignore them entirely.

Throw in the 200+ languages and longer labels in some of them and it becomes even more complicated...

> I think the challenge with the language icon is 1) there are not many multilingual sites and 2) the other icons there potentially cause the user to ignore them entirely.

Multilingual sites aren't rare at all. There is a conventional way to display a language selector: it's a button (usually a dropdown menu, if you click on it) with a national flag and the name of the language.

The big problem on mobile wikipedia is that wikipedia already has a well-established way to select the language you want to see the article in, and the mobile site completely removes it.

Using a national flag is a really bad UX pattern given the political ramifications and potentially offensive. Languages are not owned by countries. I am not aware of a multilingual site that provides over 200 languages in such a way that its country neutral (switching to a Spain based shopping site is not the same as switching to Spanish)?

As I've said before the mobile site doesn't remove it. It just changes the mechanism for understandable reasons based on the medium.

Nice to chat to you.

So I’ve been switching to desktop version, locating the language sidebar, then switching back to mobile for nothing all this time?!

There is room for improvement here. Wiki could detect language preferences based on accept-language Header. "en-US,en;q=0.9,pl;q=0.8" is a pretty good indication I want English and Polish translations to be the first one listed. Alternatively/additionally you could let logged in users define sort order/preferences.

As is now I have to inject

    ['.vector-menu-content-list .interlanguage-link.interwiki-en', '.vector-menu-content-list .interlanguage-link.interwiki-pl'].forEach(el =>{
      if (document.querySelector(el))
      {
        el.style = ''
        let lang = document.querySelector(el)
        lang.parentNode.insertBefore(lang, lang.parentNode.firstChild)
      }
    })

They already adjust the list by the frequency you visit them. They don't by default show all 100+ language links anymore for a while.

Right, I did not like this change at all...

I use the langlinks across many languages, way more so than the average user so my use case is different.

The list is meant to change according to your usage, not the average user. Of course, you have to log in.

I use the left hand side bar, I like to read the articles in different languages.

I am constantly juggling between several languages and always preferred the desktop version for this reason.

I also love the new-ish mouseover previews. That was a great change imo.

As someone "reading with the mouse" I love them until the mouseover appears over the piece of text, I was just going to read.

"Not changing for 10 years..."

I absolutely love that part about Wikipedia.

The article refers to this: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...

From what I can see, this particular change is already live in https://fr.wikipedia.org/

Then it explains the difference I've seen for a few weeks, thanks. It's not much different, mostly narrower.

I use a lot to switch between portuguese, esperanto and english. Portuguese to read national/local articles, esperanto for every other and english when the other two have incomplete articles.

> I’ll also note that they definitely have changed some UX stuff over the past 10 years.

The mouseover popup/tooltip for links showing a brief snippet of other articles is so great that I find it irritating when other sites don't have it.

The problem for me was that when opening links with Vimium, it also activates that popup, thereby obstructing the text. In the end I had to turn off the popup, good thing it can be disabled.

"that when paragraphs are that wide they become harder to read"

I actually use the mobile view on desktop for this reason. The mobile view will have white space on the sides if you do full screen, but I usually have two windows side by side, which results in all text, no sidebar, and a more minimal top bar. There is a 'mobile view' button on the footer of every page, or you can throw an 'm' between the language and base url.

The sole critique of the UX of Wikipedia that I have is that the normal version of Wikipedia redirects you to the mobile version when using a mobile device, and changes the URL while doing so. This is why we end up with all these m.wikipedia links. The mobile version, however, does not redirect you to the normal page when using a normal computer.

So people like myself constantly have to edit the "m." from wikipedia links to get the normal version. I really dont get why they are doing that.

I honestly think they were exploring replacing the desktop version with mobile at some point and used desktop m. removal as a gauge of aversion to the change.

That can't be true because the mobile version doesn't allow access to all of Wikipedia's functionality, such as talk pages, unless they've made some serious changes. (More precisely, I don't remember there being any way to get from an article to the article's talk page without editing the URL in the mobile version.)

This was fixed quite some time ago, there's now a Discussion tab/link on the mobile version.

Can you tell me you I can get there, e.g., here? https://en.m.wikipedia.org/wiki/Test

The work "discuss" does not show up in the source code, you can check "curl https://en.m.wikipedia.org/wiki/Test | grep -i discuss"

The discussion is called "talk" on the desktop version, but it is also missing on the mobile one. Or there is some javascript trickery going on, but I clearly dont get it.

Not sure why you're missing but https://i.imgur.com/llv2rtc.png

This is how it looks in my Firefox: https://imgur.com/a/x2Gl1Sj

And this is how it looks in my Chrome: https://imgur.com/a/LQ7pmH8

Ah, you're right.

You need to login and enable "advanced mode" in setting (in hamburger menu) to see it.

I see.

But this also means that every mobile user of wikipedia (I guess the majority now?) which is not logged in and enabled that feature (for sure the majority) does not even know about the discussion pages of wikipedia articles. This is super sad.

Also, the mobile version collapsing the zippies, which means search doesn't work.

What are "zippies"? I tried searching but couldn't find a relevant definition.

On Wikipedia, the content section headers. More generally, expandable sections of a page that default to being collapsed.

Sometimes called accordion menus. See: https://jqueryui.com/accordion/

On mobile wikipedia site go to hamburger icon - settings and then Expand all sections

Oh, nice, this is apparently a persistent setting too! Thanks!

I made extension that does exactly that if you want

https://github.com/spixy/NoMoreMobile/blob/master/README.md

That's appreciated, thank you. I already have such an extension to redirect reddit to old.reddit. It works and I can somehow see why such a thing might be necessary for commercialized platforms such as reddit.

However, I'm suprised that this is neccessary for wikipedia. I guess it was more work to write the extension than to fix whatever is going on on wikipedias side. But then, on the other hand, maybe writing the extension and stop caring about what is going on on wikipedia is easier.

I'll never understand the lack of a "prefer full site" link in the footer of every page. Common sense / table stakes for usability since forever.

Firstly, at the bottom of the page in either desktop or mobile you can get to the other with a mobile/desktop link. (Discoverability fail maybe?)

Secondly, there's discussion about serving everything from a single domain at https://phabricator.wikimedia.org/T214998 , which I guess would enable the normal mobile browser feature of switching between desktop and mobile.

> Firstly, at the bottom of the page in either desktop or mobile you can get to the other with a mobile/desktop link. (Discoverability fail maybe?)

For a long page, scrolling to the bottom might take even longer than just changing the URL. Yes, there are keyboard shortcuts to scroll to the bottom, but so there are shortcuts to edit the URL bar. It is, in any case, an annoyance that always(!) takes some extra time.

[Edit: I love that switching to the desktop version is literally the very last word/link of the mobile version. Even after the link to the "Privacy policy" and the "Terms of Use" that probably nobody in the history of homo sapiens ever clicked]

> Secondly, there's discussion about serving everything from a single domain at https://phabricator.wikimedia.org/T214998 , which I guess would enable the normal mobile browser feature of switching between desktop and mobile.

The last comment on this discussion is, quite ironically: "Have been somewhat expecting this to be fixed for the better part of 7+ years now. Hopefully this can be implemented soon!"

Except there should not be two versions at all and instead they should just make the desktop version responsive and strip out the bloat - I don't want an article to on desktop to load six different javascript files and have a giant banner at the top any more than on mobile.

https://en.wikipedia.org/wiki/Test is 27 different requests for me - that is inexcusable for mostly text content.

Facebook also does this.

I find the mobile version to be pretty poor and mostly the opposite of what I want when using wikipedia in a mobile capacity.

Mobile has higher latency and a small screen, so its important that I not need to make lots of request and its important that I can search inside documents. Both of which are broken by wikipedia's mobile interface.

I wonder if there's a functional reason why they do this, rather than just implementing responsive design / media queries? I seem to remember more sites doing this ~5 years ago, but based on what I see, it has fallen out of favour.

(Actually found some info if anyone is curious: https://medium.com/freely-sharing-the-sum-of-all-knowledge/w.... Though the article helps explain some of the context and reasoning, I don't think it really justifies the divergent experience and imperceptible progress on improving the desktop experience)

Also in-page hovers to other articles!

> the first two things I’d point out would be that I almost never use the left hand side bar (and I have a feel almost no one does) and that when paragraphs are that wide they become harder to read

Good news! The sidebar makes the paragraphs narrower.

But yes, that wide-text issue makes it incredibly annoying that so many HN users provide explicit links to mobile wikipedia pages in their comments. Don't do that! The mobile pages have bad readability in normal aspect ratios! If I'm on a phone, ordinary en.wikipedia.org links will redirect to en.m.wikipedia.org, but the reverse is not true! There is no conceivable reason to provide a mobile wikipedia link, and plenty reason not to!

> I almost never use the left hand side bar (and I have a feel almost no one does)

The left sidebar has two killer features for me:

1. Finding canonical translations for technical terms. You need to know what the standard way to translate "hardware acceleration" or "differentiable manifold" is in French? Go to the wikipedia page and hover over the language switcher link in the left sidebar. Done. This has become one of my indispensable tools.

2. Learning about historical events where there are multiple inevitably biased narratives. For example, want to know about the Islamic Golden Age? The English, French, and Farsi versions have significantly different content from different perspectives (I would assume the Spanish and Arabic ones are also equally interesting). I highly recommend this exercise especially for history that one is taught in school, e.g. if you're American and can read Spanish, I bet the Spanish entry on Mexican-American War will teach you a few things you had never heard of.

You summarize it very well. Those are the two big usage I have from that bar. In fact I switch so often between languages I wish they were displayed upper in the bar (btw I don’t like switch language on mobile), and personalized with my 4 most used languages on top. Sometimes a language I want to read is hidden and it’s super annoying to get it.

> 1. Finding canonical translations for technical terms.

OMG yes I do this as well. Google translate is unreliable for technical terms, regional vegetables/fruits, cultural concepts, and lots of other things.

EDIT: Wikipedia is also good at differentiating regional variants of a language, e.g. the country of Laos is 老撾 in Beijing Mandarin and 寮國 in Taiwanese Mandarin and Wikipedia knows this. Likewise, a USB drive is almost universally called "U盤" in Mainland China but this word is virtually unknown outside Mainland China. It's actually a good way for native speakers to look up one-off words like this when writing documents intended to be read by another region because you really just need to replace a few nouns here and there.

The direct link to the commons page is also useful for finding pictures related to a topic.

I personally had no idea this existed, even though I would (and now will) use it avidly. So that's probably an indication that the UX needs to change to improve discoverability!

I second using Wikipedia for translating, most of the time is better than using a translator or using a dictionary and sometimes is the only option for more technical or specific terms.

I don't use it for comparing between languages much because I'm bilingual and my native tongue Wikipedia is not that big, but sometimes is really interesting to see the different perspectives.

Regarding the comments about the importance of language links in the sidebar: if you look here you can see that the language links will be moved to a button/menu in the article header — https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme... The conclusions of the user testing show that people have a much easier time finding them in the new location.

Their test group for this feature consists of 8 to 9 people, with 5 in a control group. You'd think that for one of the most visited sites in the world, they'd have larger test groups?

Testing large amounts of people doesn’t always produce better results. https://www.nngroup.com/articles/why-you-only-need-to-test-w...

Will the new menu require JS to access?

I just hope you can still simply hover your mouse over the languages links to see the translation without having to click and go to the foreign language article.

Absolutely, the only time I've ever used the sidebar is for language change, but with this change they are moving that to a more accessible place (Which is nice), but it also means the sidebar is now truly useless :)

Changing the language, yes. But translating at a glimpse will get lost this way.

Go to the wikidata page and it has the translations.

That's a click more though, while the current method doesn't necessitate a single additional click.

I look at the different language wikis all the time for that reason (and because I'm a native Spanish speaker who prefers the English Wikipedia), but it's just routine to scroll to the language selection list completely ignoring the controls of the left pane, that I may have used twice in the last 10 years merely out of curiosity.

I also find your first point to be a truly indispensable tool. How else do you know what they call carbon fiber in German? [0]

But the second is a touchy area. In fact, Wikipedia's co-founder recently wrote a blog post detailing how its neutral point-of-view policy has flopped, in the name of fighting false balance. [1] His examples are pretty embarrassing, but more important in that Google points human "Search Quality Raters" to Wikipedia to understand "reputation" and maintain a supposedly even political bias. [2]

[0] Kohlenstofffaserverstärkter Kunststoff, of course.

[1] https://larrysanger.org/2020/05/wikipedia-is-badly-biased/

[2] https://static.googleusercontent.com/media/guidelines.raterh... Pages 16-18

I don't understand Larry Sanger's complaint about NPOV. If a neutral encyclopedia was required to list all minority points of view on every topic then nothing would be knowable. It wouldn't be able to say that the earth is round. If saying that the earth is round is biased then neutrality is worthless and not worth pursuing.

In even simpler terms, the use of editorial judgment is required to write an encyclopedia. Always has been, always will be. A website free of editorial judgment looks like 8chan, not an encyclopedia.

Even 8chan had some level of editorial judgement, however small it was. It was there.

The Admin has been very active in preserving QAnon's presence on the board. Potentially to the point of hijacking the QAnon tripcodes.

https://en.wikipedia.org/wiki/QAnon#Identity_of_%22Q%22

Well, i dare say, that would be an example of an editorial judgement. Agreeable or not.

The original statement of NPOV was to at least mention any significant view supported by a significant minority of experts or people involved; not EVERY topic. It makes sense that, if you want the encyclopedia to be a starting point for investigating a subject, it informs you of the existence of significant non-sanctioned views.

In practice, this need is usually satisfied by the Talk pages and archives. The published article is sanitized, but if you really want to learn about the controversies in the topic, your best choice is to dig deep in the discussions that resulted in the controversy being excised from the visible version. It's quite rare that the talk pages are also purged as well.

When I've been to the talk pages they were populated by even-less-neutral discussion about how to expunge anything that might offer support to people who believed the right-wing position.

Though that’s a rather technical term for carbon fiber that I suspect nobody uses when speaking or even writing to each other in a less formal context.

I’ve heard it being called just “Carbon”, pronounced with a long “o”, frequently. Since the translation for the generic element, carbon, is “Kohlenstoff”, and that word is very commonly used, the opportunities for confusion between carbon and carbon fiber is less than it might seem.

The literal translation for carbon fiber would be "Kohlefaser" and that is also used quite commonly.

I admit I'm not in any field that deals with materials a lot, but OP said "Kohlefaserverstärkter Kunststoff" (which I likely wrongly called "carbon fiber" in English), is "Kohlefaser" really the same? Maybe it is and I'm just ignorant about that.

My German-as-second-language understanding is:

Kohlenstofffaserverstärkter Kunststoff == Kohlen (literally coal but understood more broadly as any carbon) stoff (material) faser (thread) verstärkter (reinforced) Kunststoff (plastic).

Depends. (As everything always does.) “Carbon fiber” literally means just the black threads, in English as in any language. When you say “This bicycle / fishing rod / automobile part is made of carbon fiber”, what you _actually mean_ is that it's made from carbon fiber- reinforced polymer (=“plastic”). Stuff isn't built from _just_ the fibers; the plastic needs to be there to keep them together / they're just there to reinforce the plastic (or both).

The GP (G-G-G...P?) post seemed to be using the shorter expression, but as a shorthand for the longer (as most people do) in English but not in German, which may have caused some confusion.

But it's the same in both (all) languages: The shorter expression technically means just the reinforcing fibers; the actual material used to make stuff is technically called the longer expression; but in ordinary usage most people use the shorter expression to mean the longer one.

In my experience 'Kohlefaser' is a pretty common technical term, I've only ever encountered 'Karbon' w.r.t. bicycles (but that just be my limited view).

> His examples are pretty embarrassing

Some of the political ones show what is more easily described as bias, but his points about Global Warming or the MMR vaccine show exactly why "NPOV" for any extent is a bad idea, and why the new policy of "avoiding false balance" actually makes a lot of sense.

As a couple of other responses have indicated, this is not a reliable way to translate terms.

Another bit of anecdotal evidence on translation: I recently wanted to find the idiomatic French for "electronics packaging." Google Translate gets it wrong, and there's no French wiki page to refer to. The source that came up with the goods was the "translations in context" snippets here: https://www.linguee.com/english-french/translation/electroni...

Linguee is not a reference either for English to French, simply because most of the side-by-side translations it uses are bad translations; and also because it mixes French and Canadian sources, which are sometimes completely unrelated to the point that a native French won't understand a Canadian translation and vice-versa.

Deepl, from the same company, is much better and is currently the best online translator.

France French and Canadian French are not that different and are certainly mutually intelligible, kind of like US English and Australian English. (Except of course if you're a rude Parisian and act like any accent except yours is undecipherable).

You can certainly understand them if you're talking with a Canadian, because you can always ask for clarifications. But my point is not about accent, it's about taking a Canadian translation on an online translation service and mistakenly using it in a French document if you're not a French speaker. Good luck having your French readers understand what's a balado (podcast), a Bazou (a car) or a Boucane (the smoke), and that's just a handful of the B words. It doesn't matter whether you are a rude Parisian or not (what's with the stereotyping?)

Or tell them on your gardening website to fill a chaudière to water their garden.

Un bazou doesn't mean a car, it's a slang word that means jalopy. In France French, one would say une guimbarde, and I suspect lots of Canadian French speakers wouldn't understand that word. Slang words tend to differ a lot from country to country, no matter the language. A translation service that translates car to bazou or guimbarde is broken, but this has nothing to do with Canadian vs. France French.

> How else do you know what they call carbon fiber in German? [0] > [0] Kohlenstofffaserverstärkter Kunststoff, of course.

Well, it actually not that simple :)

Kohlenstofffaserverstärkter Kunststoff[1] is carbon fiber reinforced polymer[2]. But it seems like carbon fiber is also used as a short hand for carbon fiber reinforced polymer. Similarly, Germans often call Kohlenstofffaserverstärkter Kunststoff just Karbon.

But the translation of the technical term carbon fiber[3] is just Kohlenstofffaser[4] (which is quite a literal translation).

But indeed, it is really nice how transparent that is when looking that the wikipedia articles.

[1] https://de.wikipedia.org/wiki/Kohlenstofffaserverst%C3%A4rkt... [2] https://en.wikipedia.org/wiki/Carbon_fiber_reinforced_polyme... [3]https://en.wikipedia.org/wiki/Carbon_fibers [4] https://de.wikipedia.org/wiki/Kohlenstofffaser

It's not my mother language but I speak German, and I keep reading "server" when trying to read "Kohlenstofffaserverstärkter". IT sector ruined my brain.

The combination of political opinion expressed in [1] + the author's wildly incorrect past statements is all I need to know that Wikipedia is doing things right:

> Since 2002, Sanger has been critical of Wikipedia's accuracy. ... [In 2007], Sanger again criticized Wikipedia, stating it was "broken beyond repair" and had a range of problems "from serious management problems, to an often dysfunctional community, to frequently unreliable content, and to a whole series of scandals".

https://en.wikipedia.org/wiki/Larry_Sanger#Post-Wikipedia

I guess you don't need to know much to ascertain the truth of something.

I know A. the examples he gave do not justify his position that the "false balance" policy is bad due to his clear extreme political bias in favor of Trump and B. he has a track record of being very, very wrong about systemic issues at Wikimedia which discredits his position on this particular (supposed) issue.

Sanger will never forgive Wikipedia for getting along just fine without him.

I just read [1].

I'd hope that a person with Sanger's experience and insight would at least float suggestions, proposals, wish list, or any thing at all, to achieve something he'd consider more neutral, objective, or something.

everipedia.org I guess does some stuff differently. But if it has a different take on neutrality, it's not jumping out at me.

Sanger has some role with Ballotpedia? Maybe his vision for neutrality is there?

Just sitting here, I can imagine at least three different crazy experiments to play with neutrality. And I know nothing.

Also:

I was willing to at least consider anything Sanger had to offer, given his CV. But generally I fast fail (flip the bozo bit, summarily dismiss, shove into the memory hole) any media critic leading with "liberal bias".

I think he just has muddled reasoning. For example, his essay says something about Jesus, the Christ label, how the wiki is wrong... Or something. I was raised Christian, so I'm moderately inclined towards biblical navel gazing. But if Sanger had a point, it's lost on me. I'm just more confused after trying to parse his thesis.

Further:

I'll read any proposals for mitigating social media. I honestly can't even criticize whatever this is:

How to Fix Social Media in Three Easy Steps [2020/09/20]

https://larrysanger.org/2020/09/how-to-fix-social-media-in-t...

Non sequitur?

I was willing to at least consider anything Sanger had to offer, given his CV. But generally I fast fail [...] any media critic leading with "liberal bias".

Especially when one of the main criticisms is "It's biased to say a false statement is false".

Sanger's fundamental misunderstanding is that a neutral point of view doesn't mean that the thing you're writing about is also going to be neutral.

Keen point. Thanks.

It just now occurs to me that you're probably referring to the epistemological crisis. I don't actually know what that means, but please humor me.

Sanger teaches philosophy. To him, maybe there is no truth? Or that all truths are equal? Or something like that.

More than a handful of the geeks I've worked with were afflicted by the recursive discursive thing. Most bad was the philosopher software architect. Actually repeatedly debated metametadata, the data about metadata. I wanted to kill myself.

Tying this back to current events: It might be useful to have some canary questions, to determine the epistemological bent of the other participants. It's pointless to argue about facts if the other party doesn't believe in facts.

For English-French translation in Québec, have a look at http://m.gdt.oqlf.gouv.qc.ca/index.aspx

Just out of interest, I tried "electronics packaging" (which other sources seem to indicate is called either "habillage" or "packaging" in French). I got this http://m.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=1893553... result which says "electronics packaging designer" translates to "concepteur d'assemblage électronique." So now I'm not sure what to think. The suggested translation doesn't include the word "habillage" which I previously thought was the term I needed.

"Habillage" (literally "dressing") in this context relates to packaging of a concept/proposition i.e. the marketing around it (or "spin"). The french word for "packaging" in the physical sense would be "emballage" (literally "wrapping"). Some would use "empaquetage" but that is less common.

So "electronics packaging" would translate to "emballage/empaquetage de composants électroniques".

Are you sure about this?

I know linguee.fr has been criticised, but check out these two analogous pages found via a search for "electronics packaging" there:

https://schroff.nvent.com/en/schroff/about-us

"The brand Schroff, which belongs to the business unit of nVent Technical Solutions, has been a world leader in electronics packaging for over five decades."

https://schroff.nvent.com/fr/schroff/about-us

"La marque Schroff, qui appartient à l’entité légale nVent, est leader mondial dans le domaine de l’habillage électronique depuis plus de cinquante ans."

This makes it look extremely like habillage doesn't just mean what you claim it does "in this context."

Emballage was indeed my initial guess for the appropriate French word, but I, you know, did some research before jumping to a conclusion?

That's quite a stack of subdomains, any sense to those? .qc.ca I can recognize, and gouv is for gouvernment.

So you've got 3, the m at the start is obvious - there's only two left and they're both spelt out in the header of the webpage.

> 2. Learning about historical events where there are multiple inevitably biased narratives.

Interesting anecdote: Linguistically, Serbian and Croatian are almost identical, except for the obvious thing that Serbs write in Cyrillic alphabet, while Croatians use the Latin alphabet. Politically however? Holy what a can of worms. "Inevitably biased" is putting it mildly, outright history revisionism puts it better, and it has been twice a subject of widespread outrage: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2...

(in case it's relevant, I'm half Croat, and have a massive dislike against NDH supporters and any other fascist/fascist apologets)

I've never realized how often I do both scenarios but now that you said it, that's exactly right, it is very useful. Being multi-lingual myself, the benefit of the switching language is not just for bias but also because some topics are just more expanded in other languages. I keep Google in English so obviously English wikipedia articles are the ones showing up, but let's say I look at some francophone music artist, i'm more likely to get a longer wikipedia page once I switch to French.

> if you're American and can read Spanish, I bet the Spanish entry on Mexican-American War will teach you a few things you had never heard of.

That's a great idea, I'm gonna do exactly that tonight. Thank you very much!

I guess monolingual people simply don't understand some things. That there is so much information not represented in English Wikipedia, or, say, that some foreign person with a stub article is many times more valuable, interesting, relevant than other foreign person with a decent article (when it is clear from the content in another language). Or that “information on the internet” doesn't simply appear out of nowhere, that people work on it, and the process is far from being optimal or comprehensive (never was, and never will be, sadly).

The difference of perspectives is also quite enlightening. I'm not talking about obvious transitory trifles like Obama vs Trump vs Clinton — it is pathetic that a free encyclopedia, of all things, wastes so much time on those, — or who's at war with whom for which reasons. I mean deeper differences in the world view. So there's some “highly controversial” (whatever this means) topic, and there is a completely regular article on it in other language, no signs of editing wars or flame wars, doesn't seem all that important altogether. You obviously start to meditate on why it couldn't be written the same way in the first language.

Just like many pop-science fans believe that the cardboard presented to them is a “real science” and the only true world view, most people talking about “approaching neutrality” assume that basically everything can be analyzed from the same common base, and, of course, their own beliefs are that common base. This, obviously, is not a good way to understand anything that belongs to a different culture.

I do 1. quite often, but I've also noticed that sometimes, the list of languages the term is available in varies between languages, which makes no sense to me.

> Learning about historical events where there are multiple inevitably biased narratives

Not just historical events. For example, Vladimir Putin's Russian page looks very different from the English page. If I suspect bias, one quick check I always do is to read the page from another language using Google Translate. Does not always work, but sometimes you get more information.

> Finding canonical translations for technical terms

Exactly.

In addition to these, I also use the sidebar's random button when learning a new language. Instead of committing to reading a book or reading the news its nice to just flip through random articles and trying to power through them, sometimes with the aide of wiktionary.

Years ago Wikimedia external-to-community "UX" staff previously forcefully hid the inter-language links against substantial community outcry. The result caused a devastating loss of traffic to other languages and, ultimately, a quiet reversal.

Sounds like they're going to repeat that mistake again.

I have been reading HN for a while and never commented, but the translation thing is very close to my heart, what with learning Physics both in Polish and English at different stages of my life.

So much so that I've made a dedicated tool for this: https://wikitranslator.github.io/

It uses Wikipedia's APIs to "click the language links" for you. It also displays short summaries of both languages' articles, so the translation can be verified. I know I'm a small sample, but I end up using it reasonably often.

You should make a Show HN out of that! Just wait a while (perhaps a couple weeks) for the hivemind caches to clear.

See the tips at https://news.ycombinator.com/item?id=22336638, especially the one about adding a comment explaining how you came to work on this and what's different about it.

If you do submit it, email us at hn@ycombinator.com and we might be able to help further. And welcome to the state change of HN-commenting!

Thank you very much for the tips!

> 1. Finding canonical translations for technical terms.

I use this so often, that I've thought to turn this into a full-blown tool on several occassions. A simple "translate" webapp that opens wikipedia (API) in the background, looks for the inserted term and then returns the translated articles (with links to the article!) for that term.

My wife (native Polish speaker) and I (native English speaker) both use Wikipedia's left-hand list of articles in other languages to get quick translations of the title/subject of a given article.

I came here to say the language part. Sometimes no dictionary will translate the thing that you want, you have to use Wikipedia to translate it. It's also great for language study, hopping back and forth between your target language to see how similar ideas are expressed differently.

Which is why I almost always use the mobile variant of Wikipedia. It is so much better, even on Desktop.

I find it really frustrating, because the sections all start collapsed, so "Find in page" doesn't work.

I agree on both. I actually prefer using their mobile site on desktop.

> I almost never use the left hand side bar (and I have a feel almost no one does)

Pretty much every non-native english speaker uses it all the time.

I us it to check pronunciation of English, French and other surnames. I know Russian letters and make use of their tradition of rewriting surnames phonetically.

> I almost never use the left hand side bar

I use it most often to change the language...

When English is not your only language, then you basically have 2x the amount of articles thanks to the sidebar.

What is the most irritating is that they dont make some sort of really persistent cookies to remove the irritating mobile view.

I use the left side bars to switch languages all the time

> when paragraphs are that wide they become harder to read

I hope I don't sound like a jerk saying this, but resizing the browser window is the key. I dunno why some people maximize everything on their computer - that's a really inefficient use of space.

I wish more websites wouldn't try to force formatting on me and just let me resize my window.

Well, I use tabs and not every website looks best at the same size. So I don't think the approach works. (FWIW, I'm also a non-full-screen user).

But you're probably on to something. I would be cool if the web browser would allow you to adjust the body size of the document without adjusting the window size.

Opening the dev tools works

Reader View is available in Firefox.

That's...in literally every browser's setting since the beginning of browsers.

It'd be neat if it worked like the ruler at the top of an MS word window (or textedit/wordpad), where you can drag in the margins!

I don't maximize anything, but site that expects me to raise browser is obnoxious. It is not the only tab and idon't want to resize especially separately for each

> I wish more websites wouldn't try to force formatting on me and just let me resize my window.

I agree. Fossil mostly requires the use of CSS, but my own stuff I tend to not use CSS if I can avoid it, and often just write plain text files anyways (rather than HTML), which works well even if you are viewing them outside of the web browser, as well as with the web browser, too.

Also, tables on mobile.

Sounds like you want the responsive design version of Wikipedia.

https://en.m.wikipedia.org

I use the sidebar a _lot_ for switching between languages.

There's a left-hand sidebar? I've gotten completely blind to its existence...I once knew there was stuff below the logo.

Remember that Mediawiki (MW) is not just Wikipedia (WP and co.) I run several MW instances and the sitewide sidebar is fully customisable which is handy. Many users are used to the LHS holding "tools". You could also/instead put a hierarchy tree of say categories in it.

I'm not absolutely sure but I think you might even be able to create your own user version of the sidebar if you create a suitably named user page. I'm not sure what WP sites allow you to do but MW has a lot of user customisation options built in.

I use the sidebar a lot to find the same article in another language. But that’s the only use I have for it.

> I have a feel almost no one does

I use it all the time for switching the same article in different languages.

>and that when paragraphs are that wide they become harder to read

Yes, reading Wikipedia on a 27” iMac is comical. Anything larger than 1000px wide is entering eye gymnastics territory. Ideally it should be around 600/700

You are allowed to change the width of the browser window.

Sure, but you shouldn’t need to.

I always use the left-hand side bar. Switching between different languages (and being able to see which languages each article is written in) is important for multilinguals. And the “random” button is great.

A blockchain-hosted fork of Wikipedia named Everipedia.org has most of these features already built coincidentally. While I prefer Wikipedia over them, I have been noticing myself use other skins/newer look wikis instead of the dated Wiki UI. Although, the load speed of Wikipedia.org is difficult to beat.

I use the translations all the tine.

> then making two changes that are backed by a fair amount of data

I don't like how you go from a subjective assumption that no-one uses the sidebar to this, almost sounding disappointed that they haven't already done it. Or are you referring to some other data? I for one use the sidebar all the time.

> The fullscreen expandable thing for images is pretty good

Strongly disagree: Links shared by people with JS enabled now silently show the page instead of the image that was intended to be shared if the recipient has JS disabled.

i use the sidebar all the time to look at different language articles.

some are quite understandable, and some i can google translate.

for a multilingual person, that bar is indispensable..

The biggest thing I've seen that's changed in the past 10 years is the creation and refinement of the VisualEditor extension. It's a great tool for self-hosted mediawiki when you have a bunch of relatively non technical users, who are not comfortable with editing wiki 'code'.

https://www.mediawiki.org/wiki/Extension:VisualEditor

VisualEditor is what you get by default now when you go to edit a wikipedia page, unless you specifically click on the option to edit source.

Please, since someone from wikipedia is probably reading this: Keep the JavaScript to a minimum. The plans aren't clear to me, but given what sites like reddit/etc have done during their "updates" the new UI's are terrible on anything that isn't a top of the line device with a screaming fast internet connection. Wikipedia (and a few other "older" sites) is such a pleasure to use as is, don't ruin it.

AKA round-tripping 1000 times sucks on high latency connections, and my little atom based tablets/a53 based phones/etc choke on those sites and its absolutely miserable trying to use them.

So, put some effort into measuring the before/after and making sure that the download/render times remain in the same ballpark on older devices/connections.

The experience with js-heavy sites even on a very capable desktop is still negative. Too much js introduces bugs, latency, and lack of stability. A page like that will sometimes jump around and resize for no apparent reason.

Making wikipedia noticeably js-heavy would definitely ruin the experience.

The size and amount of JS doesn't really matter. Whether it's well written and integrated matters. How many round-trips it introduces matters.

The stuff that gives JS a bad reputation is sites that slap together nested widgets that each load their resources sequentially.

If you serve a 1 MB blob of all_the_things.min.js on the first page load, then gzip reduces that to ~300 KB, which will take ~2.5 seconds to load on a 1 Mbps connection, and then it will likely be cached.

If you serve a widget that loads another widget that adds a third widget, on the other hand, elements will keep popping in and your user experience will suck.

On a US-normal laptop 1MB of JS might not matter too much. But for a world-normal laptop + smartphone, the size of the bundle does matter, not just for bandwidth but for performance as well. Larger JS scripts takes longer time to parse so if you have a lower power device, it still gonna suck.

Everything around your program matters, but for different audiences. Wikipedias reach is huge, and getting it to work and work well, for the lowest common denominators (think ~10-40 USD smartphones) is a pretty big job which includes thinking about sizes of all kinds.

Edit: Ignore me, seems you're not actually replying to anything specific in the comment before you, so this all seems off-topic now.

This is a valid argument, and you do need to benchmark on underpowered hardware. My gut feeling that a 1 MB blob of JS is not a huge problem even for a cheap smartphone nowadays, and if it is, the HTML/CSS can become the bigger problem.

I remember doing really silly-sounding things (like shipping a web app + the entire database) with excellent results. Even if the initial load takes a while, you can't beat the instant responsiveness of already having the data when the user clicks on another piece of content. Hundreds of KB of JSON on a 2013 smartphone (probably Nexus 4 or 5) was still a pretty good experience IIRC, at least on par with a modern web site on a modern smartphone. On a PC, I've mercilessly thrown hundreds of MB of binary data at JavaScript.

In my experience, aside from long network request chains, the biggest performance killer is e.g. having nested Angular elements that all refresh every time you touch anything on the page, not code size. If you know what you're doing and care (e.g. diligently mark immutable stuff as such), you get excellent performance. It's just that most don't care.

In addition to underpowered hardware there's underpowered connections (e.g. bad satellite connections and rural cellular) where things like being able to turn off images in a browser can come in handy.

While wikipedia might not be the typical site there, there is something to be said that a site that deals in information (like a generator's manufacturers page) should at least have a low-bandwidth option so you can access the textual information you need without pulling in a presentation layer that isn't critical.

True, but for apps which are meant to be interactive you also need to take into account SPAs that might make very small requests for a good while once the main bundle has been downloaded.

So, for a world-normal device which one is better? A site that downloads 1MB of Javascript and then makes data requests of a few KBs or a site that makes a 300KB request with a page reload every time you interact with it?

My general rule is that if the application is interactive, meant to be used for long periods of time and SEO is not an issue, well-written SPAs result in better UX.

That's not the case of Reddit for example. Most users spend the most time reading comments, and that requires very little interactivity. So old Reddit is miles ahead of the new slow and bloated one.

I agree fully with you! My point was not that the bundle size matters the most, but rather than everything matters. What matters most depends on your user-base of course. Expensive, professional tools that only works on Mac: fine with high requirements and bandwidth requirements. Free service whos goal is to spread knowledge everywhere in the world: need to think about cheapest devices on the worst networks.

1MB of JS is bad, and you should feel bad for delivering it. A content focused website should fully render without caching in under one second on a normal desktop. That is not possible with a meg of JS.

PSA: old.reddit.com is so much better in these regards. I use it on my phone too, with some custom css to make things bigger.

There is also i.reddit.com.

I only use old.reddit.com on phone and pc as it is much faster and much more intuitive , reddit has gone to hell in my opinion

I'm already resigned to the fact that once old.reddit.com goes away I'm not going to be spending any more time on Reddit. Maybe that'll be a good thing.

"reddit is fun" on Android is a great app for it. Staying away from reddit more is good for you, too.

"infinity" is also a great alternative for android.

Infinity looks great.

Relay was my favorite while I was on Android. On iOS now, Narwhal is my go-to.

old.reddit exclusively on the web, via 'Old Reddit Redirect' extension on Firefox.

I continue to be surprised that this still works, and wonder how long that'll last. It's pretty clear by this point that they're willing to try every dark UI pattern that they can think of to boost some silly engagement metrics. Community and long-term growth be damned.

I'm writing a custom skin (CSS) to turn New Reddit into Old Reddit for when they inevitably, sadly, turn off old.reddit.com

Is all of the data even available? Posts don't show the author name on the front page and many comments are hidden under links on the new UX from the comment page.

the base reddit api is pretty good - just tack a .json onto any url for an example

Have any work in progress examples?

i.reddit.com still works great to browse text-based posts on my Kindle e-reader, of all devices.

New reddit feels like they hired 6 junior React developers and put a gun to their head telling them to rewrite the website in React in 6 months or else.

It's unbelievably slow.

Funny yet accurate! I wonder what's causing them from sunsetting old.reddit...usage? An individual?

I will never use new.reddit, I tried to once but it's such a poorer UX

Making UXs for desktop that share design elements with touchscreens will always be a mess.

It's my biggest fear for the future of macOS development given the recent announcement of Big Sur and ARM.

I don’t think they are in a sense, as far as I know they have no plans of removing it.

That being said, using it once and then saying never again is kind of, not good. I’ve been on Reddit for almost a decade and while using the new design for the first time or even the first week was, painful I’ve fully embraced it now and can’t stand the old one.

I don’t find it painfully slow at all. In fact I find it faster overall when taking New features into account.

And the only way I can use Facebook - mbasic.facebook.com

And for the love of god, don't add anything that will require a cookie pop up.

It's not even an issue with adding JS, they could build it entirely in React and not have it crawl along like new Reddit does. The issue is 'redesigns' which real purpose is to add extra layers of user engagement, ads and tracking.

Indeed.

Most of the times, these dynamic things on web pages and elsewhere mispredict what I actually want.

No Google, I did not want to zoom in on the map that you automatically did for me. Rather I unzoomed back and you automatically zoomed back in.

No scroll bars, I don't want you to disappear or even thin down automatically.

I personally don't like infinite scrolling as a solution either as it messes up scroll bar operation.

And I want strictly none of the above if when clicking 'back', you don't take me to the exact same view I was on before, without the elements of page jumping for a few seconds.

No my laptop and phone, I do not want you to wake up when I disconnect power, and especially so when I had just put you to sleep!

Glad that Wikipedia is planning to show and hide the side panel on user instruction/click. Please keep it that way.

For sure; wikipedia is one of those sites that don't need any JS for their base functionality, and it will benefit greatly from it. They need to keep accessibility in the forefront for this redesign, and honestly, accessibility is easy if you just stick to the basics.

They can embellish things with JS, but that has to be optional. Things like the article summary popup when you hover over a link. That can be deferred and left out completely.

They have the opportunity to do great things with design and typography for clarity, I hope they take it.

The detail page for the first feature they mention, limiting line-width [1], makes me think: Wow, it sure takes a lot of analysis and discussion to make what is a pretty straightforward and simple change. (Recall, too, this has been in the works for at least a year? And still isn't deployed to English wikipedia?)

Which makes me realize there's sort of an ironic situation. When a site is beginning and small, you don't worry too much about the precise details of how you've doing things, you figure it's more important to get it out there, and it can always be changed later.

Then, someday, if you're lucky, the site is huge, with lots of traffic, lots of dependencies, lots of people paying attention to it... and you are much more reluctant to make changes, taking them very seriously with lots of consideration... so now are stuck with whatever people decided years ago without much consideration at all!

[1]: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...

seems like the usual workaround to this paradox is to start a new "alternative" ui and allow the original site to stagnate. wikipedia did this with their mobile site - on a desktop-sized browser, it's a vastly superior reading experience to the regular wikipedia, and was implemented with virtually no controversy or fuss because anybody who was going to get angry about changes just continued to use the main desktop site.

This is the core of "enterprise" things.

Many times clients, (especially paying business clients) care more that "things that worked yesterday should continue to work today" than about the enhancements, or even "breaking fixes", that you want to deliver for your product.

Thanks for the link — that subject has been my #1 complaint with Wikipedia for a long time.

I'm glad they're finally doing something about it, even though it seems like I still won't be happy with it — judging by the wikis where the update is active, it's still too wide.

The rationale in the article is interesting, but IMO wrong — the idea that you need to balance scannability and line length suggests that line length is the main factor in improving scannability, when it seems obvious that what wikis have been missing for a while is better, probably sticky tables of contents for quick navigation (which something like Wikiwand figured out a while back).

Making users scroll 25% less is a poor solution to improve scannability, and degrades readability tremendously.

There are issues tied to the variability of layouts on Wikipedia that are more legitimate (how to deal with boxes, etc.) and would involve deeper design changes, but they would probably be worth it considering how important the basic reading experience is to wikipedia.

I just got link from the OP, but yeah!

This is what I don't get. Why not just make your browser window narrower? Wikipedia is one of increasingly smaller set of sites which have the decency of NOT WASTING MY FRIGGING SCREEN SPACE by putting text into a narrowest of columns in the middle of my screen and leaving the sides empty.

I get that line scannability is an issue for some people, but that's why _you_ can adjust the way _you_ read the article on _your_ device, without affecting _anyone else_. Web browsers, and desktop environments in general had this magic window-resizing ability for decades.

At least there are cool browser extensions like CustomCSS, which allow me to fix sites I visit often. I guess I will be adding Wikipedia there soon... :/

Because I don't want to spend all day resizing my browser when I switch tabs?

I want websites that are made to be read to optimize for legibility and comfort, not for "not wasting screen space."

As I type this comment on HN, the right hand side of the text box where I type my comment is entirely empty.

Should the text box be full-width so it fills the screen and doesn't "waste space"? Hell no. It would be a pain in the ass to read my comment as I type it.

I don't know about you, but I'm very seldom (never?) reading more than one column of text at a time. Therefore, as I'm reading, anything else on my screen is "wasted".

Doesn't matter if it's white space or anything else.

It seems like we can't avoid "wasting space."

To see the absurdity of that metric, why don't you just make your window as small as possible all the time so you're never wasting any space? Why don't you reduce the font size to 1 pt so you don't waste space with fonts that are comically large?

I must admit that logic kind of escapes me, since it misses the most basic purpose behind reading on websites.

Now, I'm not unfamiliar with the regular HN comments about how everything is "dumbed down" and it's all about "information density" and cramming everything in one screen should be the be all and end all of design.

Unfortunately that opinion also seems to emanate from people who can't substantiate their preference with anything else than appeals to "power user" aesthetics, with very few actual use cases justifying it.

These are mostly ego-based arguments I tend to dismiss when discussing design decisions.

What does a screenful of text allow you to do that you can't do with a better proportioned column of text?

Unless you're the Flash, in my experience, absolutely nothing.

As far as saying the experience of reading properly should be left to the user/reader, I simply disagree. I'd rather benefit from the skills of designers and typographers presenting the content for me in the best manner than relying on hacks like resizing my window to get a decent experience.

I don't expect to go to a restaurant and be thrown ingredients for me to customize them _my_ way, I want my food cooked deliciously. And I want my content formatted properly and elegantly.

P.S. Note that your argument is entirely symmetric: if you don't want to "waste space" on a fixed width website... why don't you resize your window?

This is not at all about "dumbing down" or "information density", this is about choice and ability to consume content at one's own terms.

If a website leaves the text width to the reader (or their user agent), everybody wins, because everybody can read the text at their preferred width.

If, on the other side, a website tries to prescribe how wide the text should be, that choice is gone, and some readers inevitably lose.

So, no, my argument is not entirely symmetric - one approach gives everybody the same choice, the other one removes it.

To answer your "why don't you resize your window?", in the approach you seem to prefer, I do not have that option, because the website took that away from me, and no amount of resizing my window will change the text width the website dictates.

But as I mentioned, I already do go out of my way to configure my user agent to work for me, by means of a browser extension. Unless you want to take that choice away from me as well...?

(I will purposefully ignore your attempts at psychoanalyzing people over the internet based on a few bytes worth of text they wrote.)

Everybody can always read at their preferred width provided they do what's necessary to get there. Resize window. Modify CSS.

You can always do that.

My point is that the smart default is to minimize having to make any change. The question is what the smart default is.

Defaulting to full width text means that most of the time, on a large desktop monitor, I need to resize my window to adapt to the text (different font, font size, layout, etc.), so it doesn't meet that standard.

Using a maximum width solves the issue, unless you want, for some reason, to display text wider than is commonly considered comfortable (you can always resize your window to shrink it further if you need to).

Can you show me an example where you'd like to resize text beyond 10-ish words on screen?

I'm very curious about concrete use cases and what the result looks like (and why it's superior), other than the case indicated in the original article (i.e. logging, not long-form text).

I'm not interested in "taking choices away" from anyone. I'm interested in not wasting my time building custom CSS to avoid having bad reading experiences on websites I spend a lot of time on.

Maybe it comes down to what you think Wikipedia is as a product. I don't see it as an API that spits out unformatted content. I see it as an encyclopedia, and as such, expect it to provide the best reading experience for me out of the box, like I would expect from a printed encyclopedia.

So far, Wikipedia is at best mediocre when it comes to basic typesetting. I just wish it were better.

I’ve seen the “stop limiting my column width” argument presented on HN on many occasions and each time it seems to be an argument of optimization: let the user decide how to better process the information. That works well for people who argue that most things can and should be handled via a terminal window, but the average user doesn’t think that way. An average user expects curation.

Right. I think there's a case to be made for a distinction between letting the user decide, and making the user decide. Customisation should be possible, but not necessary, especially for the most common use cases.

I guess we'll just have to agree to disagree. You prefer narrower lines, I like my lines as wide as my browser window allows. For me, it's more comfortable reading text with long lines and having to scroll less, than having shorter lines and having to scroll often.

> it seems like I still won't be happy with it — judging by the wikis where the update is active, it's still too wide

I'm not sure what they looked like before, but I also visited a few of the localized wikis and ended up getting a horizontal scrollbar. I know that the theme on English Wikipedia is very old and not exactly responsive, but this is not something that happens there; I get no horizontal scrollbar. Everything is sized to fit within my window, except on certain articles containing wide tables or (unfortunately) multi-column reference sections, and even then, it's limited to those elements, which overflow, and the main article contents end up sized correctly. So I have to think that whatever changes they're introducing might actually be causing new problems...

That might be in part because survivorship bias substitutes (in a good way!) for consideration.

For example, if a hundred new bakeries open each year, each one baking bread according to a recipe that the baker just kind of randomly put together without much thought, and ten years on, one of those bakeries is now drawing customers far and wide and five-star reviews, it makes sense to carefully consider any changes to the recipe even though it was only randomly thrown together in the first place. It might just be a winning formula that is the secret underlying their success.

Of course it might be their customer service, their casual atmosphere, or their good location that has driven that success, not the bread recipe. But it's hard to know for sure. So changes need to be done very carefully if at all!

Not only does wikipedia need to concern itself with highly established user flows ("sure it's not perfect but at this point I'm used to it" * millions of users), but I think a project like Wikipedia is A Genuinely Important Thing and therefore can't afford to fuck around with UI "experiments" like Reddit does and like Digg catastrophically tried. Trying to both provide a free online encyclopedia of Pretty Much Everything We Know and make it available to as many humans as possible, while also doing UI experiments on those users, seems too ambitious. Let reddit and facebook and google turn their users into lab rats. In ten years Wikipedia can take one or two actually useful bits of information generated from those experiments and implement them, as they're doing here.

Compared to how radically, how often, and how pointlessly most popular websites get redesigned, this is so... subtle.

When I saw the title I assumed there's going to be a full redesign, with all the bad modern web design trends like giant everything and plentiful useless whitespace. I was pleasantly surprised to find out it's not the case and they're actually keeping their dense desktop layout and making some rather minor changes to it.

That's the kind of miracle you get when you aren't optimizing your product for KPIs and stock value.

Agreed. Thinking about it, it actually seems like a major achievement that even after so long, Wikipedia's design doesn't feel clunky or unintuitive. I still think of this as the "new" design, and I'm still happy with it.

These changes are driven by actual issues actual end users were having, as opposed to the usual "we want this feature [no one asked for] to be used more so we gave it more exposure [at the expense of the UX]". That's what software development should be like. You serve your users. Not the other way around.

> as opposed to the usual "we want this feature [no one asked for] to be used more so we gave it more exposure [at the expense of the UX]"

This is just how business works, you like to steer users to features that will make them spend more. Wikipedia has been able to side-step this because it's a non-profit.

Yes and I never liked businesses, especially IT ones. Also why I can't find a job for 1.5 years now — can't fathom making someone already rich even richer as opposed to making the world better.

Just imagine how amazing the world would be if the creators of most of the things we use every day weren't obsessed with making more money than what they know what to do with but instead with improving the design of said things to serve the people's needs better.

> Also why I can't find a job for 1.5 years now — can't fathom making someone already rich even richer as opposed to making the world better.

Have you considered working for your government or a non-profit?

> your government

I'd rather work for Facebook than get involved with this dictatorship universally hated by at least my entire generation.

> a non-profit

Thought of it. Don't know of any, sadly, and there aren't many anyway. Someone told me about Mozilla when I left my last job, but that was before covid, they didn't do remote and I don't want to relocate, and now it's in quite a turmoil.

Maybe I'm wrong but it feels like Wikipedia's layout has very subtly evolved over the last 20 years. It probably feels the same as it did 10 years ago but there are certain UI elements and layout options that I see today that I'm not sure existed 10 years ago. I don't even remember if that table of contents was a thing 10-15 years ago.

MediaWiki has a skin system, and judging from other comments here this appears to be treated as a new skin, or an iteration of the already default "Vector" skin.

There are several skins that have tried to tackle some of these problems in the past, notably Foreground: https://foreground.wikiproject.net/wiki/Main_Page

Refreshed: https://www.mediawiki.org/wiki/Skin:Refreshed

and Timeless, which was a quasi-Wikimedia project: https://www.mediawiki.org/wiki/Skin:Timeless, https://www.mediawiki.org/wiki/Winter

which all tried to be responsive rather than using the MobileFrontend extension and splitting the site into two separate device-specific skins.

You can append `?useskin=skinname` on Wikipedia, or any MediaWiki site, to switch the current view to the given skin. For instance, Timeless is installed on wikipedia.org, so you can see what it looks like by going to https://en.wikipedia.org/wiki/Ruth_Bader_Ginsburg?useskin=ti...

The list of installed skins is on the wiki's Special:Version page.

I wish this were more widely known, and not just for Wikipedia. There are too many local MediaWiki installations that stick with the dated default Vector theme. NB: it's not the theme's datedness that makes it bad; it's that the design decisions are poor ones that reflect trendy anti-patterns of that era, and in the meantime, the insistence on them has more or less quietly and thankfully disappeared. I'm referring to the attitude that publishing on the Web calls for a sui generis "look" involving sidebars, dubious color and font size choices, and bold emphasis on app-like UI elements and other cruft like navigation controls, rather than foremost emphasizing the content itself and letting the user agent handle things like preferred font size. The Vector skin, like popular Wordpress themes of that time, strongly reflects that style, and it's bad. The Web would be much better off if future MediaWiki installations by default shipped with a skin resembling Wikiwand (modulo the fixes that should be made to it as well—e.g. stop fucking overriding the browser's native font size with your tiny-ass text! HN is just as guilty on this; any site that makes the main body text <1em (or >1em, for that matter) is by definition doing it wrong).

If you have a user, you can set the skin permanently on

https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

I use Monobook, which is more compact than the default (Vector). It used to be the default.

Having a user also enables you to toggle "Gadgets" which can provide productivity boosts, especially for editors.

There are also `?useskinversion=1` and `?useskinversion=2` which are useful to force the use of the legacy version of skins.

Not sure if what you’re linking is the same, but Wikipedia and other Wiki sites also allow you to apply your own css in your user settings. These override any themes you set.

If you add only these two, it already improves the experience with 99%:

To limit the width of paragraphs:

#mw-content-text { max-width: 50em; }

To set a serif font for text and headings:

p, page-heading.h1, mw-parser-output.h1, mw-parser-output.h2, mw-parser-output.h3, mw-parser-output.h4, mw-parser-output.h5, mw-parser-output.h6, .mw-headline { font-family: Georgia, "Times New Roman", sans-serif; }

This is different — user CSS requires a login and can override a skin, but is separate from skins, which are installed on the back end similar to an extension. Similarly, skins can have their own custom CSS in a similar namespace.

Also, you can use the `useskin` URL parameter to preview one of those backend-installed skins without logging in first, while user CSS requires a login.

I use the Timeless theme myself (https://en.wikipedia.org/wiki/Pangolin?useskin=timeless). If you like the Timeless theme’s less-busy navigation but don’t like that theme’s sticky header and misaligned icons, you can copy my CSS customizations for it: https://en.wikipedia.org/wiki/User:Rory_O%27Kane/timeless.cs...

To try those customizations yourself, copy the CSS code on that page. Then, in your Wikipedia account’s Preferences > Appearance (https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...), choose Timeless as your skin. Finally, click Custom CSS next to Timeless, paste my CSS, and click Save. If you don’t like those customizations, just edit the page again and delete the CSS.

I made one final tweak to the Timeless theme: on page load, a bit of JavaScript scrolls the page down to hide the search bar and user menu. Most of the time I don’t care about that part of the page when I visit an article, and when I do want to see it care, I just have to remember to scroll up.

I installed that JavaScript using a custom user script installed with https://violentmonkey.github.io/, though you could probably get it working with the Custom JavaScript link in your Preferences > Appearance settings too. Here’s a simplified version of my JS that you are free to copy:

  // ==UserScript==
  // @name Wikipedia – scroll below Timeless-skin static header on load
  // @description When using Wikipedia’s Timeless skin, modified with user CSS to not have a fixed header, this scrolls below that header when a page loads. This hides the distracting color bar and lets you see more of the article. If you want to see the header, just scroll back up.
  // @namespace roryokane.com
  // @match https://en.wikipedia.org/wiki/*
  // @grant none
  // @author Rory O’Kane
  // ==/UserScript==
  
  const headerHeight = 60;
  
  const usingTimelessSkin = () => document.body.classList.contains("skin-timeless");
  
  if (window.location.hash === "" && usingTimelessSkin()) {
    window.scrollTo(0, headerHeight);
  }

> the wide range of functionality on the site can feel overwhelming and difficult to understand

I guess it must just be my lengthy history with the web, but this line is like nails on a blackboard to me. It's OK to have to learn how to use powerful tools!

I feel the same way. I wish interface designers would focus on ways to get people comfortable with experimentation instead of removing features entirely.

In this case, no feature is being removed--just hidden in a collapsible sidebar, but I agree with your overall point.

Having to learn how to use powerful tools is absolutely fine when the tool is a specific one designed to be used by power users. For something like Wikipedia for whom the bulk of the audience visits briefly and occasionally to grab information, it's not a good thing. I think a lot of us are scarred by changes like these to our "power tools," which can be incredibly frustrating, but Wikipedia is a different beast.

Your design should fit your audience, and I think it's a good change to have a sidebar with tools that are surely ignored by the _overwhelming_ majority of users not be presented in a persistent, important location.

Also worth mentioning that they aren't removing anything, just altering presentation to better suit the common use case.

That seems obvious but it's not necessarily true. It seems to be an increasingly popular philosophy in this data-driven era of telemetry though, so I'd like to offer a counterpoint.

I want Wikipedia to be as convenient as possible for the editors/authors, even if most users are readers. The authors -- even as a small minority of users -- create the content that, in turn, attracts the readers.

It's possible that alienating authors to prioritize the reader experience ends up driving away readers through the second-order effect of driving away authors.

(I'm not saying that these particular Wikimedia changes are an example of this, just illustrating a mechanism by which prioritizing the experience of the majority of users can end up harming them in the long run, because second order effects are important too. Wikimedia seems to have thought carefully here, which is good).

An extreme example of this philosophy would be noticing that the vast majority of your users never touch the edit button, and so getting rid of it entirely to streamline the interface for everyone else.

then make a special UI that editors/authors can enable in their preferences...

'Editors' and 'readers' is not a binary dichotomy. One of the great things about Wikipedia is that anyone who happens to be reading an article and notices an error can correct it without much friction.

This is mostly only important insomuch as it helps recruit new editors. As a fraction of effort, those drive-by non-logged-in edits are a trivial contribution.

I think ideally there might be powerful features of the tool that take some time learning, and that's okay.

But the tool itself should have simple features that can be used by a newcomer too. The tool itself should not be "overwhelming and difficult to understand" -- I mean "overwhelming" is never a plus, is it? The power-user features should be designed in such a way they don't scare off or interfere with more basic use. Rather, the basic use should be low-barrier, and serve as a step to investing to learn the more challenging use.

"simple things should be simple, complex things should be possible." (Alan Kay). Not "everything should be hard and complex because we are resigned that that's the only way to make complex things possible."

I think this is true as a general rule, but it may also depend on the "product" (whether commercial or noncommercial like wikipedia). There may be some products where it's okay if you scare off newcomers, where you know you have a core that will be willing to invest the time to figure out a challenging or even "overwhelming" tool because of it's value to them, and that's all you need/want. But I don't think that's appropriate for wikipedia, I think it is the absolutely correct choice and in line with wikipedia's mission to prioritize making basic wikipedia use as low-barrier as possible for as many users as possible.

So I think Wikipedia's bar for use is pretty low. To bring it much lower (i.e. to Twitter or Facebook levels) might reduce quality because people will be more willing to make changes while requiring even less time investment.

Wikipedia has wildly succeeded and mostly avoided the fate of other social media sites. We must tread very carefully to keep Wikipedia for future generations.

So these particular changes are more about the UI for viewing/consuming content than editing/creating.

And I'm suspicious of the theory that a harder to use UI for editing results in higher quality content. I understand your theory that some people who would edit content maliciously or without proper care would be put off by a harder to use UI, but it's not obvious to me that it's true, or that it wouldn't be countered by putting off even more people who would have good intentions and take proper care, some of whom correct malicious content. When making decisions for a site that millions use, you probably don't want to make significant strategic decisions, like to intentionally not make the UI as easy to use as you can, based on hunches.

But anyway, wikipedians have actually had the opposite concern of yours for a while, rather than increasing to "too many" contributors, wikipedia seems to be losing contributors, and many see it as a problem. Both because you need enough contributors to maintain content, and because the self-image of wikipedia is that "anyone can edit", they actually want to make it accessible, not put barriers in the way.

https://en.wikipedia.org/wiki/Wikipedia:Why_is_Wikipedia_los...

More info about who contributes to wikipedia is on the following page, which suggests about 132K users in the last 30 days. I don't know what the number is for how many users viewed wikipedia in the last 30 days but I'd guess far under 1% of wikipedia users make edits.

https://en.wikipedia.org/wiki/Wikipedia:Who_writes_Wikipedia...

Much of the discussion in your first link seems very old. There is a link buried in there to this discussion in 2015, when it was suggested that the trend may be reversing (based on the questionable decision to focus on “active” editors making more than 100 edits a month). It would be surprising if the growth in internet use over the past decade had not increased the number of Wikipedia editors at all. https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2...

I’m suspicious too, but I agree with the grandparent that we should tread very carefully. Wikipedia’s success probably has at least something to do with the fact that its development has been extremely slow and isolated from commercial web development trends.

i agree wth you. i was just providing a potential reason why making it easiercould be hazardous (just like makin it harder could be). Wikipedia is such a special thing and we don't totally understand why it has worked.

Wikipedia already contains a huge amount of "powerful" tools in the sidebar, that most casual users would never want to interact with. Upload file, recent changes, what links here, etc - pretty much all of these are irrelevant for people who aren't editors.

Except the whole point of Wikipedia is that everyone is potential an editor...

I think the appropriate direction depends on your audience. Being powerful is often a trade off with accessibility.

Tools meant to be used by laypeople need to make a good first impression.

A mainframe-style UX where you have to type magic letters to trigger functions is great once you've gotten used to it, but the average user will not put in this effort and simply use something else instead (compare e.g. vim vs. nano). You can afford that sort of UX when you have users who don't have much of a choice and/or will spend a lot of time using that specific tool (which is why vim is still a thing). That's the case for e.g. airline booking systems for agents, not the case for airline booking websites for average users, and not the case for Wikipedia either.

The best UX for this is a UX that is simple, yet still provides the advanced features, and ideally makes them discoverable. A classic example would be menus: You can either slowly click through the menu with the mouse, you see all the options, and you see the underlined letters that will allow you to navigate the menu much faster if this specific menu is worth learning.

Additional visual clutter can be overwhelming, even to experienced users, especially if it's not well separated from the important stuff (it can simply make the important things harder to find - compare e.g. the toolbars of Google Slides and OpenOffice Impress). But good design can easily counteract this. For example, you could use a grey background on the unimportant stuff to let people focus on the important stuff.

Which is why Wikipedia is doing. It's not as if the presence of that toolbar is going to distract someone from the only other task that can be done on the page, reading the article that takes up the entire rest of the screen...

Direct link to one of the early adopter wikis: https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_princip...

Cool, instead of having Wikipedia zoomed in to 150% I have to have this one zoomed at 170%.

Why? They both use the same font size and line height.

There could be other factors involved, but it takes longer for fr.wikipedia.org to load on my computer than en.wikipedia.org. I hope Wikipedia will remain usable on old and slow devices.

And the sidebar works with no JS. Perfect!

From that link, it seems like the change in the text column width behavior, which is promoted as limiting text columns to a maximum width, in practice creates a min-width as well which can be quite wide. That is, in the old wikipedia, you can adjust the browser window to make the text column arbitrarily narrow, but in the new wikipedia — depending on other elements on the screen — in practice can you from having an uncomfortably wide column of text that you can't adjust to be any narrower.

So it seems like kind of a mixed bag readability-wise.

edit: For example, this article's main text area seems to have a width of around 155 characters, while typography rules of thumb dictate not exceeding 75 or so:

https://fr.wikipedia.org/wiki/Reichsgau_Wartheland

Quite a pleasant change

While there might be a lot of current users who feel like “if it’s not broke why fit it?”, there are a lot of whys it can be improved (some previous commenters have already linked some great research to how line length improves readability). As someone who is very dyslexic, I can say that Wikipedia is incredibly difficult to read, navigate and use effectively as a resource. It is not organized in a way that is easy to parse, the content blocks are huge making it extremely difficult to read, and there is very little white space. I’m excited to see how they revamp the UI/UX to make it more user friendly.

I am sorry to hear this. A child of mine is severely dyslexic, and I think about these things all the time on their behalf.

You can already select a more dyslexic-friendly font for Wikipedia articles. In the side-bar, click the gear icon in the "Languages" sub-header. Select "Display" settings in the resulting box, then the "Fonts" tab and check the "Download fonts as needed" option. This will reveal a further option to switch the font for main content in your current language. Select OpenDyslexic in the drop-down box, then Apply Settings. As you can see, it's really easy and usable even for newcomer folks!

Thank you so much for sharing that, I’ll check it out! :)

I think given the historical overlap between Wikimedia and Fandom (formerly Wikia) execs and the overlap between Wikimedia and Fandom editors, there's not a lot of trust for anyone announcing a wiki redesign

The web/CSS is supposed to empower the user to make modifications to fit their own needs.

I have a Javascript bookmarklet to restyle a page if necessary. If I always needed it, I would set a user style sheet, or different default fonts.

The most underrated thing about websites that have kept a working design/ui/ux/whatever for a few years or more is that people are used to them. I know where the search bar is, I know where to switch language and where to exactly point my attention to find what I’m looking for. Even if something is not exactly right, or doesn’t make sense to some expert UI designer, you really don’t have to change it. I’m seriously weary of multi year redesign projects undertaken by websites used regularly by a lot of people. It almost never works. PayPal didn’t get it right, Spotify constantly messes with their app and changes where things are, everyone can probably add something to this list.

Shouldn’t UX be a lot more about how the thing looks? Work on enhancing your copy if people find it difficult to understand.

That’s something I’m a huge fan in G Suite. The UI changes very slightly, most of the time you don’t even notice, but the number of new features that the team ship is incredible.

Not sure about G Suite, but Gmail UX/UI seems to get worse with every other update -- it's cluttered with unrelated stuff, like Google's chat attempt of the month, and unbearably slow. Searching for text with diacritics is broken, even though it used to work a couple years back. Kind of absurd for a search company.

I'm pretty confident I don't want this. I'd like to be proven wrong, but there was maybe a couple of cases among hundreds when perfectly working UI was actually improved instead of fucking broken by "getting a new look".

What I actually would like to be improved is how the data is represented internally. Let's face it, it has been a long time since Wikipedia has become the largest and most accessible knowledge base in the world. It was made simple, which is a part of why it is successful. MediaWiki is pretty much a blogging engine, article content and structure is restricted by the guidelines only, not by the engine. This is good, and at the early stages it was the only possible solution, since there is so much that can be useful in an encyclopedia article.

However, now we know a lot of patterns of how data represented in different articles is similar. But wikitext is still basically just a human language with a bit of markup elements. Sure, there are templates, which are slowly improving over the time, but still, it's petty much a collection of free-form blogposts. There is almost no way to separate data from the representation (i.e. to have a table contents as a csv, with a template assigned). There were some attempts to make it possible, but querying (or modifying) data automatically is still very much a pain. A lot of it requires parsing, and (perhaps even more annoyingly) — pretty simple parsing. But you have to do that work for every single problem you have. Instead of, you know, to just query data I know there is. In fact, when you start parsing templates it becomes very clear very quickly, that they are vastly underused. Absolutely the same data, like years of life in bio-articles is still represented differently even in very elaborate and well-maintained articles.

Very little has been done in this regard over the last 10 years, I feel. And improvement does require a lot of work: looking for possible templates, promoting generic data representation among contributors, modifying wikitext to allow for it, improving the API. It they are looking how to spend money, I'd rather want it to be this, because making a lot of data machine-accessible would be literally as huge, as making wikipedia human-accessible was about 20-15 years ago. Sometimes I need to open 500 articles to read a single sentence in each of them, and some python script could've done it for me in a second (a couple of seconds maybe, depending on how wikipedia stores and represents the data).

Friend, they are using data and research to improve their UI. Thinking that "other products didnt do it well so you shouldn't try" is extremely unproductive.

It's also not productive to argue for a vastly more difficult and different area, like their data model, during a topic of refreshing UI..

Data representation is UI.

> they are using data and research to improve their UI

That's what every UI/UX ''expert'' says and 99% of them are full of shit.

I think the current efforts in this regard are focused on https://wikidata.org and to a lesser extent the new (planning stages only so far) abstract wikipedia project https://meta.wikimedia.org/wiki/Abstract_Wikipedia .

Those are both the opposite of an incremental approach but i'd be curious what you think of them.

I don't want to say anything negative about them, because both are fine initiative on their own. But I'm not hugely optimistic about them (yet). Both can succeed, but both are pretty far from what I'd consider succeeding.

First of, I want to highlight what you already said: this approach is the opposite of an incremental. Both approaches are fine and have their own value, but they are truly different, and not somehow philosophically "opposite, but the same".

This is not a perfect example by any means, but just to be less abstract, let's pretend you want to dig a really big hole.

1. "Disruptive innovation" approach is spending a lot of resources on research without any real output for a long time, in hope that in the end it will produce an excavator, which will surpass the work of 1000 mortal men. These projects are costly and provide no guarantee, they are usually successfully done by small research groups in facilities like "Google X". Any such project is always a huge bet, it either works out or not. And even "almost working out" e.g. producing engineering schemes that will be improved upon in a 100 years to actually produce an excavator, mostly counts as "not working out" for any individual project and organization.

2. More conventional approach would be to motivate 1000 men to dig a hole using shovels and buckets, maybe developing a better shovels and buckets in the process, if possible. The trickiest part here is actually motivating 1000 men: using money, violence, "gamification" or whatever.

Wikimedia foundation is not known so much for "disruptive innovation", as it it for crowdsourcing. And even if it was: every moonshot is unlike any previous one. In fact, it motivates hundreds of thousand of people to contribute without directly paying them money, which is a huge feat.

Now, let's get to Wikidata. Web 3.0 ideas with OWL and knowledge graphs are older than actual Wikipedia. And maybe if I'll say they weren't successful, somebody will retort by mentioning some projects where OWL and RDF are actually useful... I mean, sure. But are they as successful as Wikipedia? Are they as successful as Web 1.0? This is rhetorical, of course.

"Why" can be arguable, but I feel like it's actually pretty clear why: people do not willingly contribute to something they don't understand, and maintaining a data graph still requires a lot of manual contribution and editing. This kind of contribution has to be made an effortless by-product of what they actually want: putting something on the internet they (and other people) can access in a human-understandable format. They don't care about stuff being machine-readable. You may know that they actually want it, because the possibilities it will open are enormous, but most of contributors don't know it. It's easy to see why I should edit an article on the subject I care about, that contains wrong info or is incomplete. It's not as obvious why I should edit some abstract "item" somewhere out there, and care about some "data graph" I've never seen... That is, until I need to access it using SPARQL myself.

I'm more optimistic about Abstract Wikipedia for that reason as well: there are plenty of biligual Wikipedia users, and many of them know that sometimes reading the same article in 2 different languages reveals that there exist almost parallel universes, with communities speaking different languages having their own "truth". Sometimes it's actually useful, because you get to see that there is actually "no truth", but it's also apparent why something like "Abstract Wikipedia" may be useful. But that is too early in the concept phase to seriously speak about it, anyway.

So, once more: these will either succeed or will they fail. That remains to be seen.

What I was talking about is much more approachable, I think. This is not an "all or nothing" undertaking. There are plenty of very real improvements that can be made to the data model of each and every article, and they will remain regardless of whether they help to create "Wikipedia:Web 3.0" or not (and I actually think they have very real prospect in helping with that, because it will literally get people editing the data graph without even knowing about it). They are useful on their own.

And unlike my "friend" exacube in the neighbour thread I actually think this kinda is about UI. Because unlike with abstract data graph, people care about approachable, clear and uniform interfaces. A random example, to clarify what I mean. You can look up some "List of birds of CountryX" kind of articles in different languages and different countries. Semantically, all of these are the same thing, there can be a single "best UI" for that, that any given encyclopedic organization can decide on. Wikipedia doesn't have one: sometimes it's a table, sometimes it's a list. Sometimes there are picture of a bird thumbnail, because that's useful. Sometimes (for a table of the same length for the same country in a different language) there is not, because it's obviously a lot of work to make such a table, and person who did it just didn't bother. Yet these photos exist in the `BirdName` articles, so you could prefetch them automatically, if there was a common structure to all of it. Same for many other data. And there are countless examples of this kind.

Thanks. That is an interesting perspective and i agree with a lot of it.

I would point out in the bird example though - the normal way of having a "data model" in wikipedia is through templates (yes it is very definitely mixing view/model/controller in a questionable way). These templates do have the ability to fetch data from wikidata (with some restrictions) and wikidata does store an image for most animal entries.

So its entirely possible to have a template on wikipedia, that just takes a list of species names, and turns that into a pretty table listing the species, a picture, and perhaps other fields as required.

> MediaWiki is pretty much a blogging engine, article content and structure is restricted by the guidelines only, not by the engine. This is good, and at the early stages it was the only possible solution, since there is so much that can be useful in an encyclopedia article.

I wonder whether there is a fundamental trade-off here. The track record of expert systems and structured knowledge bases is not great. Capturing data in these systems is relatively hard and expensive and therefore none of them have become as detailed as Wikipedia (cf. Wikidata). We also know that the task of giving structure to our own implicit knowledge by writing it down, even in a way that is not machine-accessible, is difficult and time-consuming. It may not be possible to create machine-accessible knowledge bases without “front-loading” the work of giving structure to that knowledge. Knowledge bases that require this to be done may never be as detailed and comprehensive as a less structured resource like Wikipedia, just as Wikipedia will never be as detailed and comprehensive as the (even less machine-readable) sum of all human knowledge distributed over the set of surviving brains and texts.

I believe that this is absolutely the case. In fact, this is kind of the point. No way we would have Wikipedia if it did demand much structure from the very beginning. I don't see it possible (and, in fact, I don't want it to happen) to enforce structure in articles that cover some abstract concept, idea or new phenomena.

But for better or worse, Wikipedia is now also a huge database of biological species, anime characters and car models. It has several million of biographies, which cannot (nor probably should) be simplified for machine comprehension, but (not universally, of course, but highlighting that is a part of the point as well) have very concrete data entires, like DOB/DOD, "simplified characteristic" (actor, mathematician, politician, imperor of Rome), height/weight for many athletes and so on. And (even though this isn't the point), amazingly, all these countless articles already follow roughly the same structure. Like, for each biography you can expect to find the circumstances of death near the end of "Life" section, but before "Legacy", and you'll find "Interesting facts" in the very end. It may seem very natural (and it is!), but the reason I'm mentioning this, is that encyclopedia also is the tool that helps the authors to structurize data. I'm sure that 2nd and 3rd dinosaur articles were very different from each other in structure. But when you are writing a 1001th, it will be pretty similar to 1000th. Even if for you personally it's the first one to write.

And it is the point that it's hard for people to consciously produce structured, machine readable data. But we want to have structured, machine readable data. That's why I think gradually modifying Wikipedia itself in a way to unobtrusively trick us to provide this data, is the way as opposed to wikidata.

There is an example to get the feel of what I mean in the last paragraph of my response to bawolff, if you are curious.

These are the first of many changes in a long and complex process.

They're raising too much money and hiring too many unnecessary people.

I was just rereading WP:CANCER again after the latest donation banner took a full screen scroll and asked me for an email when I pressed what I assumed was the dismiss nag button: https://en.m.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has...

rereading ... again is redundant.

Well, if you want to be pedantic

Rereading = reading for the nth time, n > 1

Rereading again = reading for the nth time, n > 2 (as you've already reread at least once)

Wikiwand[1] is something I've been using for a while that makes Wikipedia a bit nicer to look at. The concerns others have voiced about the long line length are addressed by this plugin. It also has a great table of contents on the left. Other things, I think wikipedia.org does better. Excited to see the changes!

[1] https://www.wikiwand.com/

Thank you. I've never seen wikiwand before but it is a big improvement. It is missing those pop over windows that wikipedia has when you hover over a link though.

The popovers work for me in the latest Chromium (if we're talking about the same thing)! I love those.

I do think Wikiwand goes a bit too far in the "slick" direction; Wikipedia is more functional. But it's nice to play with an alternative.

They also work in Firefox when you allow JS from wikipedia. I had blocked 3rd party JS.

I don't get it.

On desktop, collapsing the left bar does nothing. It doesn't provide space, it doesn't enhance the viewability of the main content. It is purely aesthetic. In that sense, it doesn't harm me, but I wonder what kind of person needs it.

The second thing I notice is that it removes borders, further eliminating visual cues on header/sidebar/main content. It's a blob of white with paragraphs. It feels less structured.

Finally, I think limiting line width feels wrong on things like the main page, or on wikis that have wide tables for reference. It would be good to see more examples of how it affects tabular data.

They say in the user research survey that it's for accommodating people new to english/learners.

I'm surprised wikipedia has gone this long without joining every other website in fixing their unbroken UI

I still remember the vector rollout...

I was scared for a moment that it's going to be another "we added bunch of whitespace, js and hid a bunch of options away for a cleaner look" redesign.

Was pleasantly surprised with the article. I think current Wikipedia is highly functional design that is content thick and practical. Like HN.

Just in case someone here is not aware of Wikiwand:

https://www.wikiwand.com/

I use it for 2 years now and it works just right.

Details on this: This is a restyled version of wikipedia content that looks a lot better. They have a browser extension that redirects you to the wikiwand version of the same page, which is the same content with much nicer formatting. It really looks quite a bit better.

Caveats: you have to trust a non-wikipedia site to keep their copy up to date, not to info-mine you, and if you quickly send someone a link, they may not realize they're still sort of on wikipedia.

For comparison:

- https://www.wikiwand.com/en/Hacker_News

- https://en.wikipedia.org/wiki/Hacker_News

On the second link, it fits all onto my screen. On the first link, I have to scroll. Why is this better? Sure it looks "nice" but if I want to look at nice things there are other websites. I want wikipedia to be useful, not look nice.

I disagree, this is worse in every way. Too much white space. Literally every website today needs to reduce the padding and margins by 80% and they could present the same data in dense, single page without scrolling.

Also large fonts need to die. I love HN because I can see so much in one shot, can always increase fonts with Ctrl +

You can't really exceed a a certain number of characters per line without sacrificing readability and you can't restrict the line length without padding the container, so I'm not really sure what you think the goal of typography should be. It's certainly not to reduce scrolling; there is no "fold" on the web.

I like Wall Street Journal and their typography, https://wsj.com and how they write their articles. Not sure if it directly applies to Wikipedia, but I agree with your general point about typography - 80-120 character width seems ideal, any longer and it is tiring.

Perhaps we should go with columnar layout. I don't think it helps by adding a bunch of whitespace... ultimately, you're reducing the amount of information shown on a single page which could just be columnized.

Yes, because reading walls of text is such a great experience.

You "can always" remove all the styling and get what you want.

> Also large fonts need to die

It's possible that you're browsing on some configuration that makes Wikiwand display "large fonts" (mobile device? even then I haven't been able to reproduce), but Wikiwand isn't using large fonts. In fact, articles' font-size is set to 100% of the UA's preferred font-size, and then they use use a third-party font ("Lora") which actually makes text smaller than your typical serif font rendered at the same size.

> I love HN because I can see so much in one shot, can always increase fonts with Ctrl +

By the same token, you can always use Ctrl+- then for sites that use a "large font"[1], right?

Note that HN is actually screwing things up and using a "small" font. From news.css: "font-size: 9pt"(!). IMO, pulling shenanigans like that is actually pretty disrespectful to visitors. It's why I have to permanently browse HN at 133% zoom + force the rules for mobile devices to kick in. It's only at that point where text is displayed at my UA's correct size.

1. (Wikiwand excluded, for the reasons above)

1. UA config doesn't even enter into this. No one the new design is supposed to help doesn't know how to configure their UA or even what it is.

2. Consider these 3 images: https://postimg.cc/gallery/X78M9ms

2 of them have normal sized text and 1 has a text that looks good on the designer's macbook. As it happens, the latter is borderline unusable -- an article not longer than a handful of tweets doesn't even fit on one page.

P.S. Until today, I genuinely thought that wikiwand was some kind of ad farm, from seeing it pop up in google search.

> 2 of them have normal sized text and 1 has [...]

No, one of them (Wikiwand) has "normal sized text", and the other two have objectively shrunken text. This is not a matter of opinion; this is fact. Both HN and Wikipedia, like I mentioned before, are overriding the text size in their stylesheets to force the main body text to display at a size smaller than the UA preferred size. Wikiwand is using the correct font scaling. If you have a problem with the size of the text on the Wikiwand page, it's because your UA is configured to show text at a size that you have a problem with. It's up to you to deal with that.

For an example of what properly-sized text looks like, have a look at http://cr.yp.to or http://danluu.com. These sites are not sending any "designer" styles to your browser (aside from the 8 lines of CSS for the latter, which don't affect the text size).

Besides that, your criticism of Wikiwand's design is dominated by details about its layout and not its text size. But I didn't say Wikiwand was the best layout in the world; it's not, and I don't even use it. But it's still not worse than Wikipedia's overly-designed Vector skin.

You are right, the font-size is not the main problem with Wikiwand. I tried zooming in until the text was the same size on the Vector skin and it's usable. Nevertheless, I don't think it's a coincidence that sites like old.reddit, HN and Wikipedia all use a similar font-size. Less so on Wikipedia, since the Vector redesign increased the size a bit.

I don't get what's wrong with the Vector skin though... The only thing I would change is the language options in the sidebar -- no reason for the collapsible search box thingy. Just list all the languages as tuples of (native name, name in current language). Other than that I think it's great, no doubt thanks to all the effort spent polishing it over the years.

The problem Wikiwand is trying to solve is better solved by browser zoom on large screens and a separate skin (or media queries I guess) on mobile. Setting UA font-size to make text readable (as opposed to customizing the relative sizing of different elements) has been obsolete pretty much since Opera introduced zoom. If a non-power user wants a site larger they'll just zoom in. If they want everything larger they'll apply the zoom to all pages (at least Chrome has this). Pretty much no one cares about UA's font-size. Certainly no lay person.

Edit: Seeing danluu's site linked reminded me of this relevant thread: https://nitter.net/danluu/status/1115707741102727168

> Pretty much no one cares about UA's font-size.

'cept for you, right? (Or why are we here otherwise? Reminder: someone started complaining about how large the text looks on Wikiwand site.)

> The problem Wikiwand is trying to solve is better solved by browser zoom on large screens

What problem do you think it's trying to solve, and how does zooming solve it?

> If a non-power user wants a site larger they'll just zoom in.

By the same token, you can always use Ctrl+- then for sites that use a "large font", right?

> What problem do you think it's trying to solve, and how does zooming solve it?

According to sibling subthreads here, a lack of readablity. Since I don't think line length matters much, making text larger is pretty much the only thing left. Zooming is the easiest way to achieve that. It also doesn't alter the layout of the site as much as simply increasing the font-size.

> By the same token, you can always use Ctrl+- then for sites that use a "large font", right?

Of course. Being a power user, I can even set the font-size ))

I'm just pointing out that expecting people to do the latter makes no sense unless they are a power user.

> making text larger is pretty much the only thing left

Wikiwand doesn't "make the text bigger". It leaves the text size alone. I've already mentioned this more than once. cf cr.yp.to, danluu.com.

> I'm just pointing out that expecting people to [set the font-size] makes no sense unless they are a power user.

I don't know what you think I'm saying. I'm not talking about power users. I'm saying that Wikipedia shouldn't be injecting rules for small font sizes in the main content. Everyone can leave the font size alone. Wikipedia cramming thousands of lines of CSS down the tubes, where the incorrect font size is among them, is like people who say "backslash" when dictating a URL—they're going out of their way and getting it wrong.

I always found that reading a wall of English texts are painful when the font is small, and there are no enough spacing between them.

Wikiwand has been great for me, but the table formatting is atrocious. Really like that the side bar is a table of contents.

Using Wikipedias language switcher to translate things seems to be quite common here, so I thought I'd share how I moved the languages up on top, so I don't have to scroll down on smaller screens or when zoomed in.

In `<firefox-profile>/chrome/userContent.css` I wrote the following:

    @-moz-document domain(wikipedia.org) {
        #mw-panel {
            display: flex;
            flex-direction: column;
        }
        #mw-panel nav {
            order: 9;
        }
        #mw-panel nav#p-logo {
            order: 1;
        }
        #mw-panel nav#p-lang {
            order: 2;
        }
    }

This is only for Firefox, but imho that is the… least bad browser anyways ;)

Actually, if you have a Wikipedia account, you can save custom CSS (and even JS?!) to your account:

https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

Yes — custom gadgets and user scripts are quite common! It fits in with the ethos of the place, but is quite remarkable compared to nearly any other popular website.

I really like how they have opted to make small changes gradually. Look at the feature lists here https://m.mediawiki.org/wiki/Reading/Web/Desktop_Improvement.... There's a detailed explanation for why each change is being made complimented by a GIF showing the side by side difference. I've been working on an SPA with a tight deadline and we are building new pages almost every other day. It's nice to see a project take a slow and careful approach.

Honeslty I was never a fan of sticky headers and this one [1] is no exception. Is it really worth cluttering the reading space when you can reach search in your browser's bar or just pressing the home button to scroll up instead?

Generally pop-ups are bad design for power users. If there's free space why not have it expanded? Instead add distraction-free-mode when clicking certain keyboard button or shortcut the article is expanded and all of the clutter hidden.

My general wikipedia workflows heavily rely on search, with proposed pop-up redesigns for languages and ToC now I have to do numerous clicks rather than just searching for "Français" and clicking enter if I want the french article.

Finally the article mentioned that there should be width limit and it was always sore thumb of mine - how can something that has 200 characters per line be read efficiently? There should be configurable limit with a more sane default.

1 - https://www.mediawiki.org/wiki/File:Search_prototype_for_the...

Try the Wikipedia mobile site https://en.m.wikipedia.org/wiki/ which basically solves most of your issues including the sidebar and wide paragraphs.

TIL, thanks! Though I'm fine with the current design, the proposed one is what bothers me.

So does anyone have a userscript to override the maximum line width?

I have claustrophobia, and having text forced into narrow columns actively triggers it. Taking a look at the Basque Wikipedia, I can tell right here that it's completely unusable for me. I'm willing to pay real money for someone to write me a script to override it.

You can open the article in Reader View in Firefox and then set the margins to whatever you want.

I'm not interested in using Firefox, and having to actively switch modes every time I open an article isn't acceptable.

I want something that globally eliminates all max-width everywhere.

Oh yes, thank you for saying that. We seem to be the only ones here that don't like this. I have a 2K screen, please let me see more content, not less on it.

If you have a Wikipedia account, you can go to Preferences > Appearance[0], and choose a different skin. AFAICT "Monobook" and "modern" have unlimited content width.

If you don't then you can append ?useskin=modern to each article URL. (You can do it automatically with a redirect extension.)

Alternatively you can inject the following CSS (e.g. with Stylus):

    .mw-content-container {
        max-width: none !important;
    }

(The specific CSS selector might change with time.)

[0] https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

Apparently you can add the CSS to your account based on, https://news.ycombinator.com/item?id=24571570

I don't think I have real claustrophobia (at least I don't have the slightest issue with sleeping in coffin-sized berths), but I do get a really unpleasant claustrophobic feeling when content is squished into a small area.

All books ever made have text that has roughly the same text width for a reason. It's a well established pattern, and full width websites ignore the most fundamental design principle. Do books make you feel claustrophobic too?

Your sass is unwelcome. Books are a different, more constrained format.

If I had a book with 12" wide pages and only 6" centered were used for content, it would be uncomfortable.

How about a normal book placed on a big empty tabletop? That's a more fitting analogy since you provide your own browser but not your own pages for a book.

I like the mobile version of Wikipedia, I find it more legible even on the desktop.

Comparison:

New design: https://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_princ...

Mobile version: https://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_princ...

You've got the mobile version twice there, I think you probably wanted to remove the "m." from one of them.

Respect to the designers of the current look, which has done admirable service for so long to such a vast audience.

I feel it has become iconic - a plain and functional and consistent look that makes it stand out from the garish, noisy rest-of-the-web, and is instantly recognizable even to the general public, featuring in mainstream movies and music videos.

If such a thing existed, it could be declared a UNESCO World Heritage website.

> much of the wide range of functionality on the site can feel overwhelming and difficult to understand ... we need to provide not only excellent content and an experience that is engaging and easy to use, but also an experience that is on-par with their perceptions of a modern, trustworthy, and welcoming site

MediaWiki's difficulty of use is the primary reason Wikipedia has fared as well as it has during the decline of substantitve online discourse in recent years.

Wikipedia is far from perfect, but it is the best and last of the old web. Putting people who don't understand this in charge of its redesign is a recipe for disaster.

I just want them to remove the "collapsible sections hiding most of the content" misfeature from the mobile interface. Every time I view a Wikipedia page on my phone, I scroll down and click Desktop, because it's easier than playing whack-a-mole with a bunch of section titles.

I hope it doesn't change too much, Wikipedia and Craigslist are the only two major websites that have a decent layout these days.

I respect your opinion but I do not think it reflects the majority of users in this initial group.

I think it is good Wikipedia was willing to test for the truth and be open to acknowledging it is not at its maximum potential for achieving its mission by sticking with the existing design.

I comment here because I also thought if Craigslist but for an opposing reason. I see Craigslist as neglectful in its refusal to perform public research on what it should change.

Not only in terms of design but also features such as validated identity.

There is a reason Craigslist usage has dwindled to other marketplaces, those with far less capitalistic and privacy-minded philosophies.

There is a price to pay for refusing to change. Craigslist is a slow moving, very public example of this.

If you have an account (and stay logged in) you can get some of the benefits described in the article with an alternative skin (collapsed menu, limited line width, maybe a better font). Check out the options in the Appearance section of your user preferences.

I like MinervaNeue (sample page here: https://en.wikipedia.org/wiki/History_of_Anglo-Saxon_England...)

If you don't like being logged in, it's worth noting that's also the default interface for en.m.wikipedia.org (the mobile site, which is perfectly usable on the desktop)

Wait, that's the Wikipedia Mobile layout, except with a lot more desktop functionality (and changes such as Talk Pages not being collapsed). They had this lying around the whole time?

I wish they'd move the page's table of contents into the left sidebar and the current left sidebar into a drop-down menu at the top. I never use the left sidebar (when looking at a page on a topic, why do I need immediate access to `Random Article` or `Current events`?!), but I do want one click access to the sections of the page I'm viewing. Having it in a drop-down menu is better than scrolling to the top, but still two clicks with an re-orientation step

There appears to be a some mockup already online: https://di-collapsible-sidebar-5.firebaseapp.com/Tea if you want to preview some aspects of it.

Wikimedia recently decided to abandon their in-house javascript framework in favor of Vue.js[0]. That doesn't mean wikipedia will turn into a vue.js single page app but they'll use it to progressively enhance some parts of the frontend or their internal tools/editors etc. Looking at some of the suggested features like the new search[1] it seems that vue.js could be used in this scenario. Does that mean they'll ship the entire vue.js runtime alongside jquery that is already used?

[0] https://phabricator.wikimedia.org/T241180 [1] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...

I mean, the Vue.js runtime is smaller (about 73% smaller) than jQuery.

Ok, the concrete changes they mention sound harmless, but..."modern looking website" sounds like code for "webapp-looking thing with every pixel clickable and stuff that moves around on you when you don't want it to". There is a lot more room for screwing things up than improving, for Wikipedia. I am nervous.

I wish instead of UI tweaks they would do something about toxic admins and power editors spreading misinformation with the assistance of kafkaesque bureaucracy and censorship.

That would bring something called accountability to the table. We're not ready for it yet. Enjoy the new UX!

They could just make the mobile wiki the desktop default too. It is minimal, readable, and clean.

I hope not. I find the mobile wikipedia page awful. I always switch to the desktop site on my phone.

Sections that start out collapsed is terrible for searching. Section headings that themselves are enormous is terrible for browsing. Even the text size is enormous by default - you don't get much of an overview.

The text size is totally normal on my phone. Good readable size that's similar to other text-focused pages. It might just be that their CSS needs to be a little more clever about screen sizes.

> Sections that start out collapsed is terrible for searching

It doesn't collapse on desktop: https://en.m.wikipedia.org/wiki/Siena_Cathedral

It's minimal and clean because everything is hidden. This is not a good thing, as it's impossible to search or skim.

Only on mobile, not on desktop.

Try reading a math page on an iPhone with a spotty connection. All the images now only load when tapped. So after the page loads, I've got to scroll down, open each collapsed paragraph, and tap each image separately, before I lose signal on the subway.

Unfortunately certain iPhones do not have MutationObserver support. This is not the case on newer ones.

There's an open bug to allow you to opt out of this however we've been a bit stretched to find the time to work on this.

https://phabricator.wikimedia.org/T261609

I would love a preference setting for this. Thank you!

I don't know why they did that, now we have empty space on the left and right, it's really useless, why is it better than using the full screen?

"Our second change introduces a maximum line width to our content on pages where reading is the focus, such as article pages and discussion pages. Research has shown that limiting the width can lead to better retention of the content itself, as well as a decrease in eye strain. "

This is bs.

So all documentation website should now have that max line widht to better retent the content?

Edit: maybe it's just me but any UI/UX you have used for the last 10years are really hard to change in a positive way.

No it isn’t. There’s ample research showing that shorter lines are more readable.

Check out the sources on this page for more details: https://en.m.wikipedia.org/wiki/Line_length

I agree, their line width has been atrocious since the early days. It was as bad in 2005 as it is now. The font size on their primary topic page text on desktop is also too small.

Checking a well filled out topic page, something like George Washington, a typical line might be 160-190 or more characters across in the top section. In some places on the page it can reach to 210+ characters across. It isn't a very good reading experience at their present font size and at that width.

In the early days the lines would have wrapped earlier on a 4:3 monitor. Using a vertical tab bar fills in the extra space and improves the readability of most web pages on widescreen.

According to Dan Luu, none of the citations on that page actually support what it claims.

Amusingly, given the context, I haven't actually read any of those citations. However, he's pretty careful, so I take the claim seriously, though I'll ultimately withhold judgment. As far as I'm aware, no one has come back to point to a citation and show that it supports the result.

https://twitter.com/danluu/status/1115707741102727168

So make the window narrower or get a narrower screen if you don't want to see empty space. Readability is more important.

Readability is exactly why sites need to enforce a maximum chars/line. Don't ask your users to constantly resize their window just to read your content.

I got a big screen specifically so that I can have multiple windows on my screen. Having a site decide to be in charge of sizing instead of allowing me to choose is user-hostile.

You're always in charge of your browser width and zoom. With the use of relative ems, a designer can accomplish a sane line length for any combination of settings.

You seem to be agreeing with the parent and Wikipedia and the research on the subject.

Why not leave it to the user? If they want narrower text, they can make their window narrower. If they want wider text, they can make their window wider. This design forces "narrow" as the one true way, leaving out users who prefer to use the whole monitor they paid for.

> why is it better than using the full screen?

Are you saying you only have one window open at a time?

Many people including me use the browser maximised all the time.

On a laptop typically I'd only have one window 'open?' maximised at a time. It allows focus. I'm a big fan of Gnome3 for this.

If coding then an additional monitor can help, the additional monitor multi-window to support the main focus.

If writing, then one screen and paper and pencil to sketch thoughts.

If diagramming/flowcharting, switch desk or stand up and use a whiteboard, reduce over multiple pieces of A3, then the finished result should be refined enough to iron edges out to formalise in Dia or Visio. I also prefer pencils over pens, have a box of multiple colour pens, crayons too, bunch of sticky notes not for the screen but supporting paper-based thoughts, masking tape for putting things together. And this is me working by myself.

We all have our use cases and it's rarely one size fits all.

For wikipedia - why not default to whatever's deemed best for most, but have a small toggle button for 'old'.

Modern operating systems only give you one mouse cursor and one focus at a time. What are you doing in the other windows when you are trying to read wikipedia?

I'm all for clean and uncluttered UIs, but trying to read wikipedia pages on a 4k monitor (or even large laptop monitor) is a joke. The lines are WAY too wide for easy reading. My brain just stops halfway through the line

I mean, maybe I'm just ancient with broken eyes (31), but I can't imagine anyone being able to sit down and read a wikipedia article like an actual book with reasonable left-right width.

The research on line length is not new and it's certainly not BS. I'm sure that even you read better at 70 chars/line than 200.

Dan Luu has repeatedly failed to find any good sources for this claim: https://twitter.com/danluu/status/1115707741102727168.

Ok, but does anyone really want to read at hundreds of chars per line? Just look at the comments here. It's pretty clear that there is a widespread preference for fewer. This makes sense, since typesetters figured all of this out long before CSS existed.

You just moved the goalposts!

You cited research, then when pressed on it, gave up on actually citing any, and just appealed to people's preferences. If this is really about preferences, that's what you should've said, rather than making a fake claim to have scientific backing.

> So all documentation website should now have that max line widht to better retent the content?

Absolutely.

You haven't used a ultra widescreen monitor then. Reading Wikipedia (until today) on such screen was pretty hard, with sometimes a full paragraph on a single, long line. This change is much better.

As for the sidebar (which you don't talk about, I realize) it's very useful for non-English speakers: it's easy to switch from the local page to the English one, and I've used it quite a lot. For switching to other languages as well, when the local article is more knowledgeable than the English one

Why would you maximize window width on an ultra widescreen? That isn't much of a value proposition for (Western) text consumption.

That is easy to solve - just don't fullscreen your browser window. Set it to a reasonable width and the content will follow.

I have a large, wide monitor, and want to use the whole thing. More and more, sites waste this width with whitespace. Yuck! Now, I have to scroll down to keep reading what should (and can) fit in the full window. Thanks, UX researchers! If I wanted to read a narrow sliver of text, I'd make my window narrow or browse on my phone.

FWIW, Wikipedia allows you to add custom CSS and JS that are active as soon as you log in.

Who logs in to Wikipedia? I asked search engine about a term, it brings up a link to Wikipedia, I visit page, read content, then leave. I never even knew you could have an account, and assumed only people wanting to editors would even need an account.

There was a time when contributions were welcomed by all with trust in the community to weed anything without backup out. Those days are long behind us.

Yes, all documentation websites should have a max line width. It baffles me when I see people argue against max width in any way. If you disagree with constricting max text width you should _never_ design an interface that humans use.

The conclusions of the user testing show that people have a much easier time finding them in the new location.

A collapsible side bar and max width are hardly big features you need a whole post for.

Phew. I was fearing a "reddit redesign" for Wikipedia.

I disagree. Until I read the post I wasn't aware that Wikipedia are about to embark on changing their desktop UI. As someone who uses Wikipedia as much for reading pleasure as for looking up stuff, and who has just been through the discomfort of having to deal with Facebook's - unannounced! - desktop redesign, I appreciate being told in advance that things are gonna change, especially when the post comes with a link an (animated!) outline roadmap of the changes they'll be introducing over the next couple of years.

There are several other features they're planning on adding, linked in the article: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...

The mobile UX is quite alright, really close to wikiwand.com .

I hope it goes in that direction.

I can share my userstyle on demand, looks similar and like this: https://i.imgur.com/jUhG107.png

Sticky menu, hidden sidebar on the left (mouse over reveals it and language switch moved to top). I just pulled it from stylish.org because of their malicious add-on.

130 Comments, No one mention the suggestion of Dark Mode?

And if I could have a non-topic collapsed version of Mobile Site for use on Desktop would be great.

> 130 Comments, No one mention the suggestion of Dark Mode?

Came here looking for this as well.

I would like this, but I think it's more important that Wikipedia continue to be lightweight enough that it'll load on almost any device, including those without JS.

Not that those are incompatible, just thought it worth pointing out.

https://www.wikiwand.com/en/Albert_Einstein allows to set a dark mode in the settings.

This doesn't fit the definition of a redesign. The term redesign, as used in the context of websites, is defined as the reduction in usability, uglification, waste of manpower, opposite of improvement in any meaningful sense. I don't know what this is, but it's not a redesign. We might have to invent a new word for it.

"We welcome anyone curious about our changes to try them out and give us feedback"

OK, how? I can't find any link.

Edit: Found some https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...?

At least put a link to them somewhere obvious.

Main thing is, seems fine without Jscript. Good. That's the main thing.

Print preview is not working right on palemoon. Probably a PM bug. OK, tried printing the entire text of https://fr.wiktionary.org/wiki/Wiktionnaire:Page_d%E2%80%99a... but only got the first page.

Link from the article showing what features they are adding.

https://mediawiki.org/wiki/Reading/Web/Desktop_Improvements#...

If you're curious what Wikipedia has looked like throughout its 20 year history:

https://www.versionmuseum.com/history-of/wikipedia-website

Wikipedia is a textbook case for ideas which led to creation of HTML. If Wikipedia wouldn't be able to be expressed - mainly - in HTML, that would mean HTML is a theoretical idea, not applicable in reality.

In addition to (near) absence of JavaScript, the HTML should be readable by itself - all those nesting levels, lists... Accessibility would benefit, and also using Wikipedia as a structured database - which should definitely be possible.

More in line with original Web ideas, interactive content - surely carefully tagged - should have standard solutions for embedded sound, video, 3D scenes, vector, raster and photorealistic graphics, various expressivities of embedded languages (code demonstrations).

You can add custom CSS in Preferences → Appearance. I've set mine up to look something like the mobile version for a while now. I'm always a little shocked seeing the original when logged out or on someone else's computer.

>Our first change, a collapsible sidebar, allows users to collapse the lengthy menu found on the left side of each page

Through hiding, feature discoverability is hampered.

>Our second change introduces a maximum line width

I resize my browser for the optimum line width on my computer, taking into account monitor DPI, viewing distance, visual acuity, and other individual factors. Please don't make content on computer monitor as badly cramped as it is on mobile. One size does not fit all, and there's a reason computer is higher productivity than mobile.

I wonder if it will ever look much like https://libreplanet.org. It’s the only site I’ve seen with a theme that modifies the actual layout (ie. the sidebar and Article | Talk / Read | Edit | View History tabs), AFAIK — I wouldn’t have known it was MediaWiki if I hadn’t happened to click to https://libreplanet.org/wiki/Group:LibrePlanet_Wiki_Helpers

My favorite interface change in the past 10 years is that hovering over a link to another article causes the lede to pop up - often answering my question, or increasing my interest in visiting the page.

I have tried max line length readying on wikipedia and even speed reading apps (single lines flashing the whole text before your eyes).

I honestly like the current line length which scales with your monitor the best.

I use my own CSS (with the Cologne Blue skin), and I would hope that it doesn't break. I customize the CSS in other ways too, because I often don't like what they do with modern ones. (I think would be better to design it to be used without CSS and then it might be better, but they don't do that, so I need to add my own in order to fix the mess they made.)

I do not use any side bar or top or bottom bar; only the text is displayed. I do not want a maximum line width either; I want the entire window to be filled with the text.

Regarding all of the comments about the importance of language links in the sidebar: if you look here you will see that the language links will be moved to a button/menu in the article header (https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...)

Meaning now you will have to click to even learn if the language you are interested in is available.

Great to see Wikipedia thinking about improving its design.

I've been working on a completely integrated Wikipedia/Wikidata/+more system for about a year now. Please check it out here: https://conze.pt

There are also screenshots of the development progress on Twitter: https://twitter.com/conzept__

If anybody wants to try for themselves in their language, go to "Preferences" >> "Appearance" and uncheck "Use Legacy Vector"

Oh my god they added a dick bar.

https://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Se...

The mobile site on desktop has fantastic UX. The m-wiki chrome extension smoothly redirects you to the mobile version every time.

https://chrome.google.com/webstore/detail/m-wiki/ibnmikddaop...

Just fyi, if you are logged in you can also select the mobile skin in your preference (mobile site is different from mobile skin in that it also alters page contents)

On Firefox I use Redirector, I set it to redirect from

  ^(https*:\/\/)(?!www)([a-z]+)\.wikipedia\.org\/wiki\/(.+)

  https://$2.m.wikipedia.org/wiki/$3

Works well!

The one thing I hope is fixed is that for mobile browser, when I'm clocking a link in a wiki article to another link, and then I want to hit the back button to go to the article I was originally reading, the back button doesn't scroll to where I was on the page and I have to scroll down to resume where I was reading.

That honestly looks terrible. It's like their developers haven't heard about fluid design. Why is it only using 40% of the page for actual content, even after I collapse the annoying sidebar. They'd be much better off with a navbar with dropdowns, or fewer links using a hierarchical structure.

I prefer the wikiwand layout, see e.g.

https://www.wikiwand.com/en/Albert_Einstein

Zoomed in at 150% it looks really nice. It also allows to justify the text and has a dark mode.

Just the performance could be a little bit better.

I see a blank page with js turned off, while wikipedia still works.

I just hope that it doesn't get one of those reactive designs, where, when I put two browser windows side by side on a 1920px wide display, the content gets displayed in tablet mode, instead of keeping it in desktop mode.

These reactive sites have broken half of the web for me because of this.

It's great that they are rolling out these changes. I forget not everyone uses them because I enabled the new layout a while ago. It's been available, albeit subject to changes, to everyone with an account.

Personally, I really enjoy the new look and design/UX choices.

I've enabled the new theme, and I was prepared to hate it, but I actually found it quite nice. So far, at least. It's refreshing to see a UI change that is an actual improvement and not just some management people getting their raise. Good job, team!

I wondered we they were still talking about long lines, but then I remembered I have a userstyle in Stylus:

    #mw-content-text blockquote,
    #mw-content-text ol,
    #mw-content-text p,
    #mw-content-text ul {
        max-width: 40em;
    }

Ugh, don't hard code a maximum line width. Let me decide by sizing my window if I want it.

The line length has been annoying me for years now. Recently I started to switch to the mobile version on desktops, which is much more readable in my opinion.

Maybe I should write a browser extension that automatically adds the "m." prefix to Wikipedia URLs.

While they're making UX changes, I'd love if they added a redirect from the mobile version to the desktop version when you click a mobile link on desktop. It's a minor annoyance, but one that seems to happen more and more.

Fingers crossed it won't be as awful as WTSocial. That place looks outdated by about 10 or 15 years and it was literally made last year. I actually much prefer Wikipedia's current design over that, if I had to compare the two.

French Wikipedia looks so good: https://fr.wikipedia.org/wiki/France

Anyone know if I can make this the default look whenever I use Wikipedia?

This is the upgrade they are talking about! French Wikipedia is one of the trail wikis. Go to this [1] link and search for "Use Legacy Vector". Uncheck this and you will start seeing the new look on Wikipedia.

NOTE: It looks like you might have to do this for each MediaWiki site for now, but it is not too difficult if you are intentionally trying to opt-in.

[1] : https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

I've noticed when I view Wikipedia in French it is a lot different than the English version:

https://fr.wikipedia.org/wiki/San_Diego

As an owner of an ultra-wide monitor I am all for adding margins on the left and right side. I feel like my eyeballs are about to fall out everytime I read something longer on maximized Wikipedia.

> To these users, much of the wide range of functionality on the site can feel overwhelming and difficult to understand.

What is it with going for the lowest common denominator everywhere?

If I host my own mediawiki, will the fixed line length be enabled automatically, or do I have to configure something?

I've deployed 1.34.2, but lines still seem to span the entire screen.

It should be the same, uncheck Use Legacy Vector in Special:Preferences (at least, it is for me in 1.35rc3). I haven't found a setting to make that the default, however.

You can make any preference default by adjust $wgDefaultUserOptions

Great. I always really liked mobile wikipedia more than desktop.

I use the WikiWand browser extension which improves on UI quite a bit,

https://www.wikiwand.com/

As long as this means a single site that works for both desktop and mobile instead of having separate URLs for mobile v. desktop pages, I'm all for it.

Has anyone ever created a site that is just a collection of all the scraped wikipedia articles posted in the comments on HN?

I have used Wikiwand Extension for the past couple of years and haven’t looked back. Happy to hear about max width change though!

Dark mode on Wikipedia would be so amazing!

Let's hope that Wikipedia's redesign puts some pressure on eBay and Amazon to follow suit.

I'm surprised they haven't experimented with using the LH menu bar for the article ToC.

Finally! Please take care of the paragraphs width and text size. I usually use Wikipedia at 250x

It's fine as is why change it?

The post details why it's not fine...

So, what exactly does the "Search 1: search widget move" change accomplish?

I bet it won't remember my scroll position when navigating back between articles.

I wonder if the mobile look is changing. It already has a collapsible sidebar.

I've long thought the the mobile design was better on desktop than the desktop design.

uh-oh.

EDIT: After looking at https://fr.wikipedia.org/wiki/Province_de_Posnanie it's not so bad.

Is it going to be a single-page app with React, Angular, or similar?

I sure hope not!

No. This wouldn't be technically feasible at current time even if we wanted to do that.

oh no

> Our first change, a collapsible sidebar, allows users to collapse the lengthy menu found on the left side of each page. This change helps improve usability and focus by allowing people to concentrate on the content itself, whether reading or editing.

Ah, more designers trying to justify things. Every site now has a hidden menu/hamburger nonsense, with the goal of "clean" design.

It's terrible and hurts UX and discoverability.

Eye strain? With a menu? Really?

They aren't hiding anything, they are providing the _option_ to hide. I will hide that sidebar and be grateful for it. I'm hugely appreciative of their goal of allowing for an improved reading experience, and they are doing it in a way that will have no effect whatsoever on you if you like the presence of the sidebar. There is no hit to UX or discoverability here.

It's collapsable, implying you don't have to collapse it if you don't want.

The eye strain thing was referring to the maximum line width feature. Studies have shown that longer-width lines are harder to read than shorter-width lines.

But sure, you could just imagine that they're doing these changes because they need to justify their jobs.

Reply on news.ycombinator.com