[HN Gopher] Wikipedia is getting a new look
___________________________________________________________________
Wikipedia is getting a new look
Author : Amorymeltzer
Score : 380 points
Date : 2020-09-23 16:20 UTC (6 hours ago)
(HTM) web link (diff.wikimedia.org)
(TXT) w3m dump (diff.wikimedia.org)
| avmich wrote:
| 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).
| TedDoesntTalk wrote:
| Is it going to be a single-page app with React, Angular, or
| similar?
| timw4mail wrote:
| I sure hope not!
| jdlrobson wrote:
| No. This wouldn't be technically feasible at current time even
| if we wanted to do that.
| amyjess wrote:
| 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.
| sidarape wrote:
| 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.
| gnomewascool wrote:
| 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...
| rovr138 wrote:
| Apparently you can add the CSS to your account based on,
| https://news.ycombinator.com/item?id=24571570
| [deleted]
| burkaman wrote:
| You can open the article in Reader View in Firefox and then set
| the margins to whatever you want.
| amyjess wrote:
| 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.
| tgsovlerkhgsel wrote:
| 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.
| MockObject wrote:
| 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.
| jdlrobson wrote:
| 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
| tech-historian wrote:
| If you're curious what Wikipedia has looked like throughout its
| 20 year history:
|
| https://www.versionmuseum.com/history-of/wikipedia-website
| cpascal wrote:
| Link from the article showing what features they are adding.
|
| https://mediawiki.org/wiki/Reading/Web/Desktop_Improvements#...
| unethical_ban wrote:
| 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.
| wyxuan wrote:
| They say in the user research survey that it's for
| accommodating people new to english/learners.
| krick wrote:
| 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).
| exacube wrote:
| 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..
| cxr wrote:
| Data representation is UI.
| liability wrote:
| > _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.
| bawolff wrote:
| 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.
| krick wrote:
| 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.
| sjy wrote:
| > 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.
| krick wrote:
| 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.
| BSG-Actual wrote:
| 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.
| jl6 wrote:
| 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.
| Normille wrote:
| Are they giving Jimmy Wales's begging bowl a make-over too?
| tyingq wrote:
| I wonder if the mobile look is changing. It already has a
| collapsible sidebar.
| godelmachine wrote:
| Dark mode on Wikipedia would be so amazing!
| DocG wrote:
| 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.
| qwertox wrote:
| 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.
| waldofrank wrote:
| 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...)
| rasz wrote:
| Meaning now you will have to click to even learn if the
| language you are interested in is available.
| grishka wrote:
| 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.
| ziftface wrote:
| 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.
| grishka wrote:
| 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.
| leoxv wrote:
| 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__
| deadmik3 wrote:
| I'm surprised wikipedia has gone this long without joining every
| other website in fixing their unbroken UI
| bawolff wrote:
| I still remember the vector rollout...
| rwesty wrote:
| 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.
| doublesCs wrote:
| uh-oh.
|
| EDIT: After looking at
| https://fr.wikipedia.org/wiki/Province_de_Posnanie it's not so
| bad.
| cw wrote:
| oh no
| chromedev wrote:
| 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.
| liminal wrote:
| 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
| jrochkind1 wrote:
| 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...
| Falell wrote:
| 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.
| notatoad wrote:
| 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.
| davidivadavid wrote:
| 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.
| jrochkind1 wrote:
| I just got link from the OP, but yeah!
| pferde wrote:
| 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... :/
| cxr wrote:
| > 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...
| komali2 wrote:
| 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.
| jbay808 wrote:
| 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!
| waldofrank wrote:
| 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.
| drng wrote:
| 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...)
| pityJuke wrote:
| 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?
| soneil wrote:
| 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)
| BelleOfTheBall wrote:
| 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.
| lloydatkinson wrote:
| A collapsible side bar and max width are hardly big features you
| need a whole post for.
| dehrmann wrote:
| Phew. I was fearing a "reddit redesign" for Wikipedia.
| rikroots wrote:
| 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.
| drng wrote:
| There are several other features they're planning on adding,
| linked in the article:
| https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
| wormslayer666 wrote:
| Direct link to one of the early adopter wikis:
| https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_princip...
| byset wrote:
| 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
| Constellarise wrote:
| Cool, instead of having Wikipedia zoomed in to 150% I have to
| have this one zoomed at 170%.
| aembleton wrote:
| Why? They both use the same font size and line height.
| rovr138 wrote:
| And the sidebar works with no JS. Perfect!
| thewakalix wrote:
| 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.
| stabbles wrote:
| They could just make the mobile wiki the desktop default too. It
| is minimal, readable, and clean.
| mkl wrote:
| It's minimal and clean because everything is hidden. This is
| not a good thing, as it's impossible to search or skim.
| Aerroon wrote:
| 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.
| tomtheelder wrote:
| 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.
| p1mrx wrote:
| 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.
| HipstaJules wrote:
| Finally! Please take care of the paragraphs width and text size.
| I usually use Wikipedia at 250x
| nickosmark wrote:
| 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...
| lights0123 wrote:
| I mean, the Vue.js runtime is smaller (about 73% smaller) than
| jQuery.
| bra-ket wrote:
| 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.
| newyorker2 wrote:
| That would bring something called accountability to the table.
| We're not ready for it yet. Enjoy the new UX!
| Thaxll wrote:
| 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.
| LocalPCGuy wrote:
| > So all documentation website should now have that max line
| widht to better retent the content?
|
| Absolutely.
| [deleted]
| jvzr wrote:
| 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
| kevin_thibedeau wrote:
| Why would you maximize window width on an ultra widescreen?
| That isn't much of a value proposition for (Western) text
| consumption.
| marssaxman wrote:
| That is easy to solve - just don't fullscreen your browser
| window. Set it to a reasonable width and the content will
| follow.
| ryandrake wrote:
| 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.
| formerly_proven wrote:
| FWIW, Wikipedia allows you to add custom CSS and JS that are
| active as soon as you log in.
| dylan604 wrote:
| 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.
| zhte415 wrote:
| 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.
| phildenhoff wrote:
| 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
| adventured wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| [deleted]
| hyperpape wrote:
| 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
| robertoandred wrote:
| So make the window narrower or get a narrower screen if you
| don't want to see empty space. Readability is more important.
| ryandrake wrote:
| 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.
| psychometry wrote:
| 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.
| inetknght wrote:
| 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.
| psychometry wrote:
| 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.
| pwinnski wrote:
| You seem to be agreeing with the parent and Wikipedia and
| the research on the subject.
| DanBC wrote:
| > why is it better than using the full screen?
|
| Are you saying you only have one window open at a time?
| mrguyorama wrote:
| 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?
| zhte415 wrote:
| 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'.
| bzb5 wrote:
| Many people including me use the browser maximised all the
| time.
| bpodgursky wrote:
| 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.
| psychometry wrote:
| 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.
| hyperpape wrote:
| Dan Luu has repeatedly failed to find any good sources for
| this claim:
| https://twitter.com/danluu/status/1115707741102727168.
| [deleted]
| Pilottwave wrote:
| 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.
| zzo38computer wrote:
| 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.
| iamlemec wrote:
| 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.
| Animats wrote:
| _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.
| Macha wrote:
| 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...
| llacb47 wrote:
| rereading ... again is redundant.
| m0ck wrote:
| 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.
| monkeypizza wrote:
| 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
| est31 wrote:
| 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.
| systemvoltage wrote:
| 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 +
| psychometry wrote:
| 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.
| systemvoltage wrote:
| 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.
| davidivadavid wrote:
| Yes, because reading walls of text is such a great
| experience.
|
| You "can always" remove all the styling and get what you
| want.
| cxr wrote:
| > 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)
| colinmhayes wrote:
| Wikiwand has been great for me, but the table formatting is
| atrocious. Really like that the side bar is a table of
| contents.
| boogies wrote:
| 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
| matchbok wrote:
| > 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?
| tomtheelder wrote:
| 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.
| johneth wrote:
| 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.
| ainar-g wrote:
| 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!
| pvorb wrote:
| 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.
| 0xUser wrote:
| 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.
| soneil wrote:
| 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.
| bawolff wrote:
| You can make any preference default by adjust
| $wgDefaultUserOptions
| tspike wrote:
| > 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!
| tgsovlerkhgsel wrote:
| 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_...
| mostlysimilar wrote:
| I feel the same way. I wish interface designers would focus on
| ways to get people comfortable with experimentation instead of
| removing features entirely.
| ryderdini wrote:
| In this case, no feature is being removed--just hidden in a
| collapsible sidebar, but I agree with your overall point.
| tomtheelder wrote:
| 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.
| jbay808 wrote:
| 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.
| Kuinox wrote:
| then make a special UI that editors/authors can enable in
| their preferences...
| jrochkind1 wrote:
| 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.
| Robotbeat wrote:
| 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.
| jrochkind1 wrote:
| 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_lo
| s...
|
| 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_Wikipedi
| a...
| Robotbeat wrote:
| 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.
| sjy wrote:
| 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:W
| ikipedia_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.
| kube-system wrote:
| I think the appropriate direction depends on your audience.
| Being powerful is often a trade off with accessibility.
| drchopchop wrote:
| 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.
| Robotbeat wrote:
| Except the whole point of Wikipedia is that everyone is
| potential an editor...
| [deleted]
| robertoandred wrote:
| I've long thought the the mobile design was better on desktop
| than the desktop design.
| hcarvalhoalves wrote:
| 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...
| coolreader18 wrote:
| You've got the mobile version twice there, I think you probably
| wanted to remove the "m." from one of them.
| lucasnortj wrote:
| Wikipedia reliable? Haha what a joke
| samfisher83 wrote:
| It's fine as is why change it?
| psychometry wrote:
| The post details why it's not fine...
| beefman wrote:
| > 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.
| trynewideas wrote:
| 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.
| iso8859-1 wrote:
| 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.
| choo-t wrote:
| There are also `?useskinversion=1` and `?useskinversion=2`
| which are useful to force the use of the legacy version of
| skins.
| leokennis wrote:
| 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; }
| trynewideas wrote:
| 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.
| pwdisswordfish4 wrote:
| 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_ ).
| dec0dedab0de wrote:
| I hope it doesn't change too much, Wikipedia and Craigslist are
| the only two major websites that have a decent layout these days.
| bredren wrote:
| 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.
| taimoorapps wrote:
| Great. I always really liked mobile wikipedia more than desktop.
| cmckn wrote:
| 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. Other
| things, I think wikipedia.org does better. Excited to see the
| changes!
|
| [1] https://www.wikiwand.com/
| aembleton wrote:
| Thank you. I've never seen wikiwand before but it is a big
| improvement.
| Uehreka wrote:
| 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).
| andrepd wrote:
| 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).
| tgsovlerkhgsel wrote:
| 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.
| systemvoltage wrote:
| 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.
| userbinator wrote:
| 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.
| oblio wrote:
| > 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.
| vvanpo wrote:
| 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.
| est31 wrote:
| On Windows you can do it with a single keybinding.
| Windows key + left or right arrow.
| systemvoltage wrote:
| 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.
| andrepd wrote:
| 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).
| systemvoltage wrote:
| 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.
| mywittyname wrote:
| > 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.
| epicide wrote:
| 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.
| bonoboTP wrote:
| Or do columns like a newspaper, but it's unusual on the
| web.
| grumple wrote:
| > 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.
| msla wrote:
| > 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.
| systemvoltage wrote:
| Use Ctrl(Cmd) and + sign to zoom.
| bpodgursky wrote:
| I also love the new-ish mouseover previews. That was a great
| change imo.
| pintxo wrote:
| As someone "reading with the mouse" I love them until the
| mouseover appears over the piece of text, I was just going to
| read.
| swebs wrote:
| Sounds like you want the responsive design version of
| Wikipedia.
|
| https://en.m.wikipedia.org
| petters wrote:
| 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.
| daniel2x wrote:
| There is a setting to disable it.
|
| You're welcome.
| oblio wrote:
| Setting? Where?
| msla wrote:
| https://en.wikipedia.org/wiki/Special:Preferences#mw-
| prefsec...
|
| Uncheck "Enable Media Viewer" and then click "Save" at
| the very bottom.
| petters wrote:
| Update: This is no longer the case. I can not reproduce this
| any more. Great!
| rvba wrote:
| 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.
| ssully wrote:
| "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.
| aden1ne wrote:
| I use the sidebar a _lot_ for switching between languages.
| WilTimSon wrote:
| 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.
| trynewideas wrote:
| 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
| intrepidhero wrote:
| 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.
| zozbot234 wrote:
| 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.
| seppel wrote:
| 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.
| tgsovlerkhgsel wrote:
| Also, the mobile version collapsing the zippies, which means
| search doesn't work.
| chrisweekly wrote:
| 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.
| mywittyname wrote:
| 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.
| msla wrote:
| 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.)
| spixy wrote:
| I made extension that does exactly that if you want
|
| https://github.com/spixy/NoMoreMobile/blob/master/README.md
| Izno wrote:
| 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.
| davidivadavid wrote:
| 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.
| pbronez wrote:
| They are reducing maximum column width, but perhaps not as
| drastically as you'd wish:
|
| https://www.mediawiki.org/wiki/Special:MyLanguage/Reading/We.
| ..
| davidivadavid wrote:
| Yeah, I don't think 900+px is ideal for reading on a
| desktop computer. Better than nothing, though!
| userbinator wrote:
| Resize the window yourself then. I get far more annoyed
| at sites that refuse to flow text to the desired width.
| stevebmark wrote:
| 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
| cjsawyer wrote:
| Also in-page hovers to other articles!
| thaumasiotes wrote:
| > 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!
| pmachinery wrote:
| > 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.
| gerdesj wrote:
| 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.
| segfaultbuserr wrote:
| > _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.
| jessriedel wrote:
| 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.
| thibran wrote:
| > _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.
| pwdisswordfish4 wrote:
| 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.
| jdlrobson wrote:
| The language button is right at the top of the page. If
| anything its more accessible on mobile?
| thaumasiotes wrote:
| 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.
| tasogare wrote:
| > Functionality that has been carefully designed so you
| won't find it
|
| The button is labeled Wen 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...
| kossTKR wrote:
| Pretty sure 99 out of a 100 don't know what "Wen A"
| means. I've had the same complaint, - never once did it
| occurs to me that "Wen 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.
| webmaven wrote:
| _> 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 "Wen A" is,
| in fact, a text label. The first Chinese glyph even
| translates as "text".
| thaumasiotes wrote:
| > I'll note though that the specific example of "Wen 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. "Wen 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 Yu /Yu . As you
| accurately note, it translates as "writing".
| MayeulC wrote:
| Well, it has one merit at the very least: regardless of
| the interface language, you will find that button.
| thaumasiotes wrote:
| 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.
| jdlrobson wrote:
| 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.
| thaumasiotes wrote:
| > 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 Wen 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.
| cuddlybacon wrote:
| True. But the gif in the article indicates they intend to
| move the language selector to a more prominent location.
| rmetzler wrote:
| 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.
| bakuninsbart wrote:
| 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.
| em-bee wrote:
| 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
| bakuninsbart wrote:
| 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.
| 867-5309 wrote:
| try changing your IP address, OS language/region and
| browser language to English
| rasz wrote:
| 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) } })
| karmakaze wrote:
| There's a left-hand sidebar? I've gotten completely blind to
| its existence...I once knew there was stuff below the logo.
| WWLink wrote:
| > 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.
| watwut wrote:
| 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
| mywittyname wrote:
| 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.
| pintxo wrote:
| Reader View is available in Firefox.
| ehavener wrote:
| Opening the dev tools works
| upgrejd wrote:
| I use the left hand side bar, I like to read the articles in
| different languages.
| tomrod wrote:
| Also, tables on mobile.
| Isognoviastoma wrote:
| 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.
| baby wrote:
| I use the left side bars to switch languages all the time
| amirkdv wrote:
| > _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.
| eepp wrote:
| For English-French translation in Quebec, have a look at
| http://m.gdt.oqlf.gouv.qc.ca/index.aspx
| giddhhgcfygfg wrote:
| 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 electronique." 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.
| nbadg wrote:
| 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!
| blewboarwastake wrote:
| 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.
| ehsankia wrote:
| 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 :)
| waldofrank wrote:
| 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/We
| b/Desktop_Improveme... The conclusions of the user testing
| show that people have a much easier time finding them in
| the new location.
| thoughtleader31 wrote:
| 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.
| Eiriksmal wrote:
| 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] Kohlenstofffaserverstarkter Kunststoff, of course.
|
| [1] https://larrysanger.org/2020/05/wikipedia-is-badly-
| biased/
|
| [2] https://static.googleusercontent.com/media/guidelines.rat
| erh... Pages 16-18
| anyfoo wrote:
| 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.
| lhoff wrote:
| The literal translation for carbon fiber would be
| "Kohlefaser" and that is also used quite commonly.
| bernulli wrote:
| 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).
| seppel wrote:
| > How else do you know what they call carbon fiber in
| German? [0] > [0] Kohlenstofffaserverstarkter Kunststoff,
| of course.
|
| Well, it actually not that simple :)
|
| Kohlenstofffaserverstarkter 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
| Kohlenstofffaserverstarkter 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_rei
| nforced_polyme...
| [3]https://en.wikipedia.org/wiki/Carbon_fibers [4]
| https://de.wikipedia.org/wiki/Kohlenstofffaser
| tsimionescu wrote:
| > 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.
| giddhhgcfygfg wrote:
| 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...
| bosswipe wrote:
| 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.
| CydeWeys wrote:
| 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.
| grawprog wrote:
| Even 8chan had some level of editorial judgement, however
| small it was. It was there.
| mschuster91 wrote:
| > 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/Wikipedi
| a: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)
| jeromegv wrote:
| 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.
| tasogare wrote:
| 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.
| dheera wrote:
| > 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 Lao Zhua
| in Beijing Mandarin and Liao Guo in Taiwanese Mandarin and
| Wikipedia knows this. Likewise, a USB drive is almost
| universally called "UPan " 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.
| ttsda wrote:
| The direct link to the commons page is also useful for
| finding pictures related to a topic.
| [deleted]
| azepoi wrote:
| I am constantly juggling between several languages and always
| preferred the desktop version for this reason.
| FpUser wrote:
| "Not changing for 10 years..."
|
| I absolutely love that part about Wikipedia.
| ksec wrote:
| Which is why I almost always use the mobile variant of
| Wikipedia. It is so much better, even on Desktop.
| mkl wrote:
| I find it really frustrating, because the sections all start
| collapsed, so "Find in page" doesn't work.
| buovjaga wrote:
| 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/
| MayeulC wrote:
| Then it explains the difference I've seen for a few weeks,
| thanks. It's not much different, mostly narrower.
| lultimouomo wrote:
| > 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.
| vaccinator wrote:
| > I almost never use the left hand side bar
|
| I use it most often to change the language...
| [deleted]
| G4BB3R wrote:
| 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.
| pier25 wrote:
| I agree on both. I actually prefer using their mobile site on
| desktop.
| kome wrote:
| I use it very often, just because i check articles in multiple
| languages.
| Aerroon wrote:
| 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.
| segfaultbuserr wrote:
| 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.
| formerly_proven wrote:
| Languages - yes, all the other links - almost never.
| wodenokoto wrote:
| 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.
| mfsch wrote:
| 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.
| bananamerica wrote:
| I use the sidebar a lot to find the same article in another
| language. But that's the only use I have for it.
| rossdavidh wrote:
| 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.
| paulirish wrote:
| 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...
| [deleted]
| martinrlzd wrote:
| On Firefox I use Redirector, I set it to redirect from
| ^(https*:\/\/)(?!www)([a-z]+)\.wikipedia\.org\/wiki\/(.+)
|
| to https://$2.m.wikipedia.org/wiki/$3
|
| Works well!
| bawolff wrote:
| 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)
| [deleted]
| chriswalz wrote:
| I have used Wikiwand Extension for the past couple of years and
| haven't looked back. Happy to hear about max width change though!
| StillBored wrote:
| 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.
| ziftface wrote:
| 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.
| tgsovlerkhgsel wrote:
| 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.
| capableweb wrote:
| 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.
| tgsovlerkhgsel wrote:
| 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.
| swebs wrote:
| And for the love of god, don't add anything that will require a
| cookie pop up.
| toxik wrote:
| 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.
| codeflo wrote:
| 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.
| wishysgb wrote:
| 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
| SippinLean wrote:
| I'm writing a custom skin (CSS) to turn New Reddit into Old
| Reddit for when they inevitably, sadly, turn off
| old.reddit.com
| alufers wrote:
| 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.
| mcnesium wrote:
| 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 ;)
| Slackwise wrote:
| 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...
| Amorymeltzer wrote:
| 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.
| SusAnnie wrote:
| 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.
| zozbot234 wrote:
| 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!
| SusAnnie wrote:
| Thank you so much for sharing that, I'll check it out! :)
| TedDoesntTalk wrote:
| 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.
| Symbiote wrote:
| 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.
| Macha wrote:
| 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
| Ciantic wrote:
| 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.
| anotheryou wrote:
| 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.
| jgwil2 wrote:
| If anybody wants to try for themselves in their language, go to
| "Preferences" >> "Appearance" and uncheck "Use Legacy Vector"
___________________________________________________________________
(page generated 2020-09-23 23:00 UTC)