Unsolicited redesigns of popular websites are extremely common, especially as student projects or material to fill out a design portfolio.
A proof of concept, often composed by some text and a few screenshots, is only a stub, not something ready to be "switched on". An actual redesign follows a formal process accepted by those who have the power and right to adopt it, as happens for instance on many wikis with community contests to redesign the main page.
As a top ten website, Wikipedia has been the subject of many unsolicited redesigns. Since these are redesigns of a site that everyone uses, they often get picked up by blogs.
- 1 Why unsolicited redesigns are welcome
- 2 Why unsolicited redesigns can be problematic
- 3 What you can do if you want your redesign to be more seriously considered
- 4 Scope
- 5 Unsolicited redesigns of Wikipedia
- 6 In-house redesigns
- 7 References
Why unsolicited redesigns are welcome
- Radical change (or in this case, a proposal for a radical change) is strongly encouraged by one of Wikipedia's core guidelines: "If you see something that can be improved, improve it!"
- They let an individual or small group of designers flesh out a set of new ideas without constraints.
- They allow novel ideas to be thought out and visualized, even if they would be hard to implement immediately.
Even redesigns that turn out to be unsuitable may have the following positive outcomes:
- They start a conversation.
- They show a hunger for better design.
- They can provide inspiration for new things to try (or to avoid).
Why unsolicited redesigns can be problematic
Independent of the merits or drawbacks of any individual design decision, there are potential shortcomings that are often exhibited in unsolicited design proposals.
For example, specific proposals often ignore, or don't understand, important requirements:
- Wikimedia's websites are multilingual and multicultural; many design proposals are done in only one specific language, script, or kind of content and so miss important considerations.
- Wikimedia pages must meet legal requirements, like page history, attribution and licensing information.
- The purpose of an unsolicited redesign is often to showcase the talents and ideas of a design firm or designer, more than to improve the project in question, which leads to designs that are aimed more at that designer's potential customers than the actual needs of Wikipedia readers and editors.
- Ignoring the factors that have driven the evolution of Wikipedia's design to date.
- Ignoring current work being done to redesign the site.
- The copyright status of unsolicited redesigns is often unspecified.
More generally, a redesign of any large website faces a variety of hurdles between design and implementation, and Wikipedia is no exception:
- Because properly soliciting input from a wide range of stakeholders is a costly and time-consuming process, proposals are often inadequately informed about important design considerations.
- Any serious redesign requires some degree of usability testing and validation from users.
What you can do if you want your redesign to be more seriously considered
If you want a design proposal to be given serious consideration, rather than just considered an interesting portfolio exercise, consider:
- Familiarizing yourself with current Foundation design plans.
- Focusing on a particular problem, like licensing or history, rather than the entire site (since, when trying to redo the entire site, you'll often miss important nuances like those listed above, and implementing your design will take years).
- Releasing the design explicitly under a free license or into the public domain.
If you've done those things, then get the word out in a few places, and choose a space on-wiki to discuss your ideas. These can include:
English Wikipedia Main Pages and portals:
- To discuss redesign ideas with editors, post to the Village Pump for Proposals
Other Wikipedia and sister project design (article and talk pages, mediawiki skins):
- See the Wikimedia Foundation global design page on mediawiki.org
- Post to a mailing list like Wikimedia-l or the official Wikimedia design list
Redesigns which reuse existing Wikipedia HTML markup and classes are more likely to be well received than designs which require a rewrite of the underlying structure. Also, don't forget that you can apply your own, local CSS to Wikipedia pages. You can either do this by editing the page for your username and skin (e.g. Special:Mypage/monobook.css, Special:Mypage/vector.css - see Help:User style), or in your own browser.
Unsolicited redesigns of Wikipedia
Past unsolicited redesigns of Wikipedia include:
Images of hypothetical redesigns that aren't actually live:
- Wikipedia Redefined (commentary)
- Moving Brands rebranding exercise (July 2011)
- Hannes Tank
- Greplin Wikipedia Search Redesign Challenge (site no longer available)
- Hamza Erdogdu(2013-01-18)
- Markus Hauken
- (June 2013)
- 1910 Design & Communication: A Readable Wikipedia (February 2014)
- Wikipedia Concept (April 2014)
- Concept by George Kvasnikov and Julian Krenz (April 2014)
- Wikipedia article page redesign (May 2014)
- Nadia Skovorodneva (2016?)
- "CSS descent" Article in the Russian language, and using the Russian Wikipedia for examples, but mostly applicable to any language. Suggests removing all the sidebar links except the interlanguage links; removing borders around images and page sections; removing editing and discussions links, coordinates, and hatnotes; enlarging fonts; aligning all the images to the end of the text.
Full or mostly full sites:
- http://ency.cl/opedia (blog post)
- Das Referenz by Raureif (May 2014) (via )
- Advanc.io (June 2014)
- WikiWand (June 2014)
- Moe Salih redesign (July 2014)
- buk.io Wikipedia for readers (January 2015, Minsu Kang)
Browser addons or extensions
- The Stylish plugin has many user-contributed themes that adjust the site's CSS to restyle the site.
- Firefox addons (or with more results wiki)
- Chrome addons (or with more results wiki)
From the community:
- mw:Winter (November 2013-)
- mw:Typography refresh (winter 2013–14) — note how even this minor change needed thorough testing and had many bugs reported after release