You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This got cut from another article, so I'm tracking it here for publication later.
Abstractions make it easier for things to slip through the cracks
A much bigger risk of using abstractions is the removal of developers further from what actually happens in their apps. Using a framework like Angular or React makes it possible to build apps extremely quickly, but it can also mean we never even notice we’re creating non-semantic, inaccessible content.
As a contrived example, let’s take a look at this React code:
constApp=()=>(<Wrapper><Title>Hello Friends!</Title><Subtitle>Doesn’t this look semantic?</Subtitle></Wrapper>);
From a DX perspective, this is great. We see right away that our app displays a title and a subtitle, and if our job was to edit one of those, it would take little effort to figure out how to do it.
Underneath this abstraction, however, there’s trouble. The developers who wrote this code weren’t thinking about semantics or accessibility, so the final result of this code is a mess of div soup:
<div id="root"><div class="css-1jm59wz"><div class="css-xb3uqj">Hello Friends!</div><div class="css-18fjbby">Doesn’t this look semantic?</div></div></div>
Through no malice or ill intent, we’ve created a poor user experience because our abstraction didn’t take semantics into consideration.
In some cases, like open source projects, these oversights will be patched by the community as they’re caught, so all we have to do is keep our frameworks up to date. This is one of the strengths of using community-powered tools.
When we use a given tool or framework to improve our DX, we’re at the whim of the developers who work on it. If they never prioritize accessibility, our users will suffer for the sake of our DX. This puts us in a difficult situation: we can give up the improved DX — and the productivity and job satisfaction it provides — in favor or improving the UX of our app, or we can let our users suffer so our jobs are easier.
If we find ourselves making choices about who must suffer — the developer or the user — it’s a strong signal that DX and UX got out of alignment somewhere.
The text was updated successfully, but these errors were encountered:
This got cut from another article, so I'm tracking it here for publication later.
Abstractions make it easier for things to slip through the cracks
A much bigger risk of using abstractions is the removal of developers further from what actually happens in their apps. Using a framework like Angular or React makes it possible to build apps extremely quickly, but it can also mean we never even notice we’re creating non-semantic, inaccessible content.
As a contrived example, let’s take a look at this React code:
From a DX perspective, this is great. We see right away that our app displays a title and a subtitle, and if our job was to edit one of those, it would take little effort to figure out how to do it.
Underneath this abstraction, however, there’s trouble. The developers who wrote this code weren’t thinking about semantics or accessibility, so the final result of this code is a mess of div soup:
Through no malice or ill intent, we’ve created a poor user experience because our abstraction didn’t take semantics into consideration.
In some cases, like open source projects, these oversights will be patched by the community as they’re caught, so all we have to do is keep our frameworks up to date. This is one of the strengths of using community-powered tools.
When we use a given tool or framework to improve our DX, we’re at the whim of the developers who work on it. If they never prioritize accessibility, our users will suffer for the sake of our DX. This puts us in a difficult situation: we can give up the improved DX — and the productivity and job satisfaction it provides — in favor or improving the UX of our app, or we can let our users suffer so our jobs are easier.
If we find ourselves making choices about who must suffer — the developer or the user — it’s a strong signal that DX and UX got out of alignment somewhere.
The text was updated successfully, but these errors were encountered: