Welcome to our latest design update, Ars 9.0!

More good stuff. Personalization, responsive design, and more...

See full article...

 

[mdrejhon]

The list looks nice on my iPad. Unfortunately it remembers the Neutron view from my iPhone. I think preferences should beboet device, not per account.

Agreed. I often switch between iPhone, iPad, PC & Mac when reading Ars.
I also have a 45" ultrawide monitor, all the way down to a tiny 6" phone.
The power users (subscriptors) tend to have bigger variety of displays, probably.

I can get used to this new system, it will grow on me, on the condition of these three changes:

• Always only remember layouts per device.
• [EDIT: Seems to be Fixed!] Fix the comments bugs
• And the thumbnail circles instead of the thumbnail rectangles?
  Ditch the kitsch of the circles, or have a mode without them, I'd rather have the full thumbnail for all articles. If circles must stay, make them full height (same height as rectangles)

Give it a couple weeks for them to do the tweaks.

 

[mdrejhon]

I'm paying for the ad-free subscription, but it feels like I'm still getting the ad-blocker one you describe. I don't need the entire monitor filled, but this seems much more narrow than before.

I suspect subscriptors have a wider variety of monitors than the generic Analytics, too.

In fact, with a percentage of subscriptors, Ars might theoretically see heavier mobile use during commute hours and lighter non-mobile use during working hours, as one example, but still a wider variety of screen sizes by power users (a core audience that probably is more likely to pay for Ars)

For example, I have a 45" ultrawide on one of the systems I read Ars on.

So I have a variety of display sizes from 6" thru 45" too, and I like multiple density options including classic 1990s-density options too. I use GMAIL's "Compact" mode, even desktop, as one example.

Even though change is a bit disruptive to get used to an extent, I'm OK with the choices and can get used to it, although I wouldn't mind some tweaking/improvements, and especially a per-device memorization of preferred layout.

 

[mdrejhon]

[snip]

• Always only remember layouts per device.
• [EDIT: Seems to be Fixed!] Fix the comments bugs
• And the thumbnail circles instead of the thumbnail rectangles?
  Ditch the kitsch of the circles, or have a mode without them, I'd rather have the full thumbnail for all articles. If circles must stay, make them full height (same height as rectangles)

On my MacBook Pro M1, as one example display, default 100% Chrome zoom, full width maximized window, screenshot:

Circle Thumbnails Potentially Too Small In DESKTOP Layout

As an aging geek, with eyes not as good as before, early 50s now whereupon I first started reading Ars in my late age 20s, the circle thumbnails are too small and blurry to my eyes to understand the context:

