6 ms·

I've noticed an obnoxious new UI anti-pattern showing up more frequently as of late: a loading page that renders a fake UI made of nothing but light grey boxes.

I've noticed an obnoxious new UI anti-pattern showing up more frequently as of late: a loading page that renders a fake UI made of nothing but light grey boxes. More often than not, it's not even the actual UI layout of the page, just an artful rendition of a blank UI. These sorts of things drive me nuts, especially when it's a page whose contents could easily have been served as a static HTML page instead of rendering this silly fake UI via javascript then using more js + requests to replace that garbage with the actual content I want.

sherry-sherry 3y ago
That is mentioned in the article under 'Skeleton loader screen'. It can be nice on some slower/flakey connections, or on pages where different elements may load in at different times. Quite often the skeleton is static, and is then 'hydrated' with JS. I agree it seems to be used unnecessarily more and more now though.
- Springtime 3y ago
  I remember reading about the proposed idea back on A List Apart like 12 years ago and thinking it was an interesting idea yet surprisingly have only seen them adopted widely in the last ~5 years.
eastbound 3y ago
Everything-in-html requires to program MVC actions. Those patterns are often ugly, full of gotchas, hard to learn for kiddos, and old school. Plus, when the user clicks somewhere, we gotta load the new data with REST anyway, so that makes two ways to load data and it’s prone to mistakes, twice longer to develop. Rendering placeholders allows us to load everything via REST. The data takes the same path every time, so, fewer bugs, streamlined way of loading data, plus kiddos love the simplicity of writing REST resources in Java. Also, each visual component can be programmed in isolation, encapsulating its own concerns, rather than having to mix all data into the MVC action channel. And isolation/encapsulation is good for reliability and sharing the work across a team. One solution is to hydrate the initial HTML with the result of REST calls, but it has drawbacks. I know it won’t mop your sorrow. It may just help to know there is a reasonable reason for that. I also find it infuriating to look at a page that says: “3, 2, 1, Done! I’m loaded, that wasn’t so ling was it?— oh wait, gotta load my data… Theeeere you go I’m loaded! No wait, that thing as well…”
- atoav 3y ago
  As a "kiddo" I don't have any problems with first sending a html view that is made interactive with the js added to it. But then again I tend to avoid frameworks and thing software developers shouldn't pick completely inefficent patterns even if it is very convenient for them.
mvdtnz 3y ago
If you'd read the linked article you'd have the vocabulary to speak about these UIs you hate so much.
- wruza 3y ago
  You know it’s beyond help when a thing people hate is a named UX approach.

sherry-sherry 3y ago

That is mentioned in the article under 'Skeleton loader screen'. It can be nice on some slower/flakey connections, or on pages where different elements may load in at different times. Quite often the skeleton is static, and is then 'hydrated' with JS. I agree it seems to be used unnecessarily more and more now though.

Springtime 3y ago
I remember reading about the proposed idea back on A List Apart like 12 years ago and thinking it was an interesting idea yet surprisingly have only seen them adopted widely in the last ~5 years.

eastbound 3y ago

Everything-in-html requires to program MVC actions. Those patterns are often ugly, full of gotchas, hard to learn for kiddos, and old school. Plus, when the user clicks somewhere, we gotta load the new data with REST anyway, so that makes two ways to load data and it’s prone to mistakes, twice longer to develop. Rendering placeholders allows us to load everything via REST. The data takes the same path every time, so, fewer bugs, streamlined way of loading data, plus kiddos love the simplicity of writing REST resources in Java. Also, each visual component can be programmed in isolation, encapsulating its own concerns, rather than having to mix all data into the MVC action channel. And isolation/encapsulation is good for reliability and sharing the work across a team. One solution is to hydrate the initial HTML with the result of REST calls, but it has drawbacks. I know it won’t mop your sorrow. It may just help to know there is a reasonable reason for that. I also find it infuriating to look at a page that says: “3, 2, 1, Done! I’m loaded, that wasn’t so ling was it?— oh wait, gotta load my data… Theeeere you go I’m loaded! No wait, that thing as well…”

atoav 3y ago
As a "kiddo" I don't have any problems with first sending a html view that is made interactive with the js added to it. But then again I tend to avoid frameworks and thing software developers shouldn't pick completely inefficent patterns even if it is very convenient for them.

mvdtnz 3y ago

If you'd read the linked article you'd have the vocabulary to speak about these UIs you hate so much.

wruza 3y ago
You know it’s beyond help when a thing people hate is a named UX approach.