Avoiding media queries is possible but unreadable.

Some SCSS mixins make it more readable though: https://github.com/ryevych/adaptiveValueFunction/blob/main/scss/adaptiveValueFunction.scss

Extending the atomic design with applications and principles:

Applications provide a place to document overall product and business information to give context about how and why the pages within an application are organized. Principles were added below the Atoms as a repository for our generalized interaction patterns; patterns such as how and why to use animations or the proper way to truncate text.

An example of style guide for content

From Tim Berners-Lee
Date: 1998, last change: 2013-03-04 22:56:21

When you design a system or a language, if the features can be broken into relatively loosely bound groups of relatively closely bound features, then that division is a good thing to be part of the design. This is just good engineering. It means that when you want to change the system, you can with luck in the future change only one part, which will only require you to understand (and test) that part. This will allow other people to independently change other parts at the same time. This is just classic good software design and books have been written about it. The corollary, the TOII is less frequently met.

Feature available or not in your current browser

Web Content Accessibility Guidelines Success Criterion 2.4.4: Link Purpose (In Context) instructs us to ensure that a link’s accessible name makes sense when separated from its surrounding context. It’s why “learn more about elephants” is a far more effective link name than “click here.”

Cool to know.

This is all about maintaining an equivalent experience by not over-describing something for only a certain subset of people. Here, the goal is to preserve the author’s intentional act of creating a sense of curiosity, regardless of the way someone interacts with technology.

User-facing state is what someone experiences when they interact with (or try to interact with) an element in some capacity. It is reactive, helping to communicate the ways in which something can be manipulated.

It is also worth noting that on the web, the majority of user-facing state can be communicated programatically. This means that there is an HTML attribute or ARIA declaration that can ensure people who can’t see the content can understand the state something has been set to.

It is different from the application state.

The states:

• resting: the status of something before someone has interacted with it, or other content affects it. Oftentimes referred to as “Base” or “Default.”
• hovered
• active
• focused
• visited
• loading / loaded
• disabled
• hidden
• readonly
• enabled
• checked: marked for sending as data to another internal or external resource. Can be focused, but keeps it's selected state after focus is moved
• unchecked
• undeterminate
• selected / deselected
• dragged / dropped
• collapsed / expanded
• resizing
• dirty: an editable element that has been manipulated on one or more occurences
• pristine: editable element has yet to be manipulated by someone
• saving
• overflowing
• scrolling
• playing / paused / stopped
• sticky
• unstuck: sticky element removed from a side of the viewport back it its original position

Research shows that the more different a new view is visually, the more likely it is to be perceived as a separate page by users. With it comes the expectation that the “Back” button will bring a user to the previous “page,” even though, technically, it might not really be a separate page.

That's why it's good to adjust the URL as much as possible :)
Moreover it allows to share this "state" of the page

Nice project

Un dashboard d'accessibilité reprenant un bon paquet d'outils. C'est bien fait, complet, et ça rend la démarche d'accessibilité approchable

(via https://nicolas-delsaux.hd.free.fr/Shaarli/?-ovkdg)

Ahaha the catchphrase

In short, the information age needs an information super-highway and not just a big pipe for interactive documents.

About academia and industry:

Academia is structured in a way that there is very little incentive for anyone to build usable software. Instead you are elevated for rapidly throwing together an idea, a tiny proof of concept, and to iterate on microscopic variations of this thing to produce as many papers as possible.

In engineering the devil is in the detail. You really need to get into the weeds before you can know what the right thing to do is. This is simultaneously a devastating situation for industry and academia. Nobody is going to wait around for a team of engineers to finish building a system to write about it in Academia. You'll be passed immediately by legions of paper pushers. And in industry, you can't just be mucking about with a system that you might have to throw away.

And Semantic Web seems to be something to learn about: https://en.wikipedia.org/wiki/Semantic_Web

Segmented Rendering is just a smarter way to do static rendering. Once you understand that it’s all about caching renders and then getting the right cached render for each request, everything will click into place.

To implement segmented rendering:

1. Define your “segments” for a page.
   Example: paid users versus free users, users from company A versus users from company B or C, etc.
2. Render as many static variations of a page you need, with one URL per segment.
   Example: /with-jokes/my-article, /bland/my-article. Each variation matches a segment, for instance, paid or free users.
3. Setup a very small redirection server, that checks the HTTP request content and redirects the user to the right variation, depending on their segment. Example: paid users are redirected to /with-jokes/my-article. We can tell if a user is paid or not by checking their request cookies.

More performance?
Render the site on demand with Incremental Static Regeneration

Formalizing REST APIs

My API is up to level 2 on the Richardson Maturity Model. So my API is more an HTTP+JSON RPC than Rest.

The short answer to this question is that HATEOAS isn’t a good fit for most modern use cases for APIs. That is why after almost 20 years, HATEOAS still hasn’t gained wide adoption among developers. GraphQL on the other hand is spreading like wildfire because it solves real-world problems. ‒ GraphQL and REST Level 3 (HATEOAS)

I feel this feeling too that something is wrong

Rather than interrogating a device directly, we ask the device vendor to do it for us.

I see so much problems coming 🍿
At the same time, I like the idea so much!

4 parties involved:

• an origin (service provider)
• a client (service consumer)
• an attester (proof the client is real, for example device vendors)
• an issuer: producer of the token called by the attester and choosed by the origin

An enormous ad-blocking list!

I have a bad experience with carousels as the user can not control it.

Instead:

• ResidentAdvisor avoid carousels altogether, highlight three last features, and invites users to explore more with a “View more features” button.
• Australia Post uses a dynamic layout to highlight all features together in the same area.
• 168plymouth uses mini-carousels for each feature that they want to highlight. There is no rotation, no auto-advancing, and you can move only in a single direction — moving backward might not be necessary with just 4 images that every panel contains.

TL;DR refers to the language selector checklist

In my experience, when asked to change a country or language, a vast majority of users will immediately head to the header of the page first, and if they can’t find it there, they’ll jump all the way to the bottom of the page and scout the footer next.

I find this rule true in my experience:

We can’t confidently infer users’ preferences without asking them first.
While polite nudging is reasonable, automatic redirects are not.

As a rule of thumb: let the user choose between language, country and currency.

For example, if you want to purchase sneakers on Adidas from Germany but deliver them to your friend in Poland, you need to be able to make sense of the Polish language when checking out.

Moneses shows two tabs in the right upper corner of the header. Users can switch between language and country, defining preferences for each separately. [...] We can allow users to customize further parts of the UI, from currency and auto-translation to units of measurement and date formatting.

Preferred customization:

• shipping location
• preferred currency
• units of measure
• time/date formatting
• time zones preferences
• level of experience

Modal windows are often dismissed. So, In the mock-up above [with a modal on the bottom right], the important content isn’t blocked by the modal.

• display most languages/countries in their local format . It avoids the assumption that the user needs to understand English.
• breaking options down by tabs, either horizontal or vertical ones
• provide users with poignant autocomplete suggestions. But Sometimes the fine-tuning of making autocomplete work for many different languages might be an effort way too underestimated and way too time-consuming.
• Use the globe or translate flags to indicate the choice of locales

On Atlassian, if the user with a different browser language preference enters the site, it suggests changing the language at the very top of the page, with a globe icon appearing there, too.

Infinite Scroll checklist

*If in doubt, always prefer pagination.

• With infinite scroll, always integrate a footer reveal.
• Consider separating “old” and “new” items visually.
• Provide an option to continue browsing later.
• Consider using “load more” + infinite scroll together.
• Consider using pagination + infinite scroll together.
• Change the URL as new items are loaded in and expose it to users.
• Allow users to jump to any page with a pagination drop-down.
• Consider using scrollbar range intervals.
• Consider allowing users to pin or bookmark items/areas of interest.
• Make sure accessibility and performance are major considerations in the implementation.

I totally agree and it felt natural to me

Memory and local storage are great for “private” state — settings, caches, history. URL parameters are good for the “public” state, so that one could bookmark or forward the stateful link.

LOL

A framework for building a web app in Rust 🤔
May be useful someday.

It's true that the Rust ecosystem is growing and tools are coming. But we lack the knowledge of how we can put things together. Here it fills the gap.