[Secondary suggestion I noticed: This image isn't clickable by default when viewed in the comments ajax inline. Mayhaps, may you make clicking on embedded images load the original image? There's modifications for common forum and comment plugins to do that. Once loaded as a standalone image URL in a new tab or full screen overlay, that allows the user to use the browsers' existing zoom feature to inspect images, e.g. desktop screenshots more easily and comfortably inspected on mobile devices, etc]

If the circle thumbnails must be kept instead of going back to rectangles, maybe enlarge the circular icon thumbnails by 50% in diameter to help my aging eyes? Then they likely will easily grow on me eventually.

Suggested quick-and-dirty CSS change & aging vision rationale:

Spoiler

Make the icon height be the vertical bounding rect of the article headings AND the author/date underneath, not just article heading.

With potentially good test-audience ratings (especially among older geeks) -- make it the whole bounding rect height that includes the author and date (so the height dips downwards beyond just the headlight height)

There seems to be enough space vertically to grow circle thumbnail icon diameter by 50% -- between circles to do it without vertically spreading out the headlines nor feeling cramped. It would "tempt" my mouse pointer to click them more often too on the desktop!

I suspect some aging geek eyes would appreciate seeing thumbnails a bit better if you gotta crop the corners, to turn them more into icons, increase the surface area of the circular thumbnails if circles are kept?

It probably has a "it will grow on me" feel, but if possible, if you can throw a bone at least in the Desktop Layout (which also doubles as the iPad Layout) and at least increase the circle surface area significantly in the Desktop Layout, for aging vision accessibilitys' sake?

The asymmetry in surface area between small-diameter circles and large-dimensions rectangles, are a bit unbalanced. Even if there may be a young-test-audience rationale to continue do the circle icons in the smartphone era, but this is the Desktop Layout we're talking about.

I bet bigger % of subscriptors use bigger screens (and bigger variety) than non-subscriptors, whether 1% vs 5%, or 10% vs 30%, even if most readership is mobile. The "ahh, i will consume THAT gem of an article on the big screen" moments, eh?

I started reading Ars in age 20s, now I'm early 50s, and... This meet-halfway "accessibility-without-saying-accessibility" tweak might partially quiet the "I hate circles" audience too. Thanks!

 

[mdrejhon]

With my terrible image editing, this is something I think would work much better on widescreen desktops:

Spoiler: Proposed View on 5K monitor

View attachment 91783

While a probably niche view, this brings an idea:

I also have a 45" monitor as one of the screens I view Ars on. I wouldn't mind attracting more of the power user audience by a "Jumbotron Layout" view mode as an additional layout beyond Desktop Layout.

• Televisions
• Ultrawides
• 4K and 5K displays
• Certain people who prefer 100% OS DPI and browser DPI on large 1440p and 4K displays

Some people use their 48-55" televisions on their computer desks to view web content too from time to time. This may be a niche audience, like only 1-5% or less, but they might be subscriptor/geek overweight, a desirable audience to attract.

Pros/Cons about too many layouts in web developer guidelines:

Although web developer guidelines says too many modes can be hard to maintain, I currently have a specific lineitem small-change request about the Desktop View. If the existing Desktop View has to remain unmodified (unlike my suggestion), perhaps this new "Jumbotron Layout" view would be where some of my requests could be satisfied (instead), as a compromise.

Automatically responsive mode [DONE]:

Sometimes I use iPad 85% zoom or 115% zoom on a per-site basis to force it to load a preerred layout (two column layouts in tablet landscape mode), so it even adapts to the zoom ratio in Safari when viewing my blog. Thankfully Ars does this now; thank you! So everytime I rotate my iPad, I see Desktop layout in landscape, and a Mobile layout in portrait. This didn't work before, but Ars has improved this iPad screen-rotation experience. Obviously, this upgrade is overlooked with the perceptual downgrades of change, but some elements has improved on the iPad, as there used to be a lot more horizontal scrolling necessary on the iPad, and that has now been fixed.

 

[mdrejhon]

Niche? This is Ars. I have a 65" TV above and slightly behind the two primary monitors for background things. There's also two to my left mounted on the ceiling for testing other devices, a laptop display, and sometimes an iPad since that can be used as a display on a mac. A wall-mointed half-rack thrown in there. My husband only has four monitors. On one wall. The other wall has a plasma above a CRT for emulation. I am sure others here have far more absurd setups.

I was actually viewing it from an Analytics perspective. Whether Google Analytics or Cloudflare Analytics or whatever stats-collecting engine used...

Generic statistics analytics engine (without filtering subscriptors vs non-subscriptors) would probably have told Ars staff that 99% are viewing from mobile devices as aggregate, including people who search from Google and people who aren't subscriptors.

But the registered Ars audience and the paying Ars audience is almost assurdely geek-overweight, and big screens are probably not nearly as niche among subscriptors, the ones who loiter, the ones who commentator, the ones who already are subscriptors, and the ones who might be considering subscribing, the geek audiencepool that Ars prefers to recruit from, etc.

Even though subscriptors may still view from mobile 90% of the time, it's still less than 99% of a generic Analytics. This drilldown subscriber-layout-preferences data is very valuable to redesigning a site. The niche statistical differences of paying people start to pay for the bills.

I don't know what data Ars has, but I have been caught off guard by the statistical bias between members and non-members, since due to privacy reasons, generic Analytics data is not broken out in this granular level, and sometimes audience-attracting optimizations miss this. For this reason, separate analytics passes (within the confines of Privacy Policy) to get aggregate data from subscribers (differences in layouts used by subscribers vs non-subscribers).

____

Little Known Analytics Accidental Statistics Bias Anecdote (Creating Desktop Degrades):

Even 90% mobile vs 99% mobile means 10x more subscribers using desktop layout than mobile, so sometimes the tiny digits pays the bills surprisingly. It may not be that extreme for Ars, but it can be that extreme for certain desktop-gaming websites (aka geek-heavy websites), which is a capital example of Analytics bias accidents where registered members are more likely browsing from desktop sites percentage-of-time than the unregistered.

Deciding what kind of new-membership to attract is also a different redesign deciding factor. One example is (for me) look at how nicer (holding nose, barfing)... FoxNews layout looks is compared to CNN layout is, even though I prefer CNN (by a gigantic margin), although I prefer the "bias-detecting" Ground News app (boring layout, although due to bias-busting, even more important than layout to me).

ArsTechnica happens to be one of the few I bypass Ground News on. Now, one new worry I have for Ars is that the new layout (might?) attract more future subscriptors of the wrong kind of audience, because of (potential?) overreliance on generic Analytics data and how it's telling us (some big number) 90%+ or 99%+ visitors are now mobile and not filtering to how geeky/lucrative/etc the non-mobile audience is...

I run a geek-heavy blog and realized a potentially bias-inducing Analytics behavior (and amplified by important accessibility needs) as an insight from this, to make sure I don't blindly follow only the Analytics generics. Management sees generic analytics, and orders prioritization on mobile themes at the cost of desktop themes, causing [unexpected ugly effects / downgrade / enshittification / preferred-word] of some of my favourite tech sites elsewhere on the Internet...

So I learned to, to do supplemental research on the aggregate data of prosumer-use, in order to compensate for this accidental generic Analytics bias. Obviously a bit migeration from a dying geek pool where there seems to be no new subscriber signups, to get more subscriptor market is needed, but I think there's still plenty of more not-yet-paying geeks to recruit from too. Creating a Goldilocks from this is very tough, so I'm giving Ars a lot of slack here;

 

[mdrejhon]

If people are reading sites that they feel are optimized for widescreen monitors could you please link them?

I would be very happy to look at examples of what you feel uses a big wide monitor the way you would prefer. In my competitive landscape research of news sites (and I've looked at a lot) I did not see a single one, but that doesn't mean they don't exist.

Ars has never been "fill your whole widescreen 4K monitor". The previous designs didn't do it either. It's not a common thing for a reason, it makes for a poor reading experience. There are studies about text column width and what is ideal for reading. It's not something that just appeared everywhere for no reason.

But, if you have some counter examples, I would love to see them and see if there are ideas that we didn't think of, please feel free to share.

It's a bit more mudane and insidious sadly -- sites were never optimized for ultra widescreen.
It's a long-term change creep:

A decade (and two) ago many sites were optimized for things like, say, [slightly wider]x layouts and their retheme inched towards [slightly narrower]x layouts, over the course of two or three redesigns.

For example, some tech sites used to look better at 1920x1080 a decade ago, but are now less nice looking today on 1920x1080 because of responsive upgrades that made then look better on different screens.

I can't quite place a pulse on a specific research, but one of hundreds possible metaphor is sites were optimizing a reflow to ~1280x and inched towards ~1100x then ~1024x on the next two redesign cycles, but the current designer didn't remember the two-designs-ago.

Many tech sites (since the boom of iPhone and Android in the late 00's) have seen audiences migrate to mobile. Desktop layouts were very bad on those at first, and the optimizing job has helped improved many screens, albiet at the detriment of some of our favourite occasional screens. We often forget designs 3 designs ago, and most sites don't map the evolution over several designs, since we feel that 90% of things improved in a redesign. But do three 90%'s in a row, and it's more like closer to 90% x 90% x 90% ~= 65% approx (At least for that specific power user whose favourite layout was 3 designs ago for a specific screen). Obviously, most screens improved, but some power users do obviously die hard (ha!).

It's something that creeps slowly over a longer time period (one decade) thanks in part to the statistical bias effects I described. In other words, many site layouts more than ten years ago looked better on big screens than today's site layouts (even if they improved as an aggregate for mobile devices).

So along the way, something subtle got lost, e.g. even a minor change like the loss of a 1152x layout in favour of 1024x, or a loss of 1920x layout in favour of 1720x, or whatever. Something subtle and something evolutionary, driven by years of partially-generic research not specific only to tech sites.

It's poorly documented and researched, because it is one of the long term evolutions of the Internet, which is why reserch/articles about 20-year-timelines of site-evolution is pretty sparse currently, except on other more sensational topics (e.g. loss of print newspapers, enshittification, IE-vs-Netscape compatibility, etc).

This could be a new-territory research, for heuristically analyzing historical tech-site audiences, the exodus towards mobile browsing, the move to better accessibility/responsive standards, etc. There are times where 2 screen may have degraded, 4 screens improved, etc. And power users are very picky about (slight) downgrades on certain screens.

My general past big-corporate experience is it is sometimes a long-term statistics-driven pressure. People who run sites can only do our best given the data we have, and what data that companies (Analytics) decides to give to site owners.

The nutshell is that themes for big screens in the late 00's and early 10's sometimes looked better at certain browser widths on screens (even if we HAD to resize the browser (or zoom) just right to get the look we wanted), unlike a large number of themes today that reflow better to a larger number of screens, at the very slight (~10%) cost of downgrading certain users / big screens. Understandably so, but is amplified the most for tech-geek sites. The improved responsiveness improved the look of many screens, but not a universal unamious 100%.

People exaggerate when they say sites were (intentionally) "optimized" for widescreen years ago, when in reality it wasn't -- just that
(A) Either some sites dynamically resized to browser width (no column-width limiting) that is now the norm today
(B) or that the designer over 3 design cycles decreased the maxwidth by 50-100 pixel steps once every 5 years.
(C) or a combination of above;

But many sites did indeed "look" (preference-wise) better at wider browser widths for some power users, since they had the power to adjust their browser more easily back then than today (e.g. less Ajax to messup, or lack of maxwidth, or other 'flexibilities' that was abuseable). Slight change that creeped over years/decade, creating a trigger of vocal frustration/exaggeration, that has a legitimate etymology/cause...

However, it's an exercise that is particularly more-intense for the editorial staff of many old-tech sites, due to the
(A) Maturity and oldness of the tech site; and
(B) The geek-heavy subscribers of those specific tech sites; and
(C) Different programmers working on different design cycles; meaning the oldest changes from more than a decade ago, over 3-to-4 redesign cycles, aren't remembered by the most recent redesigner. Creating larger deltas between current design and several-designs ago;

The multi-decadal slowness of the layout-evolution (deoptimizing away from desktop-only), and the tech nicheness, means this is a poorly-researched topic, sadly, with few citations...

This may not necessarily directly apply to Ars but still "Useful To Know" for tech site staff, this is endemic to news-sites and more especially the tech-site universe as a whole. Ars has resisted (most) of it so far, where other sites do much more sudden jarring redesigns than thiss. So there is some kudos silver lining here -- that this redesign is less disruptive than the average tech sites' redesign from the statistical bias effects nudging each incremental away from specific power users' preferences.

After all, I run a tech site too...

 

[mdrejhon]

Aside.... Thinking ahead...

Right now, this is not the focus in today's current-stats-focussed race; but I had an idea:

Even as 90% of things may improve over one redesign cycle - the fact that "three 90%'s in a row results in only ~65%" should be an adage for sites that are now 25+ years old and trying to satisfy new audience / accessibility while preserving old grumbling greybeard geeks. Enough 90%'s in a row, and you've got less than 50% (for Old Audience)!

As the Internet hurtles towards 50-100 years old -- some of the Internet's oldest sites trying to survive, beginning next decade may need multi-decadal layout history databases to be visible to current layout designers -- to heuristically analyze for the purpose of attracting older audiences.

This was tough to do in the Netcape-vs-IE / pre-github / pre-AI-analysis era, but generating a retroactive database of layouts (of multiple sites) is now just a fraction of a day's job of just one employee now, and potentially a datamining endeavour to re-attract a number of additional old-readers / etc. Though attempting to advertise such an audience back is a tall ask, but that's left as an exercise of this said work. Something much faster to flipbook and datamine through than Wayback machine, more like flapping the pages of a book and/or seeing a 10-second morph of 20 years, etc.

A new archaeological task / field that is not yet tapped? Man, I still remember preferring some 90s-era blog layouts, and certain types of newspaper layouts, as one example!.

I must be exaggerating, Black Mirror style, but.... maybe a new field of work for some future digital-archaeology job fields to attract older audiences in the noise of generic Analytics data?

</random-brainstorm>

EDIT: IMPORTANT! Not to resurrect old layouts; just retroactive knowledge for future tech sites to help design new themes with minimum disruption to existing longtime users, etc.

Improving the venn diagram overlap where a redesign looks the way management wants, but slipstreams a lot of olduser-satisfying preservation cleverly, in a manner of speaking. Remember, most theme designers only remember 1-design-ago, not 3 or 8 designs ago, often by different staff, etc.

Consider also some of us change slower / more resistant to change, even some geeks are on the spectrum, etc. It's archaeological data-mining, once enough time has elapsed.

 

[mdrejhon]

I see sign in at the upper right corner sometimes when it thinks I should sign in.
When I click,
Sometimes my sign-in mysteriously looks like this:

Then the next screen is me actually signed in, as if it was automatic (i.e. suddenly realized I had the session cookie after all).

Perhaps it's a cached sign-in front page? If so, maybe make the Sign In popup "already signed in" aware, and display "You're already signed in", in the event that the sign in link is loaded while already signed in?

 

[mdrejhon]

I am still having extreme difficulties accessing Comments Sections now -- I had to refresh four times before I could access one section's posts. On several of my devices I still have the "undefined" in my Activity popup area.

Logging out and logging in helps, so I'll keep doing that, until it stabilizes.

 

[mdrejhon]

Hmm, I don't know what that would be. So now that I'm replying to you do you see that in your notifications instead of Undefined? It might not have populated with anything from before the launch.

After a lot of logouts and logins it's much harder to reproduce. It's mainly happened with pre-redesign-era cookies polluting my browser, so they were throwing he curveballs.

Today it's much harder to reproduce, as I have few pre-redesign-era cookies extant.

But there was a lot of this type of weirdness before my cookie-crushing and cache-clearing rampage:

 

[mdrejhon]

I've started hacking the CSS when reading articles on my 4k monitor via F12 tools. Locate <div class="relative lg:col-span-2"> and then change span 2 to span 4. This makes the text much wider.

@media (min-width: 1024px) {
    .lg\:col-span-2 {
        grid-column: span 2 / span 2;
    }
}

FYI to prevent hacking the CSS everytime you visit -- you can easily whip together a Chrome extension with that mod in just 30 minutes.

Tiny CSS-modifying Chrome extensions are literally merely Hello World sized.

You can edit an existing tiny Chrome extension (Hello World example) to inject this CSS everytime you're at specific URLs.

Sometime in the late 2010s I once made an accessibility extension to create a big-fonts mode for a transcriber website. It ended up being much easier than I thought; simply a bunch of text files I had to edit, didn't even have to write Javascript for such a simple CSS-mod.

____


BTW, I remember the old era where I could set article sizes the way I want simply by resizing windows to let its old text reflow fit. This is much rarer now, even if it was just a side effect of early web standards, and we just worked-around it by resizing windows to preferred text reflow. Most of the time, predefined and narrower text widths are better, but there are indeed times where I wished texts on sites were either narrower or wider.

Wikipedia, fortunately still has Wide mode, which is much wider, than most news websites.

This very ultrawide-flexible Wikipedia setting resurrects the old 90s-era / early 2000s era wrap-to-windowwidth mode favoured by some oldtimer geeks who want windowwidth to define their custom articlewidth.

Few sites do this anymore (it's undesirable to 90% of the population), but Wikipedia still does let you select it for the few who prefers this. Even stretches to the full width of my 45" ulrawide, if I wished, although I naturally habitually resize window to preference.

In other words the Wikipedia Wide mode is like a thousand different width settings (because of the thousand different window widths possible) -- a secret easteregg "Bring Your Own Width" setting, for old geeks, per se. Don't like our standard preset(s)? Just resize window merrily and get the width that you want.

A nightmare for newspaper layout designers, and for modern HTML5+ responsive fixed-grid layouts, but it is right up the Classic Web of text reflow to window width, usually mainly remembered by people who's been on the 90s era web, and by people of certain unusual accessibility needs.

Some of us coder geeks grew up with 132-column modes, old terminals, and extremely wide text presentation, and some old habits die hard... And, with Ars' oldgeek audience, it seems complaints seem a wee bit heavy especially with the 8-year elapse in web standards and best-practices. Obviously, this isn't the mainstream recommendation, but, the old audience tends to be fairly vocal. Sometimes we warred with the 80-column cops, merrily sticking to the minority of wider views, amplified by Old Web 1.0 standards and habits.

Spoiler

Also, while I do find narrow columns easier most of the time... That's not universally always the case. In a niche area, it had some undocumented accidental accessibility benefits, for people who found it easier to read long lines serially - less than 5% of people probably -- but some people have a tendancy to lose reading location tracking when moving eyeballs to the beginning of next line -- unless they put a finger on the screen (like a ruler to a line of newspaper), or scrolled slowly (like a ruler) to show the next line of text one at a time at bottom.

Grandma used to do that "ruler on a text line" technique even for narrow newspaper columns! Everybody reads differently and sometimes they require more reading processing (dyslexia issues, eye movement issues, etc) and may favour wider or narrower consequently.

...On the generic topic of accesisbility guideline documents: I noticed that some people resort to different accessibility features (sometimes designed-by-committee), such as VoiceOver, to get over various reading quirks.

As a deaf person AND a geek, I run into flawed Accessibility Recommendations documents all over the place, often desiged by a relatively small committee. Bias show up in various accessibility things we take for granted.

One example is I notice how some wheelchair users complain to me about the differences in yellow checkerboard textured tiles -- the parallel grids are easier to wheel over than diagonal grids (chessboard) -- on a manual wheelchair. This may have been subconscious bias in accessibility design by non-disabled people who creates Accessibility Guidelines that then just becomes accepted as industry standard...

So on this related subject, this very problem also often arise in many boilerplate web accessibility standards because it's designed often one-size-fits-many rather than accomodate-all.

Either way, there might be somewhat of an overlap between a wikipedia editor and an old-geek reader of Ars. This might be a case where hybridization of guidelines may be needed, or some minor oldgeek-satiating easter egg modes, in the next cycle of tweaks.

 

[mdrejhon]

After a lot of logouts and logins it's much harder to reproduce. It's mainly happened with pre-redesign-era cookies polluting my browser, so they were throwing he curveballs.

Today it's much harder to reproduce, as I have few pre-redesign-era cookies extant.

But there was a lot of this type of weirdness before my cookie-crushing and cache-clearing rampage:

View attachment 92248

Strangely, on my desktop MacBook, the weird "Undefined" apparently just happened again (despite this being a refreshed login / cookie):

This wasn't the case last night, so I wonder what's up;

I wonder if it's some kind of out-of-order cache expiry (e.g. 1 hour, 4 hour, 8 hour) or some downstream CDN request caching that is triggering some glitch?

Nontheless, a shift+Refresh fixed things right up.

(Just adding an additional data point)

 

[mdrejhon]

I assumed it would've been fixed so I held off, but maybe it isn't apparent to everybody (or is intentional, but please don't let it be intentional)..

The dark mode background color is off compared to the other colors; it's using a warmer dark variant while the rest of the dark colors use a cooler variant. It's driving me nuts.

rgb(22,21,18) as the page background with rgb(35,36,40) as the highlight background just looks awful to me on every one of my screens.

View attachment 92222

Just reversing the R & B in that is SO much better IMO (so it'd be 18, 21, 22).

View attachment 92221

As a person working on display tech...

I can inform that on two of my screens it's hard to see (first glance much ado about nothing), but on one of my wider-gamut displays at some profiles, I see the unbalance.

I don't know if this was a casual color picker action or if an intentional design choice, but casual color picking (on most non-localdimmed LCDs) has a way of amplifying subtleties on certain locally dimmed or OLED wide-gamut displays at certain gamma curves / tone maps.

The darker blacks of some modern displays seems to cause some display makers shift gamma curves and tone maps to make the intermediate dark shades show better, and the wider dynamic range often shows subtle color tints In grays much better.

So I seem to see subtle shades better whenever an HDR OLED is running in color-saturated SDR mode. (Alas, a default on many new OLED monitors, since he newness some of them dont yet have fully optimized SDR within HDR)

The color swap is harmless to the lower gamut dispalys (even I cannot tell on a quick glance), but your suggestion does indeed noticeably improves the wide gamut displays running in saturated SDR tone map modes. This may also conceivably apply when the person has a heightened color sensitivity.

For those without nextgen displays, QA/extended testing can be done by screenshot and then juicing the saturation in a paint app to see how it looks on saturation-enhanced displays and/or the ultra color sensitive.

So it's very display dependent, with a secondary effect by a human's color sensitivity.

 

[mdrejhon]

Thanks for including the logs, that's helpful.

Maybe I can help provide debug data on the "Undefined" problem?

I opened DevTools on a blank tab, opened arstechnica, no error, but when I clicked my icon, I got an error at the same time as Undefined. Allow me to share the error as a code block:

/civis/account/alerts-popup?_xfWithData=1&_xfResponseType=json&_xfToken=:1   
       Failed to load resource: the server responded with a status of 400 ()Understand this error

Corresponding screenshot:

Expanding the error shows this:

Opening VM37:9 shows this code:

(async function anonymous(__self,scope
) {
with (scope) { __self.result =
      panel = $el.parentElement.parentElement.parentElement;
      if (triggered || panel !== event.detail.panel) {
        return;
      }
      triggered = true;
      alerts = await (await fetch('/civis/account/alerts-popup?_xfWithData=1&_xfResponseType=json&_xfToken=')).json();
      // Set alerts count badge
      alerts_unviewed= alerts?.visitor?.alerts_unviewed?? 0;
      badge = document.getElementById('alerts-count-badge');
      badge.innerHTML = alerts_unviewed;
      if (alerts_unviewed > 0) {
        badge.classList.remove('hidden');
      } else {
        badge.classList.add('hidden');
      }
     }; __self.finished = true; return __self.result;
})

Any assistance I can offer on this probably worthy debug session?

<strange-theory>I know that strange edge cases can occur only occurs with distant CDN's because I have seen some companies miss in QA testing because of a weird edge case that didn't happen domestically but only happened distantly / internationally where there was some weird CDN issue when one thing is cached but the other is not, or something is cached-before-the-other. I don't know if this is part of it, just wildly speculating weird edge cases.</strange-theory>

EDIT, it happened again -- after I closed and reopened browser completely. Weird. In this run, I copied an additional error I forgot to copy and paste:

{
    "status": "error",
    "errors": [
        "Security error occurred. Please press back, refresh the page, and try again."
    ],
    "errorHtml": {
        "content": "\n\n\n\t<input type=\"hidden\" class=\"wpconnect_url\" value=\"https://meincmagazine.com/civis/account/alerts-popup?_xfWithData=1&amp;_xfResponseType=json&amp;_xfToken=\" />\n\n\n<div class=\"blockMessage\">\n\t\n\t\tSecurity error occurred. Please press back, refresh the page, and try again.\n\t\n</div>",
        "title": "Oops! We ran into some problems.",
        "js": [
            "https://cdn.arstechnica.net/civis/js/themehouse/styleswitch/global.js?_v=241fa251"
        ]
    },
    "visitor": {
        "conversations_unread": "0",
        "alerts_unviewed": "0",
        "total_unread": "0"
    }
}

 

[mdrejhon]

Wild longshot theories:

• FIrewall/CDN cached HTTP error codes and/or cached challenge pages.
• Secondary: Failure to run a challenge page, e.g. a challenge page can be unavailable for an ajax or inline image request (e.g. 400 instead of a challenge page)

Here's my anecdote during a site migration moving my websites between hosting accounts at the same hosting service. This can occur when you do this technique to make-live a major site upgrade too.

My website accidentally had a race condition between two CDN-type firewalls. Imunify360 vs CloudFlare.

My hosting service has an antimalware firewall that sort of doubled as a partial CDN or challenge-page provider or whatever interfered. But I also had CloudFlare paid plan too.

1. What happened was an asian user got a challenge-response in ideographic language (by antivirus CDN) and then CloudFlare CDN cached that damn challenge message.
2. A user in Brazil got this strange cached asian-language challenge message that was consequently traced to the antivirus CDN service my webhost service was using, and my CDN cached that other CDN's challenge message.
3. Ugggg.... Why would certain countries get wrong-language challenge pages?

After a lot of tracing...it was an Imunify360 challenge page that was cached by CloudFlare. So a firewall-vs-firewall interaction.

Same thing MIGHT happen to HTTP error codes getting cached temporarily.

With the dangers on the web, host providers start adding more protection (including antivirus/antimalware things) we frequently run into chained CDN, that sometimes.... catches somebody else's HTTP error code (missing page, bad redirection, wrong 400 status code, etc), and it ends up getting served randomly to other people.

I wonder if it this sorta strange thing is also happening here? Probably not... but it was one of the hardest staging->production debugs!

An example is the Imunify360 / Webshield hosting-service firewall, which occasionally created a problematic interactions with aggressive cache-expires settings at CloudFlare. Challenges by a firewall can be cached by a downstream CDN, and possibly cached HTTP error codes too (at least temporarily). I fixed it by forcing CloudFlare to respect my sites' original HTTP's expires headers, rather than overriding them, and that fixed things right up (after half an hour later, when all the bad cached stuff expired).

Maybe this is not the problem, but in this Advanced Web Protection era, we have new weirdnesses when running sites. This makes production pre-testing harder since this is not currently debuggable in staging because we don't have a 100-country fleet of beta testers intentionally trying to get the firewalls & CDN's to glitch one-in-a-thousand behaviours. Ugggg.

Related:

Since the damage was already done; one form of self-recovering practices is letting all the antivirus and CDN's respect the sites' original expires headers that was blanket site-wide. In this sense, the next HTTP request to hit my site, automatically cache-busted the earlier bad cached stuff at all other URLs at my site (eventually -- at least over the course of half an hour). Learning 202 Advanced Cache Busting, a skill I didn't think I need to learn. To do so, I had to disable all the cache-expires overrides any firewalls or CDNs were doing, and let my .htaccess have control over that specific element. CDNs can still cache, but the original browser cache expires headers were now respected. Eventually, that cache-busted all the bad challenge page cached earlier, over the course of the next half an hour. Remember, for Google SEO, some of my headers allowed the browser to cache static content for a whole week, which was tough to cache-bust -- I even let the browser do a full week cache of some known static .html files (longtime old pages are unchanging), and unfortunately the same URL was instead the challenge page cached at CloudFlare that also did the cache expires header override.

Even when the CDN fixed itself, the weeklong browser cache kept loading the browser cached challenge page. So browser locally cached a CloudFlare cached challenge page originally emitted by a Imunify360 antivirus firewall. That's why the Brazilian user saw a weird chinese challenge page that would not go away even after non-shift-refresh, and after I force-flushed the CloudFlare cache. The most difficult thing I had to cache-bust; once the user visited a different URL of the same site, it cache busted everything, and then going back to the original URL worked....

Hopefully this isn't a wild goose chase, but "Undefined" disappearing when going to a different part of Ars (possible cachebust behavior), and going back to the same page, Undefined disappearing. So I wonder, if a loosely roughly similar weird cache interaction is happening, even if not identical. it was one of those big-time "production-only bugs" that totally stumped me for days.

This 2020s-era glitch is definitely not something you normally encountered in the 2000s or 2010s.

 

[mdrejhon]

I assumed it would've been fixed so I held off, but maybe it isn't apparent to everybody (or is intentional, but please don't let it be intentional)..

The dark mode background color is off compared to the other colors; it's using a warmer dark variant while the rest of the dark colors use a cooler variant. It's driving me nuts.

rgb(22,21,18) as the page background with rgb(35,36,40) as the highlight background just looks awful to me on every one of my screens.

View attachment 92222

Just reversing the R & B in that is SO much better IMO (so it'd be 18, 21, 22).

View attachment 92221

In my case, I'm able to replicate on all my displays: My color-calibrated ancient Dell monitors, my somewhat older but newer than the Dell gaming monitor, and even my cheap-ass System76 Darter Pro's screen

It doesn't help that I am super color-sensitive; always have been (was great back in the old CRT days - I calibrated monitors by hand at the newspaper I worked at), and I tend to forget that not everybody sees colors like me.

I am way more motion-sensitive than color-sensitive, so I'm a lot slower at adopting wide color gamuts and HDR than adopting high refresh rates. But it's nice that I can have both HFR and HDR together now.

For any site designers at Ars, here's a color-sensitivity-amplified version of your screenshots (achieved via extreme saturation adjustment in a paint program to simulate color sensitivity and/or wide gamut displays amplifying subtle shades).

Saturation-amplified, plus a brighten, for web developers working on most common LCD displays / more subdued photoshop calibrations / etc -- to amplify effects seen by either color-sensitive people like you or by certain displays that stretch SDR gamut to HDR colorspace in default settings.

Ironically, I can't see it on most Mac displays (iMac 5K, MacBook M1 LCD, etc) but I see it on an OLED attached, in its default oversaturated mode during SDR. It definitely looks better in this case with the RGB's swapped. Probably a harmless change given it only affects certain people and/or certain displays.

Apple does indeed calibrate the SDR subset on HDR pretty well, but this isn't consistent across all screens.

 

[mdrejhon]

On sites which flow text I adjust my browser width to something comfy for me. Which can be wider or narrower than for other people.

Narrower is usually much nicer, but it's not a universal comfort preference.

Some researchers (I think someone named Dyson in a mid 2000s paper) in a study of screen reading, found out that some users prefer wider columns on screens at the time, because it depended on individual reading styles.

Some speed readers were longtime trained on long serial lines, and could read wide columns faster because they were trained that way (much like someone was trained on a DVORAK keyboard or such).

I prefer medium-width layouts, but I often like to use Wikipedia's Wide setting and resize the window accordingly to suit preference. The site I have, however, does use a narrower line length but still slightly above average (and still wraps if you narrow browser window width).

EDIT, found the paper -- written by Mary C Dyson in year 2004. (Not to be confused with the famous Esther Dyson)
"The results showed that the number of characters per line affects reading rate with the longest line read faster" (text at end of page 6, or page labelled 382, since it was a part of a larger journal).
However, most users preferred the comfort of narrower columns.

(Aside: Incidentially, the paper covers speed readers. That's damn interesting about speed reading! Did not know that. I'm a longtime speed reader benchmarked with a reading speed of 800 words per minute, and my farsightedness afforded more peripheral vision, so this may have influenced my line length preference. Comfort reading and speed reading are two different things, creating different preferences. I definitely find narrower columns more comfortable but I also always noticed it hindered my reading speed from my specific flavour of speed reading training in past. Comfort-vs-speed aren't often co-existent guidelines. This clearly explains why I read faster with wide text due to my old-era-speedreading training techniques).

Newer modern speed reading training techniques sometimes use short replacing-in-place text instead, and makes you read faster on narrow screens (e.g. phone speedreading apps). But old desktop speed reading systems (1990s era) used long lines, so possibly that is where some of my yesteryear geek speed-reading training came from.

Clearly an exception to the rule, but understand why Wikipedia (while default to wrapped lines), offers optional wide modes, and some other sites like mine don't do that but still offers a slightly wide mode optimized to fit the width of 800x600 tablets with only slight margins at 100% scaling, basically optimized to look nice and full without much whitespace at 800x widths. Makes it nice to have ads at 1024x widths and beyond, or scaled 1920x widths. (Although an obsolete SVGA mode, some tablets report 800x, and it just looks nice with two side by side browser windows, and will responsively narrow nicely if you resize narrower)

That being said, I do NOT like Slashdot's godawfully ugly default wide approach myself (agree with Aurich), but am glad that Wikipedia's compromise of optional wide mode exists (agree with Wikipedia) as if I don't like the width, I can simply temporarily toggle that quickly in just two clicks.

 

[mdrejhon]

(Fair fair, just trying to scientifically trace why I, and some other geeks, a slight aberration to the rule)

Did you fix the Undefined? The Ars undefined seems gone for me on all my devices today, but the litmus test will be an overnight test -- since my first visit to Ars after a long device idle, seems to be a contributory cause.

Supplemental datapoint:

IIRC, it seems to only happens if my first action of the specific browser in the morning is clicking my profile icon, so I'll repeat that tomorrow and report back if the Undefined comes back. Especially in a long-idle tab. Since surfing the site by several pages first seems to fix it automatically, making this problem not-noticed by all. This may be why it probably affects the most eager forum-posting subscriptors worse than the average site-surfer.

 

[mdrejhon]

I got it now too. Chrome on a Pixel 8.

(Currently digital nomading around, so subjecting myself to things like IP address changes and intermittent hibernates / resumes on existing tabs)

I am getting them again on both mobile (iPhone 14 Safari) and desktop (Chrome MacBook) after letting my sessions sit around long, and revisiting tabs already cached by Chrome, etc.

I have published a fair bit of additional debugging information in this post including the security warning.

I often see correct notification numbers show up (e.g. "1" or "2") for unread messages, but that doesn't help the Undefined part. So clearly, part of it is working, and another part of it is not working.

It seems that, one (semi-reliable) method to reproduce might be:
1. Have two devices concurrently logged on, that both goes idle for a while. (Not sure if this step is necessary)
2 Simply close your laptop lid with the existing tab, or Airport your mobile,
3. Come back in an hour, and then let it connect to a highly different network (e.g. domestic WiFi versus LTE hotspot or a roaming eSIM or a VPN). Things like even merely Holafly eSIM roaming (which turns your IP address suddenly into an European one even if you're roaming the Americas) before un-minimizing your browser.
4. Immediately visit your already-logged-in meincmagazine.com and click the icon first thing you do at Ars (Don't surf around first).

I wonder, in a speculation way, if unexpected 'suspicious' IP country changes in the same SID is triggering the security console message. One moment I can be on a Canadian wifi, the other moment I can be on a roaming Americas eSIM that emits an Europe IP. Like a defacto VPN but isn't detected as a VPN.

These geolocation-quirks might hypothetically do security false positives with these kinds of rug-yank-under-feet IP address churn of switching between WiFi/hotspots/land Internet. The combined timeout+geolocation+carrier NAT combo might not be the cause of security false positives, but I wonder if it's a contributory cause.

 

[mdrejhon]

As I noted in that thread we're dealing with a freaking second hurricane, and really hoping this one won't affect Jason as much. But I have to ask for a little patience, his safety and taking care of his family will always be a priority over adjusting the site if the weather doesn't cooperate.

Godspeed and good luck...

Two recognizable >1M YouTubers just had their house destroyed (one was a fallen tree that destroyed part of the studio) and is having to pause their channel for now. One of them is LGR (house destroyed video) a retro youtuber with 1.7M subscribers.

 

[mdrejhon]

Display error report, Safari Version 11.1.2 (13605.3.8) on a MacBook Pro running MacOS version 10.13.6 (17G66):

Holy, that's an old version, MacOS High Sierra is almost EOL for security updates.

Understandably, I see Aurich already de-prioritized, he has too much to focus on.

To increase odds, maybe include developer console logs. In addition to my M1 MacBook, I have an old but still usable MacBook Pro 2015 too, but I haven't spun it up recently. If it is a very obvious one-typo ES6-compatibility quirk, then an easy fix if it's not part of an external framework, or can be quickly transpiled to an older-compatible javascript (e.g. "babel" tool). Some are just 1 line easy fixes, especially if you attach the full console log that shows the obvious fail.

BTW, I'm no stranger to debugging really weird old-browser compatibility quirks. Formerly, I needed my site to be compatible on really old streaming devices (including 2010-dated devices!). My old cutoff line used to be IE6 (then IE8) until a few years ago, but my new cutoff line is now ECMAScript 2015 (ES6). I try to keep a rolling ten year compatibility window, but only because of necessity for me.

Majority of Wordpress, forum, and plugins, all currently usually target ES6 as baseline in 2024.

I checked.... In theory your browser should still be ES6 compatible, and should still be supported as a best-practice. A common ES6-compatibility scanner is part of my QA suite now, and for those smaller hobby indies using AI coding chat assistants can also accomodate "is this code fully ES6 compatible?" queries.

___

I don't know if Ars staff uses it, but I wanted to share some useful timesaving info:

Most of us don't have the time and retro-needs to churn up a BrowserStack subcription to test old browsers (a VM that autolaunches your website into any version of old browser you dream!) -- a luxury I only do occasionally. But BrowserStack is a big timesaver in ES6 compatibility testing for me, at least on a once-a-year basis. I am discontinuing my last Windows 10 machine soon (EOL problem) going all Win11 for the PC-side of things. So all that rolling-ten-year-compatibility tests will now go to VMs, and BrowserStack is easier than installing your VM because they have hundreds of boilerplate old OS VM + old browser VMs!...

BrowserStack is a veritable Netflix of old-OS old-browser VMs.

A snapshotted cloud VM almost instantly launches your URL. Perfect for compatibility troubleshoots. I only casually use it once in a while though, essentially Free Trial + temporary subscription (it was $39 for one month in the month-to-month mode).

I don't use the automated testing APIs that big companies use BrowserStack for, but sometimes I need to launch my site in one OS and browser, and quickly see its developer console output, to understand what my site barfed there. Seeing log output on an obscure device in less than 1 minute can be priceless to saving time.

One day's of instant live use was well worth the one-time one-month fee for me! I didn't bother with mobile because of of a desktop-troubleshoot (mobile-included is another 10 extra). It has bunch of goodies such as Accessibility checker (Accessibility Testing subscreen), ES6 checker, automatic capture of stuff logged to developer console, etc. I don't have time to properly milk it, but even 1-day of live fast non-queued usage was lovely peace of mind. Over 3000 operating system and browser combinations displaying in less 5 seconds apiece, but I only needed to play with a dozen.

 

[mdrejhon]

Hey I get it, you need those ads and I respect that, but see my earlier post requesting for text to flow AROUND the ads.

I run a site.

Let me add technicals to Aurich "seems dumb" perspective. I concur!

One big problem is the limitations of ad networks and APIs. It's downright annoying to optimize a responsive site around non-responsive boilerplate add templates, and I've had many head banging on desk moments, with a nice side helping of picard facepalms. Some of the decisions made by ad networks are downright byzantine but also has some legacy roots (e.g. support for really old browsers).

The pick-poison game of funding the costs of running a website... Be sheep and play the game the ad network obligatorily requires you to, or devote double-digit percentage of your business manpower continually trying to be your own homebrew ad network with fickle advertisers, or find another way to fund the costs of operating the website... Which devil do you hold your nose to & choose to sign your soul to, indeed!??!!1!!

Big clients like General Motors or Dell Alienware prefer to buy ads from the ad network, and your plug-n-play autobidder ad network script (from the ad network you chose) will place the highest-bidder ads on your site, automagically behind the scenes. This is the easiest way for limited-resources websites to get paid more to advertise. The ad network gets a cut, and you get the rest. The best ad networks with the highest pay for the least intrusive ads, get the most indie clients, while the other money-milker websites will liberally enable all intrusive ad options.

Instead of truly custom ad sizes you choose, you generally can only do things like filter categories (no casino ads, no adult ads) and reject certain formats (e.g. no dockable ads), but then you're signing away blank billboard space on your ads -- you can choose insert points and such, but the parameters are quite square peg in round hole. It's often, "Here. This ad network is providing this ad in this size, no scaling allowed, display it in full or else." after your page has already loaded & not allowed to detect its wrongly-provided size (because it's deep inside another ad networks' IFRAME, due to cross-origin security andboxing).

Some dumb inefficiencies occurs when ad networks embed ad networks that embed ad networks. You can have a third party ad network that includes multiple networks including Google Ads, which then also sometimes loads other whitelisted partner ad networks, and so on... This can mean you've got 4 levels of nested IFRAME's before the actual ad loads. How are you going to autodetect the size of the ad downstream if it's a smaller ad in a fixed cube (e.g. mobile ad loading in a desktop site because you loaded on an iPad, etc...). Site owners are always trying to switch between ad networks to either (A) have more options to design the website around and/or (B) earn more money.

This means there is no guarantee of being able to responsively adapt to size, especially if the ad bid occurs 3 seconds later (after your article has already loaded fast due to speed affecting good SEO). Banner ads as horizontal rules between article segments is doable, but reflow around ads side by side is extremely tough even for those sites that actually spend lots of programming to make it possible.

On top of it, the ad networks are also enshittifying themselves, sometimes without clearly explained consent to us site owners (except that TOS spew), in switcheroo games. And sometimes we have to rewrite our site to get rid of an ad network we now hate (E.g. switch ad networks can sometimes be painful)...

I freaking don't have time for it either, being at ransom for site operational costs to tolerate looser ad priveleges (how dare you attempt to do more tracking of my site visitors than yesterday etc etc etc).

Being hobby-turned-biz, I understand hobbyist disdain for ads. But also understand siteowner need to pay operational costs. The ad-vs-siteowner sometimes feels like cat and mouse game, to keep the ads at a Goldilocks level, without sabotaging too much cashflow, etc. Even to this day, I refuse to add ad networks to my most popular site (the ad-free motion testing site) even though it would more than quadruple my ad income (in theory).

Rated 4 out of 5 Picard Facepalms

P.S. Web Ad Trivia; Did you Know? Some interesting exercise, every site with ad network always has a public /ads.txt file listing authorized advertisers. Load your favourite website and add /ads.txt such as www.cnn.com/ads.txt or www.foxnews.com/ads.txt or www.meincmagazine.com/ads.txt ... Some of those are obvious big ad networks (e.g. Google Ads, Facebook Ads, Amazon Ads) while others are individual advertisers (direct bidders) or smaller ad networks (e.g. nextmillennium).