[HN Gopher] Explore Wikipedia's New Look
___________________________________________________________________
Explore Wikipedia's New Look
Author : zebracanevra
Score : 118 points
Date : 2023-01-18 16:49 UTC (6 hours ago)
(HTM) web link (wikimediafoundation.org)
(TXT) w3m dump (wikimediafoundation.org)
| Sunspark wrote:
| Should use white for the text colour to give the design a
| consistent theme.
| yamtaddle wrote:
| Initial reactions from watching the gif, coming in cold, having
| not seen the new design:
|
| 2003: Ouch. Yeah, that's bad.
|
| 2005: Great.
|
| 2011: Not worse. Maybe a little better. I have a vague
| recollection that some things that aren't well-showcased by a
| still got better with this one, but the still is at least not-
| offputting compared with '05.
|
| 2022: LOL are you serious? You cannot be serious. Please tell me
| this is unfinished.
|
| All that padding. WTF. Someone accidentally hit "0" too many
| times in their CSS editor.
|
| [EDIT] I mean I guess you need enormous swathes of empty space
| when you remove all other indicators of section division, but...
| like... just don't do that, then?
|
| [EDIT 2] OK, I was like, "whatever, it sucks, but I'll get over
| it" until I read this: "When you are logged in to Wikipedia, the
| updated header will move with you as you scroll." Thank god when
| I try it on the site this doesn't actually work, since that'd
| force me to have custom CSS for Wikipedia. {ah, I see now it's
| because I'm not logged in. Great, easy to avoid then, no problem}
| Also: I'd love a before-after on page weight. Everyone always
| seems to add like a full MB of junk to the damn page when they
| add smart search like that, for some reason, even though it
| shouldn't require anywhere near that much (see: Github, whose
| pages bloated a ton when they made their search field "smarter").
| One of the nicest things about WP is that it's semi-usable on a
| potato connection and I wouldn't want to see them sacrifice that
| in the name of almost _any_ other improvement.
|
| [EDIT 3] Being the change I want to see in the world: I checked
| with caches disabled and it looks like transfer and weight are
| damn near identical compared with the "wikiless" site that
| someone else linked, for the same article. Very nice, happy to
| see that. However, it appears to use _double_ the memory of the
| Wikiless version (which I suppose represents something closer to
| the old design?) which seems pretty bad to me.
| coldpie wrote:
| > When you are logged in to Wikipedia, the updated header will
| move with you as you scroll
|
| We need to stage some kind of intervention with web designers.
| There can't be a single person on the planet who actually likes
| this anti-feature. Why on Earth do they keep doing it?
| yamtaddle wrote:
| If it's static, at least it's not the worst kind (though I
| still "select element -> remove" when I see those): the ones
| that bounce down when you scroll up even one notch, covering
| _the very thing you were scrolling up to see_ , are the web
| design equivalent of someone slapping you in the face.
| ketzu wrote:
| Could you explain to me why this is an anti feature? It seems
| harmless at worst and useful at best to me, e.g., having
| access to the search feature and lagnuage select during
| scroll here. (Serious question, I feel like I am missing
| something after reading this thread.)
|
| I guess I dislike it on mobile when it takes up too much
| space.
| coldpie wrote:
| > it takes up too much space
|
| Mostly this. I visit a website to view its content, not its
| header. I don't need to waste 10% of the screen on
| something I will almost never use. On Desktop, I can press
| "Home" to get to the header in the rare instances I want
| to. On Mobile, screen space is even more valuable, so it's
| even more annoying to have to waste screen space on the
| stupid header (and no, web designers, the style that pops
| up and _covers up the content you are trying to read_ when
| you scroll up one pixel is not a solution).
|
| I'm here to read. Stop interfering with that.
| yamtaddle wrote:
| I just gave some thought to why it bothers me and I
| actually think some of it might be because they trigger a
| kind of "oh shit a 'search bar' add-on, kill it with
| fire!" reflex from the bad ol' days of most computers
| being full of malware and spyware (now the OS and most
| programs are spyware, so... progress?).
|
| Of course the big ones are simply obnoxious wastes of
| space, and any that have a drop shadow on the content
| bother me for what seem like obvious reasons, but even
| the small ones bug me and I think that might be why.
|
| [EDIT] That's just for the static ones--the ones that pop
| in and out based on scroll behavior are one of the worst
| design trends in the entire history of the Web, which is
| saying something, and are in an angry-making category all
| their own.
| cecilpl2 wrote:
| Because most people like it and it improves metrics.
|
| From the discussion on sticky header [0],
|
| > Our preliminary results show that an overwhelming majority
| of test participants reported positive experience with a
| sticky header. Participants mentioned they enjoyed the
| ability to access important functionality from any part of
| the page.
|
| > Overall, there was an average 15% decrease in scrolls per
| session by logged-in users on the 15 pilot wikis in the
| treatment group (with the new sticky header), compared to the
| control group (without the sticky header). This indicates
| that our hypothesis was correct - adding the sticky header to
| the page reduced the need to scroll to the top of the page
| significantly.
|
| > there was a 2.8% and a 6.8% increase in the percent of
| people who were able to successfully complete at least one
| edit using the edit button within the sticky header,
|
| [0] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improv
| eme...
| coldpie wrote:
| It might improve stats _for people who use the header_ ,
| but I'm pretty sure that's a tiny fraction of users. I just
| want the screen space and consistent scrolling behavior,
| not a header popping in and out as you scroll around or
| reach the top of the page.
| mschuster91 wrote:
| What, excuse me, _the fuck_. It 's almost like _all_ lessons from
| the Windows 95 era were forgotten (see e.g. [1], and the top
| comment of the HN discussion is worth a read as well [2]). No
| borders visually separating areas of different function, no
| visible indicators where the clickable area of an UI element
| (e.g. a button) is, and the content jumps to the right when
| opening the main menu.
|
| > These improvements will make Wikipedia more welcoming and
| easier to use.
|
| Above quote from the notification, which, again, has no visual
| borders. Just an insanely contrast-less sky blue on a white
| background.
|
| Whoever has thought of this being a good idea should just go and
| resign in shame. Not every questionable design "trend" has to be
| followed.
|
| [1] https://twitter.com/tuomassalo/status/978717292023500805
|
| [2] https://news.ycombinator.com/item?id=21888451
| yellowapple wrote:
| This is all fine and dandy, but it baffles me that in the Year of
| Our Lord 2023 Wikipedia _still_ insists on separate domains /URLs
| for mobile v. everything else.
| danjoredd wrote:
| I don't like it. It was fine the way it was. I like the new table
| of contents though. Thats kind of useful
| satvikpendem wrote:
| Finally. I have a big monitor and the line width is insane, glad
| they made it a more reasonable column layout, moving my head from
| end to end was getting very annoying that I had to use custom CSS
| instead.
| fmajid wrote:
| They could have made a responsive multi-column layout to keep
| the readability of reasonable line lengths while keeping
| information density high.
| blep_ wrote:
| Why can't you just resize the window to a width that is
| comfortable for you?
| satvikpendem wrote:
| I use all my applications in full screen mode usually, so
| resizing just for a single tab or moving Wikipedia into its
| own window would be annoying too.
| wormslayer666 wrote:
| Lots of whitespace, lots of unnecessary animations, and lots of
| floating bars I'd never click occupying screen space. Hopefully
| this isn't too hard to fix with browser extensions.
| nipperkinfeet wrote:
| It seems fine. I'm glad they didn't use a useless watered-down
| mobile design with excessively rounded components like Xfinity
| and other businesses have lately been doing. On larger monitors,
| there should be a full width option though.
| BitwiseFool wrote:
| I sense part of what drove this redesign is the fact that 4K and
| Ultrawide monitors are now common enough that designing to
| accommodate them cannot be ignored. That being said, I much
| prefer left-justification instead of centering the content and
| having massive whitespace islands to either side. I wish there
| was an option to left justify.
| 51Cards wrote:
| I'm the reverse of you in that I prefer content in the middle,
| as I sit in the middle of my screen and prefer to not have to
| be constantly looking to the left. I agree, personal choice
| would be nice.
| aendruk wrote:
| Sigh, yet another site that self-destructs into a distorted
| mobile layout at a still spacious viewport width. Am I the only
| person with two windows up?
|
| Screenshot: https://cloudflare-
| ipfs.com/ipfs/QmaovnEHiCo6knhTPpp4XJyr5x9...
| slimginz wrote:
| For people who don't like the new look, you can go to
| preferences->Appearance and select 'Vector (Legacy)'. It does
| require you to login first which is annoying but at least you can
| easily go back to the old look.
|
| Edit: You can also have it take up the entire width by hitting
| the button in the bottom right. Doesn't seem to remember the
| change for me though so hopefully they add that in soon.
| rchard2scout wrote:
| IIRC, the button in the bottom right is intended to not
| remember the change. To make the full width setting persistent,
| when you're logged in, go to Preferences -> Appearance, and
| disable "Enable limited width mode".
| coldpie wrote:
| > You can also have it take up the entire width by hitting the
| button in the bottom right. Doesn't seem to remember the change
| for me though so hopefully they add that in soon.
|
| Ooh good spot. That fixes my one issue, the bizarrely narrow
| column width.
| Snitch-Thursday wrote:
| Thank you! I first went back to vector legacy, but then I saw
| monobook which is the wikipedia of my memories and have swapped
| there, so now I'm happy.
|
| Kudos to WM for keeping the option for that theme in MediaWiki.
| Now I have a reason to browse logged in all the time.
| trynewideas wrote:
| Details on the design process:
| https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
|
| -
|
| On Wikipedia, and any MediaWiki installation, you can add the
| _useskin_ query parameter to the URL to change skins on a page,
| even when not logged in.
|
| Current (vector-2022):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ve...
|
| Previous (vector):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ve...
|
| Older (monobook):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mo...
|
| Older alternative (modern):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mo...
|
| Older alternative (cologneblue):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=co...
|
| Mobile (minerva):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mi...
|
| Responsive alternative (timeless):
| https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ti...
|
| Installed skin list:
| https://en.wikipedia.org/wiki/Special:Version
| yamtaddle wrote:
| Looks like my analysis on the other post using Wikiless for
| comparison is wrong: the new theme does transfer about 50% more
| data and has double the uncompressed "weight" that the previous
| one did, for this article. Memory use similar, bouncing between
| about 215 and 230MB.
| chazeon wrote:
| Have been using this new theme since beta. I love the much
| cleaner look more than the previous one. One can always tune the
| CSS yourself at the user's preference near the theme selector.
| The only thing I need to adjust to my liking is to limit the line
| width: main#content { max-width:
| 40em; }
|
| For those who hate it: you will always have the option to switch
| back to the old theme.
|
| I really hope any website could be as flexible as Wikipedia to
| allow users to write their own CSS.
| kerpotgh wrote:
| How do you make the max-width apply permanently to a website on
| chrome?
| sturob wrote:
| If you're logged in to wikipedia you can add custom css (and
| js) in 'Preferences > Appearance'
| flobosg wrote:
| You can use an extension such as Stylebot: https://chrome.goo
| gle.com/webstore/detail/stylebot/oiaejidbm...
| marcodiego wrote:
| My personal problem with it: the sidebar became wider. Now I have
| to disable it, but when I disable it, it disappears and makes the
| text lines much wider than what I'm used to. I'm one of those few
| people who don't maximize the browser to get a good acceptable
| line width. Wikipedia simply broke this :(
| 51Cards wrote:
| You can set a fixed width view in the preferences which might
| help a lot.
| 7373737373 wrote:
| Great, now it takes two clicks to switch languages
|
| old.wikipedia.org when?
| askvictor wrote:
| Now, is there a dark mode like on the app?
| mostlysimilar wrote:
| Floating table of contents on the left is a nice feature, but why
| is the styling so plain? It's just links floating in a void. Why
| do modern designers hate borders so much?
| ssalka wrote:
| Looks nice on desktop, have yet to see how mobile has changed.
| Oddly, I find that it still shows the old UI on certain pages?
| Eg:
|
| https://en.wikipedia.org/wiki/Does_not_compute
| https://en.wikipedia.org/wiki/Combinatorics
| https://en.wikipedia.org/wiki/Stable_Diffusion
|
| And I guess my one complaint is, it now takes 2 clicks to iterate
| through random articles.
| kibwen wrote:
| I appreciate the table of contents moving to the left-hand
| sidebar, needing to scroll back to the top in order to navigate a
| long page or get a permalink was always an annoyance.
| justoreply wrote:
| I really like it
| realworldperson wrote:
| [dead]
| keb_ wrote:
| I think it's nice actually. It also works great with JavaScript
| disabled! Thanks Wikipedia.
| wolpoli wrote:
| I don't like the extra padding that every designer is adding into
| every web site and application. I need to keep multiple
| sites/apps on my screen as I need to look at references, work on
| my tasks, and communicate with others. but every designer thinks
| I should maximize their site/app. It's forcing me to resize and
| move windows all the time.
| Gualdrapo wrote:
| I don't think "every" designer does that.
|
| And not everyone wants all content crammed into a little area.
|
| All in all, it should be up to the user decide how much content
| density they want on websites.
| dangus wrote:
| The article addresses this by mentioning that they referenced
| research demonstrating text that is too wide causes people to
| read less comfortably and retain less information.
|
| The page gets much less padded when you reduce the size of the
| window, because the padding isn't there to make blank space,
| it's there to enforce a maximum line width.
| ssnistfajen wrote:
| The new layout style, most notably the centrered text blocks, has
| already been the default on a few other language versions of
| Wikipedia most notably fr.wikipedia.org.
| karaterobot wrote:
| I don't need a header to follow me down the page, in fact I'd
| prefer it not to. On the very rare occasion when I need to scroll
| all the way to the top of the page, I have no problem figuring
| out how to do that. Feels like they're introducing a persistent
| UI element without a benefit. Benefit to me, anyway. Maybe they
| heard from a lot of users who were having trouble remembering
| where the header was, I can't say. I don't log in to Wikipedia,
| so this doesn't affect me much at present.
|
| I'm not sure what value the collapsible table of contents is.
| Maybe it's useful on mobile, to help save screen space, but on
| desktop it would just be extra work for me to collapse the
| sections (which appear to be expanded by default). I have not
| found the length of the table of contents to be a problem, and I
| see the value of this structure as being that it allows me to see
| everything at once.
|
| I get why having a maximum line length is good for readability.
| My reaction to this feature is negative, but I wonder if it's
| because I've gotten good at sizing Wikipedia articles the way I
| like them to be, by upping the font size and shrinking my browser
| window. Maybe I will come around on it, but my initial reaction
| was that I don't trust them to make the right decision for me, so
| I'd rather they just kept it flexible.
| anthonypasq wrote:
| all these changes are geared at mobile. I imagine thats the
| majority of their traffic now
| dredmorbius wrote:
| The maximum line width is specifically applicable to Very
| Large Desktop Displays, not mobile.
|
| Several other changes ... seem fairly agnostic.
| babypuncher wrote:
| Are they? Wikipedia has great apps for iOS and Android.
|
| I feel like some of these changes are meant to make better
| use of the landscape aspect ratios typical in laptop and
| desktop setups (i.e. moving the ToC to the left)
| gpm wrote:
| I don't need a header either, but I suppose for people editing
| wikipedia it might be pretty useful. It probably makes sense
| for wikipedia to optimize for the people providing the free
| labour slightly more than they optimize for the readers.
| nsajko wrote:
| You suppose wrong.
| rickstanley wrote:
| Yeah, I don't like it either, and I don't see a way to disable
| this apart from user's defined bookmark script, like kill
| sticky[0]: javascript:(function()%7Bdocument.
| querySelectorAll(%22body%20*%22).forEach(function(node)%7Bif(%5
| B%22fixed%22%2C%22sticky%22%5D.includes(getComputedStyle(node).
| position))%7Bnode.parentNode.removeChild(node)%7D%7D)%3Bdocumen
| t.querySelectorAll(%22html%20*%22).forEach(function(node)%7Bvar
| %20s%3DgetComputedStyle(node)%3Bif(%22hidden%22%3D%3D%3Ds%5B%22
| overflow%22%5D)%7Bnode.style%5B%22overflow%22%5D%3D%22visible%2
| 2%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-x%22%5D)%7Bnode.sty
| le%5B%22overflow-x%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3
| D%3Ds%5B%22overflow-y%22%5D)%7Bnode.style%5B%22overflow-y%22%5D
| %3D%22visible%22%7D%7D)%3Bvar%20htmlNode%3Ddocument.querySelect
| or(%22html%22)%3BhtmlNode.style%5B%22overflow%22%5D%3D%22visibl
| e%22%3BhtmlNode.style%5B%22overflow-x%22%5D%3D%22visible%22%3Bh
| tmlNode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D)()%3B%0A
|
| But unfortunately, it renders the header useless in this case.
|
| [0]: https://github.com/t-mart/kill-sticky
| zeta0134 wrote:
| I usually use my adblocker to simply remove fixed headers.
| Hopefully there isn't anything critically important in that
| thing, because whatever's up there just isn't going to be seen.
| They're far too distracting.
| babypuncher wrote:
| Reading your comment I got worried that there was going to be
| this giant banner permanently affixed to the top of the view.
| Taking a look, the actual implementation is very small and
| unobtrusive.
|
| I don't know that I prefer it, but I also don't think I hate
| it. I feel indifferent.
|
| I definitely _love_ how they put the ToC off to the left. It 's
| a great use of all the horizontal space on our 16:9 screens,
| and will make zipping around to different parts of a large
| article a lot easier. I'm willing to put up with the small
| banner in exchange for this.
| 51Cards wrote:
| Note to those not liking this, there is an option in the
| preferences to revert to the old Vector skin. No idea how long
| this will be but setting that preference may give them feedback
| that some users prefer the old layout.
| dredmorbius wrote:
| The overwhelming majority of people will simply accept
| defaults.
|
| To what extent Wikipedia's UI/UX assessment team are aware of
| this and can note a strong defection from any new features
| _even where that defection represents only a small fraction
| of visitors_ I don 't know.
|
| Worse: sufficiently annoying / offputting features can simply
| lead to defection from a site entirely. A major problem with
| A/B testing is that _if the cumulative effect of features has
| been to drive away those preferring the path not taken_ ,
| then all your A/B tests are doing is validating survivorship
| bias.
|
| (I'd give my experience with Reddit over the years, which has
| lead me to all but entirely avoid the site, or more recently
| a rather drastic turn in Twitter's dynamics affecting many
| long-term participants, as cases in point.)
|
| Of the specific changes Wikipedia are putting into place, the
| maximum line length is a style change I've applied myself for
| about a decade now using various CSS browser extensions. I'm
| not much a fan of pinned headers, though that would be less
| an issue on desktop than my e-ink tablet. For that, I prefer
| the Desktop layout generally, but zoom the screen to cut off
| the left-hand sidebar entirely, which works fairly well until
| such time as I want to view an image fully zoomed.
|
| I _do_ find the sidebar useful on desktop. The present Mobile
| layout is annoying in multiple regards though it might be
| useful on a smaller device (I 'm using a 13" e-ink tablet,
| which is generally _not_ constrained for space.)
| pavon wrote:
| I love the new design when not logged in. After logging in
| however...
|
| > I don't need a header to follow me down the page, in fact I'd
| prefer it not to.
|
| Edit: I wasn't logged in before, and thus wasn't shown the
| header you are talking about. Now that I see it, I'm with you
| and don't like it. Everything there could have gone in the
| sidebar above the ToC instead of wasting vertical space. I also
| dislike the extra non-persistant sidebar box shown when logged
| in that pushes the ToC down off the screen. That should be one
| side or the other, not in place of the ToC.
|
| I find the persistent ToC to be _very_ helpful, and the space
| is uses would have gone to waste anyway in full-screen mode, so
| it doesn 't cause any harm. I don't love the menu button in
| half-screen (and presumably mobile) mode. I feel like they
| would have been better off with a full-width bar at that point
| since it blocks reading those top few lines anyway.
|
| > I'm not sure what value the collapsible table of contents is.
|
| For some articles the full multi-level ToC is longer than will
| fit on a single page, so you either need to allow collapsing,
| or scrolling of the side bar which never works well.
|
| > I get why having a maximum line length is good for
| readability. My reaction to this feature is negative ...
|
| I was nervous when I read this as well, but I like the results.
| They didn't over do it like so many websites to today with tiny
| newspaper-like columns, and will be more readable for the
| majority of people who never resize the browser. For me, I keep
| all my browser windows half-screen anyway and the redesign has
| smaller gutters than before, which is a win.
| ablob wrote:
| >> I don't need a header to follow me down the page, in fact
| I'd prefer it not to. > I find the persistent ToC to be
| very helpful
|
| This sounds like the perfect application of customization.
| Why chose one, when you could have both at nearly no cost. :)
| pavon wrote:
| It is customizable. If you are logged in you can choose any
| of the designs they have had since the site was created,
| and if you don't like any of those, it lets you add your
| own custom CSS.
| xeyownt wrote:
| Wikipedia is really becoming awesome, and for me is really a
| Wonder of the modern world.
|
| Combined with tools like ChatGPT (or improved variants) for high
| quality translation of any article in any language, or combining
| submissions in several languages, or to get summaries or
| interactive explanations on some subject, this will become the
| most powerful tool of knowledge in history.
| ssnistfajen wrote:
| Lots of Wikipedia articles have become well-cited but that
| facade begins to break down as we dive into more niche topics.
| Editor wars are real and impossible to resolve most of the time
| due to how obsessive the involved parties are. Some of them are
| rather damaging to what narrative is being shaped on some of
| these articles. The power to control edit access rests in a
| small group of administrators/moderators who are relatively
| anonymous. This has served the site well so far but could be a
| weak point should something occur in the future that
| fundamentally challenges the integrity of Wikipedia.
| psacawa wrote:
| Good:
|
| - Sidebar for navigation
|
| Bad:
|
| - Wasted screen space
|
| - Other languages are not available as a simple anchor tag
| anymore. They are hidden behind <button> elements. It's annoying
| for readers who consult their own language and en.wikipedia.org
| in the same session. It breaks my bookmarklet to change
| languages, which depended on something like
| `document.querySelectorAll('a')`
| mike_d wrote:
| > - Wasted screen space
|
| Don't worry, it will soon be filled with solicitations for
| donations.
| askvictor wrote:
| Humans read best when a line is around 10 words long. Longer,
| and it's easy to lose which line you're on when you go to the
| next one. The sidebar collapses if you resize to a narrower
| window, so I wouldn't call it wasted.
| Fauntleroy wrote:
| Even in the new design the line length is way too long. I get
| complaints about wasted screen space, but you really don't want
| lines of text blasting all the way across the screen either.
| atsjie wrote:
| Fully agree. I always downsized my window to read a Wikipedia
| article (I use fairly large desktop monitors, but not a
| widescreen). The sentences were comically large making it
| really hard to see what the next line is.
|
| Even in the new design they're still a bit larger than what
| I'd like.
| vermooten wrote:
| Magnify to 150% and it's readable again.
| g051051 wrote:
| Thanks, I hate it. Everything I loathe about "modern" web design
| made manifest here, and switched on without warning! At least I
| can turn it off in settings.
| ohCh6zos wrote:
| You can even turn off responsive design in the settings. I
| should have checked earlier.
| gardenhedge wrote:
| I didn't like the look of it from that GIF but after visiting it
| I don't mind it at all
| Y_Y wrote:
| The Second Law of Interface Thermodynamics means that the
| software can't get more usable with time, nor can it even retain
| its previous level of usability.
|
| Everything decays, especially software.
| muti wrote:
| A max line width is welcome from me, I'll be able to remove my
| tampermonkey script for wikipedia.
|
| I'll still need to keep the generic one around that I use on
| demand to fix other unreadable pages though.
| ketzu wrote:
| I really like it.
|
| Mostly the repurposing of the left side for the table of
| contents, but also the width reduction. I only use half of my
| screen for my browser already, and on many pages, lines are just
| insanely long.
|
| Personally, I nevery really minded having open space on websites.
| I never felt it made reading worse. Contrary, pages with little
| whitespace felt cramped and I lost my position now and then. But
| I understand that other people will feel differently about that.
|
| I'd stil like the language selector below the table of contents
| in the sidebar.
| yamtaddle wrote:
| I wish they'd let the old sidebar display as a third column if
| the viewport's wide enough. However, this:
|
| > I'd stil like the language selector below the table of
| contents in the sidebar.
|
| would also cover most of the reason I wish they'd do that.
|
| [EDIT] Incidentally, what ever happened to 3-column layouts?
| They could keep the site menu on the left and stick the TOC on
| the right (keeping it visible all the time is _definitely_ an
| improvement, and the thing I like most about this redesign). We
| used those layouts a _ton_ when 800x600 4:3 was still a common
| monitor resolution & ratio, so surely it'd be fine on 16:9 and
| 16:10 monitors with 3x or more the pixels.
| Willish42 wrote:
| > Research has shown that limiting the width of longform text
| leads to a more comfortable reading experience, and better
| retention of the content itself.
|
| Is this actually true? I'm curious if anybody has sources for
| this and if it's a common UX practice. I tend to use wider
| windows than traditional 8:9 half-screens and this max-width
| practice drives me nuts.
| favorited wrote:
| It's a common accessibility requirement. For example, WCAG
| suggests limiting the max width of blocks of text to ~80
| characters (40 for CJK).
|
| https://www.w3.org/TR/WCAG22/#visual-presentation
| messe wrote:
| Anecdotal, but personally I can't stand reading overly long
| lines and don't keep my browser window maximised. I've written
| user styles for certain sites in order to keep lines
| sufficiently narrow, and I'm one of the few people I know to
| use an 12.9" iPad Pro in portrait mode regularly.
| rozab wrote:
| >When you are logged in to Wikipedia, the updated header will
| move with you as you scroll. You will no longer need to scroll to
| the top of the page to find what you are looking for, and you can
| focus on reading and editing instead.
|
| How do people write things like this with a straight face
| [deleted]
| carapace wrote:
| _oh goddammit_
|
| (sorry)
|
| Is there a way to change it back?
| baal80spam wrote:
| Thank god for wikiless.
| yamtaddle wrote:
| 1) Awesome, didn't know about this, but
|
| 2) Are they ingesting and modifying raw WP pages, and haven't
| updated for the new design? I ask because on desktop Safari
| there are tons of major layout errors (search field completely
| overlaps left menu; top logo image missing; page stretches one
| full, empty screenfull past the end of the footer; some text
| sits on top of section dividers rather than within the
| boundaries of a section) and wonder whether that's normal or
| just a temporary issue.
| drcongo wrote:
| Oh, it's still hideous. Years ago I used to have a Safari
| extension that made Wikipedia look absolutely beautiful, with
| vastly improved readability. Such was the shock when that
| extension finally stopped working that I can still remember where
| I was when I suddenly saw the full horror of its regular design.
| coldpie wrote:
| I would be curious to know what your beautiful version looked
| like. I find Wikipedia's styling so inoffensive that I don't
| understand how you could consider it "hideous." It's pretty
| much just black text on a white background. What about that
| causes such a strong reaction from you?
| liberia wrote:
| I browse with Safari on iOS with JS disabled by default. I do
| this for privacy and accessibility reasons (gotta stop those
| annoying popup modals, trackers and other annoyances).
|
| One thing I noticed with Wikipedia with JS /enabled/, all the
| sub-categories of a topic are by default, closed.
|
| But when I browse with JS disabled, all the sub-categories are
| /opened/ and I have the _full article_.
|
| Since most people browse with JS enabled, this means they have to
| make additional clicks just to read the sub-categories.
|
| Which leads me to question: which version is better? The JS where
| you have to make additional clicks, or the no-js version where
| you get the full article?
| shrx wrote:
| I always prefer the full article, but this is a matter of
| opinion. The issue is that the behavior is not consistent.
| [deleted]
| emehex wrote:
| Gut reaction: I hate it. But I'll probably get used to it...
| zebracanevra wrote:
| Yeah, same reaction for me... I've always liked the small
| gradients on the top and the long list of things down the left
| side which I never click. Felt homely. I'll miss it.
| BitwiseFool wrote:
| I pray that one day colors other than just white and light
| grays return to the backgrounds of elements on the web. The
| zealot inside of me also wishes for skeuomorphism to make a
| glorious comeback, but I may not see that in my lifetime.
| skyyler wrote:
| Same! I absolutely hate the amount of empty space everywhere on
| my 1080p screen.
| timeon wrote:
| > probably get used to it...
|
| Since it is on some language version for some time I already
| did. But it took some time.
| ohCh6zos wrote:
| Why is everyone moving to so much white space? I wish there was
| more of an emphasis on information density on the modern web.
| smarkov wrote:
| Because it emphasizes the distinction between different parts
| of a website which in turn makes it easier to focus on
| individual things.
|
| Why are so many people against white space when it hasn't been
| overdone? Obviously "overdone" means different things to
| different people but in this case the information that matters
| is still pretty dense.
| ohCh6zos wrote:
| I took some quick measurements. The previous version leaves
| 2% of my browser window as whitespace containing no images or
| text. By comparison, the new version is 53% whitespace. That
| seems pretty extreme to me.
| dymk wrote:
| Because human eyes and brains aren't computers, and it's
| actually hard to read small text on long lines and low vertical
| spacing.
| mpsprd wrote:
| The table of contents is a great addition! Whitespace/minimalist
| styling is of little importance as it will change with design
| fashions, while the table will stay a net positive.
| ashton314 wrote:
| My initial take: I actually like this a lot. The body text is
| narrower which makes for easier reading. The sidebar with an
| updating highlight of current place in document is really nice
| too. I don't mind the "wasted space": Wikipedia is primarily
| about reading, and any well typeset book or web page should have
| generous margins so the line length is not too long.
| nsajko wrote:
| Text width is important, but this is not a solution, zooming
| and changing browser window geometry is.
| gpm wrote:
| Mac OS (and some linux desktops) seems to really expect you
| to manage windows by having them always be full screen and
| swiping between desktops. Which makes changing browser window
| geometry sub-optimal.
|
| Even on desktops where it's reasonably easy, it's pretty
| annoying to have to resize the window when you go to
| different sites to get them to format properly.
| kitsunesoba wrote:
| > Mac OS ... seems to really expect you to manage windows
| by having them always be full screen and swiping between
| desktops. Which makes changing browser window geometry sub-
| optimal.
|
| That hasn't been my experience at all, in fact for me macOS
| works better when windows are mostly sized to fit their
| content. Windows and Windows-like Linux DEs is where I feel
| pressure to maximize everything.
| zetalyrae wrote:
| I have a 4K monitor and I have Wikipedia at 200% zoom at
| all times. It works fine and I prefer it to the
| alternative.
| PaulDavisThe1st wrote:
| It's not necessarily a function of the linux desktop. I use
| xfce, but it would be entirely easy to work with non-full-
| screen windows for my browser, emacs, clementine etc.
| However, I choose not, and use workspaces to spread things
| out.
| tasty_freeze wrote:
| I'm not saying you are wrong, but it is wrong for me. I have
| a browser with say 8 tabs open. When I switch between tabs, I
| don't want to have to keep resizing the browser geometry.
| zamadatix wrote:
| I was really hoping for a built in dark mode with the update. The
| mobile app is fantastic about this.
| nighthawk454 wrote:
| This reminds me of the Modern Wiki browser extension, which seems
| to have a lot of the same things but looks better to me at a
| glance. Also configurable, dark mode, etc.
|
| https://www.modernwiki.app/
___________________________________________________________________
(page generated 2023-01-18 23:00 UTC)