Couldn't actually read for very long. The content scrolling over the static background image gave me motion sickness.
The 1980s theme was the only one I could stand, and the 1990s theme appears to be the same as the Tropical Days theme. All the ones with the background are essentially unusable for me.
It's their site, they can do whatever they want, but it's a bit silly to act like there's something wrong with anyone who has a problem with it. For example, in the default theme the yellow text (#FFFF00) with the pink highlight (#FF00FF) fails WCAG contrast requirements across the board.
Maybe the really don't care whether everyone has an easy time reading their site or not, and that's their choice, but I find the snark about it off-putting. It's not difficult to design a site that's easy for everyone to read.
> But anyway, most of the material published on our research website is also available in gemtext format via our gemini server.
Same. I think this is one of those things where they were having some fun, and then some people on the Internet overreacted with great hyperbole, and so they're issuing this response to those people, but I'm sitting here reading it and it feels aggressive, and I think, "Wait, what did I do? I'm just sitting here not bothering anybody", and it begins to feel like a low-level conflict. I think a lot of internet discourse is like that, unfortunately.
Aye. Big "we have a developer that knows CSS" vibes, rather than "we have a designer" energy. Feels like someone should have told them the pitfalls of chasing a design that was hand-crafted for a specific format (print media; magazines, specifically), or at least why the choices that were made for that medium were made, and why they may cause issues in this medium. For that kind of stuff, though, you need someone who has a deep knowledge of design, rather than just a high skill at implementing designs.
Of course, with such an obviously high skill at design implementation, they did plenty enough to be perfectly fine for most use-cases, so it's hard to be too hard on them about any of their choices. Everything works just fine. And to ignore complaints that ignore your design choices is a fine disposition, as well! No reason to bother with people who aren't interested in your vision and don't contribute.
But to snark about the complaints, as if there's nothing you could do better? Smacks of an aloofness that is an off-putting characteristic for an organizations purporting to do research.
Lol, this is the first website in a long while that made me feel sick after scrolling for a while. I need to show this to the folks in office and see who pukes or wipes their head.
Looks like we need to "seek professional medical advice"
On Firefox, you can just prepend "about:reader?url=" to any web page and you get the plain-text reader view. There's apparently a config setting in the userChrome.css file to make reader available like this on all sites.
That's a good point, and a good tip for when Firefox doesn't prompt it automatically. I'd forgotten entirely about reader mode on Desktop, I do use it all the time on mobile though.
>>Arghhhh! Your pages give me a headache, and/or eyestrain.
>Stop using the site immediately and consult a qualified ophthalmologist.
Seriously, no static display on a modern and correctly adjusted VDU such as a computer monitor or phone screen should ever be inducing headaches or eyestrain in a healthy individual when properly used for reasonable time periods, and with sufficient breaks.
If it is, you may have an underlying health condition which has otherwise gone un-noticed.
this statement basically implies that you have no intention of creating a website that is accessible to all users, and to all of those users with cognitive, vision, or neurological issues: "tough luck, go see a doctor!". Though I understand the goal here in terms of style and this page is indeed WCAG friendly enough in terms of some of the most obvious success criteria- this website is an objective nightmare for those with a variety of cognitive disabilities.
I find it wildly ridiculous that we've more or less abandoned the practically simple idea of "the web is text, so just let people render the text how they want in their browsers."
Yet another reminder of the overblown nature of UX/UI in general. Given the current push for accessibility, seems like "make the text accessible" should be the goal above all else.
The way a lot of people experience "the web" is not primarily text, but instead compressed screenshots of text. And screenshots of screenshots, ad infinitum.
I have to admit, there's a lot of crap on this page. But...
They do provide reasonable contrasts for all text on the page.
The text is a reasonable size.
Which is honestly better than most websites, especially technology sites.
That said, it would be nice if they supported readers though, or directly linked to their "gem text" (pure ascii) site. Putting blame on the browsers for the site's design choices is lazy.
Actually, a site that is structured well enough to be usable in text mode browsers is already more accessible to all users than most of the “beautifully” designed examples.
There's a different kind of incapacity involved: incapacity to control your device and software to have them suit your needs. The reply assumes that user has no other option except to drool and stare at what website author chose.
this generally isn't how designing with cognitive or neurological disabilities in mind works, we don't want the user to have to make adjustments in order to use a website as this only creates more friction. Not to mention the fact that we don't assume that the user is knowledgeable on how to make those adjustments, especially with the senior population which is a large segment of the cognitively impacted population who are using the internet.
unlike with the blind or low vision population, those with cognitive and neuro issues often aren't aware of assistive tech, often aren't familiar with the accessibility settings on their devices, and sometimes aren't even aware of the disability they are dealing with and are undiagnosed.
I absolutely hate this. Viewport width has nothing to do with DPI and should not affect the font size. I didn't get a larger monitor just so that everything can waste more space with giant text.
> I didn't get a larger monitor just so that everything can waste more space with giant text.
That's what the outer min() is for: it makes sure the font size caps out at 1.3em which usually translates to 16 x 1.3 = 20.8px, which is well within the recommended size range for prose anyway.
What that whole snippet does boils down to exactly what they said in the article:
> The main global stylesheet uses the browser default font size, smoothly scaled up to 130% on higher-resolution displays as the baseline for the body text of the whole document.
On a low-dpi screen, nothing changes. On a high-dpi one, if you haven't set your browser text size to something larger, this snippet saves you from tiny unreadable text. Also note that ctrl+ and ctrl- to zoom still work just fine. It's not as dramatic a change as the sibling comment said. You can try it out on their site to see for yourself.
That's the thing. These hacks alwways end up negatively impacting some edge cases. I found a site once that used JS to autosize the text... as a result you couldn't manually resize with ctrl - and ctrl+.. It's better to stick to standards
I don't see any issues with this particular code (although for larger sizes, there may be an accessibility issue related to zooming). In general, I would recommend avoiding the use of vw-only units because the computed value may not change with zoom.
I would only use this kind of thing on the root element, then size all other elements relative to the root element e.g. h1 { font-size: 1.5rem; }. It's more manageable that way IMHO.
Design proof that being "unique" doesn't mean "good".
I'm certainly glad they like what they've built. But it breaks a lot of design concepts that help with UX (some in micro ways that aren't really noticeable without the aggregate effect). The "max character width" is a really valuable thing for "readability". But why bother with learning design when you're using all of the TECHNICAL specs 'exactly as specified'. Why bother with design responsibility when you're already absolving yourself of technical responsibility ('it should not be our job to work around bad tech...').
Of course, the most galling thing is that they're not actually using the spec, as it is specified. Using `section` tags everywhere is inappropriate. They are meant to break up content in the `article` tag.
But, okay, whatever; you're going to cling to the spec but still ignore the parts of it you don't like. Fine. Like they said, it's not causing screen-reader issues, so who cares, right? Except that they ALSO don't use the `header` tag within those sections to denote what is clearly a header. Not a "heading" (h1-6, used for breaking up paragraphs in articles), maybe, since it's not in an article and that can cause funky screen-reader performance, but there's no reason to NOT use a `header` tag. This use case is literally what it was made for; giving a generic header that you can style and make accessible on your own. So why use a `section` tag erroneously, but then eschew using the `header` tag for the exact purpose you need? (why use it? screen readers/accessibility)
Nothing in this seems like "well-considered design". Rather it seems like "good enough, and how I like it." Which is a perfectly wonderful way to design and run a website! It's just kind of shitty to then go write an entire article telling anyone who misunderstands your uniqueness for a different flavor of uniqueness that you are actually doing everything exactly right and that anyone who dislikes your site should take their "problems" elsewhere. A fine enough attitude, if you're in to that kind of gatekeeping, but I've never found it compelling or endearing.
> It's just kind of shitty to then go write an entire article telling anyone who misunderstands your uniqueness for a different flavor of uniqueness that you are actually doing everything exactly right and that anyone who dislikes your site should take their "problems" elsewhere.
This site eats about 50% CPU on Firefox (on an older laptop) for every page that is open at the same time, and it continues to eat 50% after closing all pages. It doesn't use JavaScript and no visible CSS animations, so what is it? Apparently, the favicon! Which, as explained on the linked page, "is SVG, (with S.M.I.L. animation)". Since the favicon is still listed on the list of favourites on the browser start page, it continues to eat CPU... until clearing the browser history.
- On edge on linux (yes) cpu process usage increase as well, but not as much.
- On chromium cpu usage do not evolve but it is not animating the favicon.
If you want to disable it on firefox and are using ublock origin, you can do so by going to the ublock origin dashboard --> My Filters and add the following line:
That's it, I've completed the Internet. This is my new favorite page. The aesthete in me may bristle, but the pragmatist agrees. There are many ergonomic and UX concerns to consider when designing things, but I think they make their case very well and I didn't find it a problem to read at all.
There are various themes and it works well on mobile and doesn’t look like every single other website out there today, so I count it as a win.
It’s kind of how so many LaTeX documents look the same because nobody bothers to design anything; the inverse problem from Word where things are too easy to change.
Readit News
The 1980s theme was the only one I could stand, and the 1990s theme appears to be the same as the Tropical Days theme. All the ones with the background are essentially unusable for me.
It's their site, they can do whatever they want, but it's a bit silly to act like there's something wrong with anyone who has a problem with it. For example, in the default theme the yellow text (#FFFF00) with the pink highlight (#FF00FF) fails WCAG contrast requirements across the board.
Maybe the really don't care whether everyone has an easy time reading their site or not, and that's their choice, but I find the snark about it off-putting. It's not difficult to design a site that's easy for everyone to read.
> But anyway, most of the material published on our research website is also available in gemtext format via our gemini server.
Might be the only way I'd read this site.
Same. I think this is one of those things where they were having some fun, and then some people on the Internet overreacted with great hyperbole, and so they're issuing this response to those people, but I'm sitting here reading it and it feels aggressive, and I think, "Wait, what did I do? I'm just sitting here not bothering anybody", and it begins to feel like a low-level conflict. I think a lot of internet discourse is like that, unfortunately.
[1] https://twitter.com/dbrand/status/1626716812128952320
[2] https://twitter.com/Ryanair/status/1569268623235231748
Of course, with such an obviously high skill at design implementation, they did plenty enough to be perfectly fine for most use-cases, so it's hard to be too hard on them about any of their choices. Everything works just fine. And to ignore complaints that ignore your design choices is a fine disposition, as well! No reason to bother with people who aren't interested in your vision and don't contribute.
But to snark about the complaints, as if there's nothing you could do better? Smacks of an aloofness that is an off-putting characteristic for an organizations purporting to do research.
Looks like we need to "seek professional medical advice"
Some sites have it in the address bar, but I've never found any documentation from MS that makes it clear how to ensure that it is always there.
It's so easy to make a site that is accessible - a blank HTML document with no CSS essentially is. It takes work to make a site that isn't.
>>Arghhhh! Your pages give me a headache, and/or eyestrain.
>Stop using the site immediately and consult a qualified ophthalmologist. Seriously, no static display on a modern and correctly adjusted VDU such as a computer monitor or phone screen should ever be inducing headaches or eyestrain in a healthy individual when properly used for reasonable time periods, and with sufficient breaks. If it is, you may have an underlying health condition which has otherwise gone un-noticed.
this statement basically implies that you have no intention of creating a website that is accessible to all users, and to all of those users with cognitive, vision, or neurological issues: "tough luck, go see a doctor!". Though I understand the goal here in terms of style and this page is indeed WCAG friendly enough in terms of some of the most obvious success criteria- this website is an objective nightmare for those with a variety of cognitive disabilities.
Yet another reminder of the overblown nature of UX/UI in general. Given the current push for accessibility, seems like "make the text accessible" should be the goal above all else.
They do provide reasonable contrasts for all text on the page.
The text is a reasonable size.
Which is honestly better than most websites, especially technology sites.
That said, it would be nice if they supported readers though, or directly linked to their "gem text" (pure ascii) site. Putting blame on the browsers for the site's design choices is lazy.
There's a different kind of incapacity involved: incapacity to control your device and software to have them suit your needs. The reply assumes that user has no other option except to drool and stare at what website author chose.
unlike with the blind or low vision population, those with cognitive and neuro issues often aren't aware of assistive tech, often aren't familiar with the accessibility settings on their devices, and sometimes aren't even aware of the disability they are dealing with and are undiagnosed.
Deleted Comment
spotify, steam, epic and many more.
big diff between profit/trend driven design and philosophical/practical design.
This is going to be the default font-size for all of my websites now (preceded by a fallback for maximum compatibility of course).
That's what the outer min() is for: it makes sure the font size caps out at 1.3em which usually translates to 16 x 1.3 = 20.8px, which is well within the recommended size range for prose anyway.
What that whole snippet does boils down to exactly what they said in the article:
> The main global stylesheet uses the browser default font size, smoothly scaled up to 130% on higher-resolution displays as the baseline for the body text of the whole document.
On a low-dpi screen, nothing changes. On a high-dpi one, if you haven't set your browser text size to something larger, this snippet saves you from tiny unreadable text. Also note that ctrl+ and ctrl- to zoom still work just fine. It's not as dramatic a change as the sibling comment said. You can try it out on their site to see for yourself.
I learned this from https://adrianroselli.com/2019/12/responsive-type-and-zoom.h...
Thanks for the tip on clamp() by the way, TIL.
This is a good write up of using clamp and fluid type
The only mysterious parts of the expression are how the em and wv units work.
I'm certainly glad they like what they've built. But it breaks a lot of design concepts that help with UX (some in micro ways that aren't really noticeable without the aggregate effect). The "max character width" is a really valuable thing for "readability". But why bother with learning design when you're using all of the TECHNICAL specs 'exactly as specified'. Why bother with design responsibility when you're already absolving yourself of technical responsibility ('it should not be our job to work around bad tech...').
Of course, the most galling thing is that they're not actually using the spec, as it is specified. Using `section` tags everywhere is inappropriate. They are meant to break up content in the `article` tag.
But, okay, whatever; you're going to cling to the spec but still ignore the parts of it you don't like. Fine. Like they said, it's not causing screen-reader issues, so who cares, right? Except that they ALSO don't use the `header` tag within those sections to denote what is clearly a header. Not a "heading" (h1-6, used for breaking up paragraphs in articles), maybe, since it's not in an article and that can cause funky screen-reader performance, but there's no reason to NOT use a `header` tag. This use case is literally what it was made for; giving a generic header that you can style and make accessible on your own. So why use a `section` tag erroneously, but then eschew using the `header` tag for the exact purpose you need? (why use it? screen readers/accessibility)
Nothing in this seems like "well-considered design". Rather it seems like "good enough, and how I like it." Which is a perfectly wonderful way to design and run a website! It's just kind of shitty to then go write an entire article telling anyone who misunderstands your uniqueness for a different flavor of uniqueness that you are actually doing everything exactly right and that anyone who dislikes your site should take their "problems" elsewhere. A fine enough attitude, if you're in to that kind of gatekeeping, but I've never found it compelling or endearing.
"Am I so out of touch?
No. It's the children who are wrong."
-Seymour Skinner, "The Simpsons"
That aside, yes, I was wrong to use it like "[...] in the `article` tag."; well spotted.
- On chromium cpu usage do not evolve but it is not animating the favicon.
If you want to disable it on firefox and are using ublock origin, you can do so by going to the ublock origin dashboard --> My Filters and add the following line:
||research.exoticsilicon.com/images/icon.svg
It’s kind of how so many LaTeX documents look the same because nobody bothers to design anything; the inverse problem from Word where things are too easy to change.
[1] https://www.vacation.inc [2] https://poolsuite.net
Another one is here: https://www.vistaserv.net/
The font rendering is especially impressive to me. You can read more about it here: https://www.vistaserv.net/blog/90s-fonts-modern-browsers