The entire community was captivated by the new Wikipedia appearance.

The rest of the items we altered in addition to the appearance of Wikipedia
The rollout of a new design for English Wikipedia was a crucial turning point for my team this past week. This was the desktop site’s biggest overhaul in more than a decade.

However, much more than simply appearances have changed, and in this blog post, I hope to shed some light on what we’ve accomplished and the individuals who made it happen1.

A painting depiction of a large group of people constructing a wooden version of the Wikipedia puzzle globe logo (
The redesign of Wikipedia’s desktop site, which began in January 2020 with the first patchset, has resulted to a number of advancements in our tooling and codebases.

Many people would probably scoff at the thought that a redesign might take three years, as opposed to three months, but a large portion of this time was spent consulting with different partners and reworking the code that had been developed over a 20-year period. We have developed using an agile methodology, implementing our designers’ expansive vision piece by piece. In reality, the first version of our Wikipedia in the Basque language was released in July 2020. We designed our codebase wisely, intentionally, and strategically, keeping the entire mammoth in mind. It’s amazing to see what has been accomplished over the past three years when I look back at our release timeline and all the things we performed to complete this project.

We improved our ability to disagree.
I’ve seen significant changes in how the Wikimedia Foundation resolves internal conflicts. As an engineer, I am incredibly appreciative that technical program managers supported us throughout our daily routines and helped us get beyond any challenges that were put in our path on this project. We identified ways to make significant improvements, whether it was by leveraging Vue.js or building trust among individuals, whether it was by putting people in a room together, asking the correct questions, or negotiating opposing strongly held viewpoints. Thank you to Jazmin, Lani, Suman, Nat, and Daniel for all of your assistance, among others.

We collaborated successfully with the editing community.
Our links to our editing communities have grown stronger.

The new style and feel has been the default for many of our other projects for a very long time, even if English Wikipedia only received it in January 2023.

We owe a great deal to the pilot communities that provided feedback as we iteratedly developed the idea. I am astonished by the high caliber and considerate comments that many volunteers were able to provide us, as well as by the extent to which our team went in articulating our objectives. For instance, the limited width improvement for reading has been a contentious feature ever since we introduced it. When we realized there wasn’t any accessible explanation for why something had been so crucial to us, we created our own. My coworkers at work have planned and run a variety of office hours, some of which I’ve attended. Despite being just scheduled for thirty minutes, these meetings frequently go much beyond that time due to the lively discussion we’ve had. Thanks to all the volunteers, especially Alex, Szymon, Olga, Phuong, Martin, Letizia, and Sherry, whose suggestions allowed us to improve the new design.

We enhanced our methods for front-end development.
Because of the lack of industry-standard build tools, the lack of a frontend framework, and the lock-in to a variety of undesirable libraries like JQuery.UI, moment, and in-house libraries, working with frontend code has historically been a little underwhelming. Our codebase was primarily a backend-first piece of software.

Historically, choosing which of the various JavaScript frameworks to employ in our stack has been one of our biggest challenges. We had a difficult decision to make, but because to solid project management and a process for debate and discussion, we decided that moving forward, we should adopt Vue.js for frontend development. A design system toolkit has been developed by our designers in collaboration with teams from across the organization, and we also discovered techniques to assist the production of ES6 code without tools.

Our toolbox has expanded since our original Vue.js pilot experiment, which is used in the new search experience, and now includes views from numerous teams and projects. We appreciate the pioneering work of Eric, Anne, Volker, Roan, Nick, Jan, Stephen, Alex, Barbara, Nat, and many others.

We enhanced the backward compatibility.
Older versions of our site’s design frequently persist online for a very long time after we upgrade it, as I noted in an earlier post from 2018. This hasn’t always been free, and tiny modifications like markup adjustments and CSS removal frequently call for updates across many versions, which can need dozens of fixes.

We have relied far too heavily on markup, and when the HTML structure or an ID changed, important integrations—like menu items without styles—were broken. We used templates to build a shared data and display layer, which allowed us to make the significant changes we had planned while lessening the workload on engineers. My team’s code maintenance decreased by 20% as a result of this.

To combat this, we strengthened contracts and created APIs where code is integrated. For instance, we now have reliable techniques for consistently adding items to menus with icons and changing the page subtitle.

Throughout the project, we frequently broke features, and I appreciate the engineers’ tolerance and understanding as we worked to avoid this from happening again. We appreciate your assistance and patience, Leon, Ed, Roan, Ammarpad, Clare, Bernard, Mo, and Bartosz.

We enhanced language assistance.
The article title is accompanied with language support in the new edition, which is far more prominent than it has historically been. Working closely with our language team and taking time away from their own projects were required to make this feature more noticeable, which attracted a lot of community comments. We appreciate Santhosh, Pau, and the language team’s close collaboration with us.

We eliminated code routes and streamlined the APIs.
When we tried to make what seemed like simple modifications, such adding things to menus, we encountered an excessive amount of intricacy. There were more than 5 different APIs for writing code to add an item to a menu in the case of menus. For the sake of our own sanity, we greatly simplified that. We appreciate Ammarpad, Clare, and Mo’s work on this.

We kept a high degree of accessibility.
Since the previous desktop design had excellent accessibility, we intended to maintain it in the redesigned version. We had the good fortune to work with not one, but three engineers who were specialists in this area and held us accountable throughout the project. We also had the good fortune to get a lot of input from users and subject-matter experts. Special congratulations go go to Bernard, Jan, and Volker, who have all been outstanding, as well as the managers who have supported them. The American Foundation for the Blind provided some quite helpful input, which Bernard in particular organized.

We designed with efficiency in mind.
We are now performing better. We eliminated unnecessary CSS, only utilized it on pages that required it, and we standardized thumbnail traffic. We’ve kept an eye on significant adjustments like the move to Vue.js and a new search API. Special thanks to Volker, Nick, and Timo.

Our Wikitext markup language was reorganized.
We have to reorganize Wikitext in order to support the new table of contents experience. Instead of using metadata that might be shown elsewhere, the table of contents was formerly a component of the HTML text of the parsed article. It was difficult to make this update in particular while keeping the earlier style version in place. This should act as a model for a significant redesign of article HTML in the future. We appreciate the work of the content transformation team, especially Subbu, C. Scott, and James.

We enhanced third-party assistance.
Several websites that are not Wikipedia utilize our software, and many of these websites use plugins called skins to make them seem different from Wikipedia. Due to restrictions in the existing architecture, many of the skins for our third parties were broken, neglected, or more complicated than necessary when we started the project. These issues were comparable to those that were preventing us from achieving our objective. By auditing these, we were able to anticipate difficulties. Our third parties can now use 101 skins with much greater support, and we have improved backward compatibility systems in place. At the Skins lab, you may view these exquisite works of art and even create your own. Many thanks to Mainframe, Alistair, and all the other skin developers for their perseverance, engagement, and wisdom.

We began keeping track of visual regressions.
We started witnessing numerous graphic regressions in our releases about a year into the project, which decreased our overall velocity.

To combat this, we developed a framework for visual regression and included it in our deployment procedure. Recently, usage of this tool outside of the team has begun. Suman and Nick deserve praise for doing the bulk of the effort here.

We began logging JavaScript problems.
We didn’t have JavaScript error logging when the project first began. We do now. We appreciate the help from Jason L. and Daniel in this case.

We enhanced mobile usability.
While we didn’t quite make as much progress with this as we would have liked. The new desktop skin responds quicker than the previous one did. Most of this has been a prioritizing issue; we now have a fully functional mobile site, but we want to at least have a workable skin.

Our mobile traffic is increasing, so we’ve maintained a watchful eye on things. The technical stack for the desktop site and the mobile site have been brought closer together. Some of the greatest mobile site concepts have been incorporated into the desktop versions, and features that were previously unavailable on the mobile site are now usable on mobile. Over the coming year, new initiatives will focus on enhancing our diff pages.

Special thanks to Jason S., Jan, Bartosz, Bernard, and Jan here.

however there is still work to be done.
Notably, our task is not finished. There are a few flaws that we have to wait or lower in importance. more specifically

We would like the new desktop skin to be more responsive. This wasn’t given priority because we already have a mobile site, and working with our content writers to make article material responsive is a significant barrier here (in particular large tables).
The performance of the new skin is below potential. Due to the method we push out features, we are currently shipping more than 2 kb of CSS than we should, and overall the site’s important CSS is a little bigger than it was. In the other hand, the site’s design deteriorates on outdated browsers despite the addition of functionality that should make it more helpful.
The font size is not as large as we would like because doing so now would need a lot of work from our editors.
The website’s accessibility still has some problems. We’ve received consulting, think we’ve found those problems, and are still working to address them.
There are still a number of blog pieces being produced on our work2.
I look forward to addressing these flaws and more. Most significantly, I believe we now have a far stronger basis to build on thanks to the last three years. It won’t be another ten years before the desktop experience gets its next upgrade.