91–100 of 271 posts
Also please don't use bad fonts. Someone posted the following article the other day and the font drove me so nuts that I had to resort editing the CSS code to make it readable. https://blog.bugsnag.com/bug-day-race-condition-therac-25/ I really wish "reading mode" was a prominent feature in desktop browsers.
it's pretty prominent in a lot of browsers, like firefox and safari (from the top of my head)
My biggest pet peeve is when sites use js to try to "help" me scroll. What. The. Hell. is wrong with developers who think their users' browsers can't scroll? Am I the only one?
Earlier quoted context omitted.
I'm in favor of this. My eyes aren't particularly bad, but I have to use reading glasses in order to read most computer text, and some can get really difficult. Larger fonts are better even for my bad-like-most-other-people-my-age eyes. The tiny text I would have found fine 20 years ago is painful now.
There's an easy fix for folks like yourself: most (all?) modern browsers support setting a minimum font size. Jack that up way into the double digits, and stop justifying ridiculously large font sizes for everyone.
Earlier quoted context omitted.
Heaven forbid your buttons look like buttons.
The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it? Why does there even have to be a button? I want an API not a button...
The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).
Maybe we should investigate this ancient tech of the old ones.
Earlier quoted context omitted.
It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.
Not necessarily: I do not want to click back 30 times to get out of your slideshow and back to my Google results. Thank you.
(Ironically, these days I'm relieved when I see a presentation is posted as a PDF: https://people.apache.org/~xli/presentations/history_Intel_C.... I'd much rather load a PDF than deal with all the shitty and insane ways people have figured out how to show presentations in HTML. Cough SlideShare: https://www.slideshare.net/garyachy/dpdk-44585840)
Earlier quoted context omitted.
Not necessarily: I do not want to click back 30 times to get out of your slideshow and back to my Google results. Thank you.
But the problem there is that they used a carousel in the first place. Were it content that justified clicking 30 times into it, it would also justify backing out of it 30 times.
I suppose it's all a matter of trying to do what will best match user expectations. Or just whatever will make them happiest. Maybe call it the principle of least annoyance.
Of course, if you make an ad supported slideshow app, maybe you want to show one slide per page to get more ad impressions. I suppose that would be the principle of maximum revenue, along with its corollary (from the user's perspective): the principle of maximum indignation.
I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).
So that's why that happens. Why on earth would you break one of the most foundational aspects of HTML that way?
How do screen readers handle these script-based links? I don't mind it from a "I have working eyes and arms" perspective, but I imagine it's kind of a pain for assisted vision?
Posted on Medium with a massive pointless image at the top and page loaded asynchronously using JS.
For some reason, font sizes have shot through the roof in the past few years. Medium is one of the biggest offenders. You get maybe 2-3 paragraphs per page now, when entire articles would fit on a single screen page with normal-sized fonts.
In the past decade designers/PMs have started to figure out that users don't read, so they aren't trying to wedge as much text in. Though I'm no fan of some iOS interface, I credit Apple with getting the concept of legible text into mainstream design thought.
As far as Medium et al goes - I think the idea there is not so much the font size as not wanting to show you more than 2-3 paragraphs, lest you get a "wall of text" opinion and not read any of it.
Why would I use LogRocket for my all-text no-js web "app"?