Usability

You may have recently read Adrian Roselli’s Scraping Burned Toast, Chris Coyier’s summary of the current “toast conversation”. Or maybe you’ve browsed the GitHub repository for A Standard ‘Toast’ UI Element and its WICG discussion thread.

Or maybe you’re familiar with the concept of toasts from Android development and Material Design.

But regardless of how familiar you are with the concept of a “toast”, work has been progressing on try to pave the existing cow paths different UI library definitions have set for said potential component. Unfortunately, the level of concern given to the accessibility and inclusive UX of a toast component varies quite a bit, depending on which component library you review.

[…]

Defining a toast

[…]

At a high level, toasts should be used to indicate the completion of a task or process initiated by the user or the application itself. For instance, a notification verifying the saving of a file, that a message had been properly sent, or a that a meeting was about to start.

If someone were to ignore, or miss a toast message, due to its timed display, there should be no negative impact on their current activities or the status that the message conveyed. Using the previous examples, ignoring a toast message would still mean that a file was saved, that a message was sent, or that a meeting was about to start.

[…]

Inclusive UX of a toast

A toast component should be considered a type of status message, and thus should be given a role="status". This will ensure that when a toast is displayed on screen, its contents will be, politely, communicated to assistive technologies, such as screen readers.

Ideally, a toast component should contain no interactive controls, as by doing so an immediate divergence of inclusive UX is introduced.

 

See the source link for a list of issues and some ways to mitigate them.

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles:

• Content is readable on all reasonable screens and devices.
• Only hyperlinks and buttons respond to clicks.
• Hyperlinks are underlined and buttons look like buttons.
• The back button works as expected.
• View content by scrolling.
• Decoration when needed and no unrelated content.
• Performance is a feature.

Standard drop-down menus that contain sub-menus very often have no concept of user intent, and this can lead to a repeating frustration that most of us have likely run into: straying off course by even a single pixel can cause the sub-menu to close instantly. Ways around this include adding a delay to try and account for user error, but that doesn’t feel as snappy. Amazon has a really clever solution that accounts for user error yet responds instantly:

At every position of the [pointer] you can picture a triangle between the current mouse position and the upper and lower right corners of the dropdown menu. If the next mouse position is within that triangle, the user is probably moving their [pointer] into the currently displayed submenu. Amazon uses this for a nice effect. As long as the [pointer] stays within that blue triangle the current submenu will stay open. It doesn’t matter if the [pointer] hovers over “Appstore for Android” momentarily – the user is probably heading toward “Learn more about Cloud Drive.”

And if the [pointer] goes outside of the blue triangle, they instantly switch the submenu, giving it a really responsive feel.

So if you’re as geeky as me and think something this trivial is cool, I made a jQuery plugin that fires events when detecting this sort of directional menu aiming: jQuery-menu-aim.

See the source link for more.

In Resilient Web Design Jeremy Keith discusses the idea of material honesty. He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.

Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

In Buttons In Design Systems Nathan Curtis says that we should distinguish links from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.

For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.

This seems like it could be a useful tool:

Increase your form conversions by fixing common usability issues