Live data from Hacker News

Things that used to be hard and are now easy

jvns.ca

161–170 of 316 posts

Re: Things that used to be hard and are now easy

#161
post #149

Earlier quoted context omitted.

> But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc. Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance). I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doe…

Sorta. Screen readers, being external programs, really had no trouble dealing with tables. The tag wasn't semantic, sure; but the intent and reasoning wasn't exactly difficult. I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder. And this is ignoring the explosion in nested divs that most modern sites have.

It really depends. If table cell order happens to conform with a logical reading order, yeah, screen readers generally figured out when to ignore table semantics. But if the reading order does not make sense going row by row, then they are terribly broken.

Nested divs aren't that bad. (Ignoring overall performance considerations. And even then I'd suspect that's less a concern than download and running all these JS libraries.) Nested divs with a mish-mash of poorly applied ARIA can get pretty bad though!

Table layouts are also terrible for anyone who is not viewing the site at the browser width you designed it for. Accessibility is more than screen readers, and the ability to zoom or adjust browser width or display on a different device (hello mobile) is incredibly valuable for a lot of people. And I'd argue that the "ease" of using table layouts disappears as soon as you try to accommodate for any of that.

Re: Things that used to be hard and are now easy

#162

Earlier quoted context omitted.

Because the article was modified. [Note] Another HN user mentioned that the statement was dubious, cited the original statement, got downvoted to hell: https://news.ycombinator.com/item?id=30406644

They got downvoted not because of their disagreement, but because their comment was low quality. "Sure, bud." is a mere quip and doesn't add anything substantial to the discussion.

Good point.

Re: Things that used to be hard and are now easy

#163

I would love to see the reverse of this 'things that used to be easy and are now hard' That would be an interesting read

- registering internet resources (e.g. IPv4 block or desirable domain), due to scarcity

- various features that are harder to implement due to changing user/regulator expectations (from simple websites to stuff like GDPR)

- multimedia in the browser post-Flash, pre-WASM

Re: Things that used to be hard and are now easy

#164

There's another facet I've watched with interest: >> Building videogames, with Roblox / Unity This has resulted in something like 90 new games entering Steam every day. While some games may still be art, they're increasingly difficult to find among the noise. I've heard the mobile game market is in worse shape[1] by the deluge of games. "More games for everyone!" sounds great - but note that definitely doesn't mean m…

Is there a law for "when a thing becomes easier and/or cheaper to do, more of that thing is created, and the mean quality of that thing goes down"? Of course, there are positive effects as well — desktop publishing was responsible for countless design crimes, but it also unlocked some real innovation during print's last stand.

Re: Things that used to be hard and are now easy

#165
Writing GUI apps for Apple products.

Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at.

These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.

Re: Things that used to be hard and are now easy

#166

Earlier quoted context omitted.

> One needs an imprint and data privacy page. Really? I have a small personal website with no tracking; I guess my hosting provider collects server logs, but do I really need a privacy page for that? An imprint is something I've only seen on German websites (I recall reading somewhere that those are required by law there).

In Germany every site that collects, stores and/or processes personal data (PD) is required to have a data privacy explanation that is easily reachable from every page and explains to the user what data is being received, stored, processed and also explain the user's rights (for example the right to be informed, to correct data and so on). At first glance, a "private" page does not directly process personal data and…

> In Germany

Well, I'm not in Germany... you didn't mention in your original comment that it only applies to German websites!

Re: Things that used to be hard and are now easy

#167

There's another facet I've watched with interest: >> Building videogames, with Roblox / Unity This has resulted in something like 90 new games entering Steam every day. While some games may still be art, they're increasingly difficult to find among the noise. I've heard the mobile game market is in worse shape[1] by the deluge of games. "More games for everyone!" sounds great - but note that definitely doesn't mean m…

Is there a law for "when a thing becomes easier and/or cheaper to do, more of that thing is created, and the mean quality of that thing goes down"? Of course, there are positive effects as well — desktop publishing was responsible for countless design crimes, but it also unlocked some real innovation during print's last stand.

Jevon’s Paradox

Re: Things that used to be hard and are now easy

#169
post #149

Earlier quoted context omitted.

> But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc. Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance). I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doe…

Sorta. Screen readers, being external programs, really had no trouble dealing with tables. The tag wasn't semantic, sure; but the intent and reasoning wasn't exactly difficult. I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder. And this is ignoring the explosion in nested divs that most modern sites have.

Considering that I've developed a screen reader from the ground up, worked on the Narrator screen reader shipped with Windows, and routinely used screen readers to browse the web for almost 20 years, I think I know a thing or two about this.

So, it's true that screen readers have heuristics for detecting layout tables. But those heuristics aren't perfect. They're not even that sophisticated, at least the ones that I worked on. And some (most?) screen readers automatically announce any table that they don't detect as a layout table, even when continuously reading straight through the document. Notably, the screen reader I developed myself, which was the first one I routinely used, doesn't automatically announce tables unless the user is manually moving through the page, because I wanted to minimize verbal clutter when casually browsing the web. But when I went to work at Microsoft and started using Narrator to read my work email, I found the tables in certain HTML emails very annoying. Granted, Narrator didn't yet have a layout table heuristic at that time, but even when it did, that didn't entirely solve the problem. Luckily, there was also an overhaul in Narrator's verbosity levels while I was there, and that allowed me to eliminate the clutter of layout tables by reducing the verbosity level in my personal Narrator settings, perhaps at the cost of missing some other things.

Nested divs per se aren't a problem. Implementing a widget as a div without the appropriate ARIA markup is a problem.

Post reply on HN