281–290 of 529 posts
Maybe I should write a browser extension that automatically adds the "m." prefix to Wikipedia URLs.
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-trippi…
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.
Earlier quoted context omitted.
> 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…
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.
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…
> 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 d…
Earlier quoted context omitted.
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…
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…
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.
Earlier quoted context omitted.
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.
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.
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.
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 pro…
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.…
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.