DEV Community: Colin Fahrion

3 Web UI Design concepts that should be scrapped

Colin Fahrion — Fri, 09 Apr 2021 22:54:51 +0000

I've been making web sites since 1996. The web has changed a lot since then and my position on what makes for a good design has changed a lot over the years. Several things have influenced these shifts: the advancement of technology, the shifts of user habits, and lastly (and least of all) the design fads of the day.

In my recent post Ok fine… TailwindCSS rocks!, I explained why I ditched my long running allegiance to semantic css in favor of Tailwind style utility classes. In this post, I'm going into some web design concepts that have been the de-facto standard for a long time and why they should be scrapped.

Carousels

The web is full of carousels. There are numerous javascript libraries out there to implement them and even a few css only experiments. The fact of the matter is the user doesn't care past the first or second slide. Unless you have really engaging content the user has already started scrolling down the page or clicked away before the it's even changed to the second slide. This is doubly true for users on mobile who are primed to just thumb scroll instantly.

There is only a couple reasons any site might want to consider a carousel:

A gallery of images
A product description with feature highlights

And even then in most cases you'd be better off just showing the content directly on the page and allow the user to scroll down like they already were planning to. I mean why take the chance that the content on every slide past the first one will be ignored?

Most sites implement carousels with branding marketing fluff that users gloss over. Since users are likely only going to see the first slide then it's a waste of time to implement more than one. Just focus your message with one big hero section.

Hover Dropdown Menus

Hover drop down menus are everywhere. Ever since hover became a thing, it became the standard for how a site structured navigation. There are numerous javascript libraries to that make it easy and even css only solutions.

They have always had issues however:

If you accidentally hover away from the menu it disappears. There are "hover intent" javascript functions that sorta solve this issue but it always felt like a kludge.
If your primary nav items are both pages and hover triggers then it can cause UI confusion for users as they may completely miss the fact that they are buttons.
The last issue is made worse on mobile where there is no hover so click becomes a hover and the user has to click once to expand the subnav and another time to go to that primary page. Since well over 50% of users are on mobile this matters a lot.
Hover also becomes an accessibility issue for keyboard users where focus replaces hover.

All of this gets 10x worse when a site has nested hover menus. Nested menus in general need to go away but I've always felt that.

I'm not the only one to see this issue. Adam Silver wrote about this in his article 4 reasons why hover menus are problematic way back in 2015. And UX Movement wrote about this way way back in 2011: Why Hover Menus Do Users More Harm Than Good.

Every site navigation I develop now either uses a flat navigation that goes directly to a page or uses click button menu. The button doesn't go anywhere and it uses the actual <button> html element since you get a lot of accessibility for free using it. It's sole purpose is to open a menu that contains a list of links. There are a lot of good examples out there for this technique. This W3C ARIA Navigation Menu Button Example is a good example in pure vanilla js. If you are using React check out this article A Guide to Accessible Interactive Components using React Libraries or the accessible components from Headless UI, Adobe Spectrum, Reakit, CharkaUI, or Reach UI.

Fancy Hover Animations

Ok I don't actually think hover animations need to be scrapped completely. Hover animations are fun. Everyone loves them and they can add to usability — for desktop users. However as over 50% of users are on mobile, that means all that work you put into that fancy hover has gone unnoticed and unloved.

Also hover states can lead to the dreaded sticky hover on mobile devices since mobile devices register a click as a hover. There are ways around this but it's something to look out for.

In my current web design work I use hover animations sparingly and I don't waste too much time on them knowing that most of my users will never see them. If animation is useful for a design, it's better to focus my effort on animations on active state, loading animations, or scroll position animations.

So that's my thoughts for now. What web UI concepts do you think are no longer a good practice and a waste of your precious development time? Are there any new UI design trends you view as bad ideas?

Cover Photo by NeONBRAND on Unsplash

Dark Mode Three Way Switch

Colin Fahrion — Tue, 30 Mar 2021 01:29:31 +0000

Dark mode is the new web design hotness. There are a lot of examples of switches out there but most of them are just dual switches — Light/Dark. I wanted to implement a three way switch in the site I am designing: Light/Auto/Dark so that people can choose to lock it in one mode or another or leave it auto so that it adjusts with prefers-color-scheme.

To implement it, I borrowed some ideas from CSS Toggle Switch using radio buttons and css to build the toggle. I implemented it in Tailwind with light/dark mode colors provided via css variables. I then wrote some simple vanilla JS to store the add "dark"/"light" class to the body tag and store the state in localStorage.

I'm pleased with the result. It's simple and clean and ideally should be accessible since it's based in the same technique that CSS Toggle Switch uses (I haven't tested it for accessibility though so no promises).

Here's my CodePen of it!

Cover photo by Elliott Engelmann

Ok fine… TailwindCSS rocks!

Colin Fahrion — Fri, 26 Feb 2021 21:33:05 +0000

Ew this is basically inline styles!

When I first ran across TailwindCSS, I admittedly had an instant guttural dislike. I've been designing and building websites since 1996 — when CSS was just a baby and html tables were the defacto way to lay out sites. …Yes to all you dev newbies, I'm that old. I've had to reboot my skills and best practices several times over the past 25 years.

I've honestly never much liked any CSS framework. I can see a Bootstrap site from a mile away. I know how CSS works, I've been using CSS for styling and layout since early CSS Zen Garden days. It's often easier for me just code the css myself rather than fight to override the styles the framework provides.

I've also long been a big proponent of semantic css and the separation of style and markup. That best practice has been engrained in my so long it's become nearly an ethical philosophy. So you can see why I had an instant dislike of Tailwind. It is the complete opposite of those ideals. It's basically a codified inline style system.

Questioning my own Best Practices

One thing I've learned however in several times I've had to reboot my web dev skills is that you need to keep an open mind. It pays to learn about the new shiny thing and sometimes you even need to throw out everything you thought you knew.

I give credit to my inner punk for giving me this perspective – question authority even, and especially, your own inner authority.

The best practice of semantic CSS and separating style from markup honestly served me well for a long time. I learned how to redesign the look of a site just using css. This paid off a lot over the years in situations where the CMS template engine that spit out the html was a pain to update. I've updated lots of old sites to polished mobile ready sites just by changing the CSS. Give me a good BEM structured html page and I can make it look however you want. Though I've also restyled a lot of sites with shit css naming.

CSS Styling Today's Web

Today's web is a different place. Everything is component in which css is usually scoped by default. BEM isn't necessary. Hell a lot of the time you can just ignore class names at all. Svelte and Vue have single file components mean that you can plop the style on the div. And the myriad of CSS-in-JS approaches in React attach the styles directly to the element.

Building a site or app with scoped using components is great! No longer do I have to worry about naming conflicts or the CSS cascade.

How I came around to TailwindCSS

When I first worked with React, I used CSS Modules for my styling. It was how I was used to working with a separate css file — CSS-in-JS felt wrong. Then I tried Svelte. Svelte's single file components are great and simple to work in. The CSS is just there right alongside the markup. I never realized how much context switching between the markup file and the css file slowed me down until then. After working with Svelte I began using CSS-in-JS in my React projects for the same reason. It reduced the context switching.

Still even though I had adapted there I didn't see the point of Tailwind. I mean I know CSS. Tailwind felt like just a syntax to learn. I read Adam Wathan's long involved post on CSS Utility Classes and "Separation of Concerns", which made me begin to rethink the issue.

To get it off my mind I decided it was time to question my own biases. I installed Tailwind Intellisense for VS Code and started up a test project with a starter that included Tailwind (actually it uses Windi, which is a Tailwind compiler). I then started making a basic site, forcing myself to use the utility classes for (most) all of the styling.

It took a while to get over the learning curve of the Tailwind syntax. Intellisense helped a lot with this but also the syntax is pretty intuitive once I got to using it. After a while, I discovered it was faster using Tailwind classes than writing the css out.

I realized two things…

Using a utility css framework pretty much completely gets rid of the issue of context switching. No more looking at another document or even down to the style area of the page like with Svelte. I can see how the element is styled and make changes just on the element itself!
Another great aspect is that it makes it easier to change from say Svelte to React or 11ty to Gatsby or whatever. Since the styling is embedded with the html I can just copy paste wherever I want. I just need to make sure that Tailwind is integrated and I'm good to go.

The first advantage is great but the second is what really won me over. I have a couple projects that I'm working on right now that I'm not settled on how I want to build it. But now with Tailwind I don't really care. I can design all the components just with plain html or a simple Svelte app. Then I can easily bring both the html and styling components to Gatsby or Next once I get going with building out the functionality.

My new CSS Best Practice

Tailwind is great as you can use as much or as little of it as you want. Tailwind's base css has everything normalized so nothing has any styling. I personally like start with a classless css file for at least some basic typography and form elements. So here's my current best practice:

Set styles for all html elements in a global CSS file using either my own or any of the number of classless css frameworks. I personally like to use fluid responsive type sizes here which I set at :root and make sure that all padding/margins/sizes use rem or em.
Use Tailwind or Windi for styling of layout and components.
Use component scoped or CSS-in-JS for more complicated styling or where styles change based on functionality. (NOTE: Twind aka Tailwind in JS is potentially useful).

Of course, there are times too where Tailwind is not the best fit — namely if I'm working with a CMS that I don't fully control the templating. My fallback here is a good base classless css framework along with using css custom properties style variables to set up my design system. Level Up Tutorials has a good Modern CSS Design Systems course that touches on this approach.

This is how I'm approaching things now at least. It might very well change once some new better way of working comes along.

This post turned out to be longer than expected but then as I said I've been at this web game for a long time. I had a lot of thoughts to process and it was good to get them out. Hopefully this helps you on your journey to find your Best Practice!

Multiple CSS Approaches to Responsive Width Centered Containers

Colin Fahrion — Thu, 18 Feb 2021 23:07:45 +0000

Centered column containers are the foundation of almost every website on the internet. The basic approach that everyone knows is the max-width with margin auto approach. Often you see this using pixels.

max-width: 700px;
margin: 0 auto;

Pro: works all the way back to IE7
Con: hard-coded pixel sizes can mess with users who change their default font size. Zoom still works fine though.

Now that we no longer have to care about old versions of IE, there are several ways to better ways to accomplish a responsive centered columns.

Responsive Typography Width

By using a type unit for width we can allow the column to flex with size of the font. This allows us adjust the size by changing the base font size. It also to allows us to easily set column sizes for desired line lengths. The Elements of Typographic Style by Robert Bringhurst recommends no more than 75 characters per line, in ch this amounts to about 60ch.

A Note on ch vs rem or em

Often developers reach for rem or em but in for line length sizing the ch unit works better. The ch unit is the width of the “0” character is in a given font-family and font-size. Whereas em and rem strictly amounts to the font-size and does not take into account the font-family, which is useful to know in the case of condensed or wide fonts. Read What is the CSS ‘ch’ Unit? by Eric Meyer for a good overview.

NOTE: IE10-11 computes ch wrong ignoring the space around the character. So you may need to use rem or em instead. 75 characters is about 36em for an average width font.

max-width: 60ch;
margin: 0 auto;

Pro: Width is set variably based on ch which is the width of the "O" of the font-family and font-size. This
Con: IE10/11 measure ch incorrectly so sizes will be smaller.

Containers with full width backgrounds

Having a full width background with a centered container for content is a common technique for hero type areas. Typically if you want to do this you need to have a wrapper around your centered container element like so:

.wrapper {
  background: lightcoral;
}

.wrapper > * {
  max-width: 60ch;
  margin: 0 auto;
}

Pro: Works on IE 10 and newer if you use rems
Con: Requires an inner element

Full width background using padding with max()

This article CSS-Tricks however has a brilliant technique using padding and the max() css function which does not require an inner element! This simpler approach is great for component style development.

With the css variables you have a very flexible component that can be resized for various needs.

.wrapper {
  --max-width: 60ch;
  --pad-y: 1rem;  
  --min-gutter: 1rem;
  --bg: lightcoral;
  background: var(--bg);
  padding: var(--pad-y) max(var(--min-gutter), 50vw - var(--max-width) / 2);
}

.wrapper.hero {
--max-width: 100ch;
--min-gutter: 0rem;
--bg: url("hero.jpg") no-repeat cover;
}

Pro: Works without an inner element!
Con: max() does not work with IE11 or earlier.

CSS Flexbox and CSS Grid Wrappers

There are several ways to use CSS Flexbox and CSS Grid for layout — too much to go into in this article honestly. With flexbox you can create multiple columns layouts. With css grid you can create layouts with well grids duh.

One of interesting technique for centered containers is to use css grid with named grid areas. This allows for a single wrapper with the ability to set widths for different types of child content.

.wrapper {
  --gutter-min: 1rem;
  display: grid;
  grid-template-columns: [start] minmax(var(-gutter-min), 1fr) [hero-start] minmax(0, 1fr) [content-start] minmax(30ch, 60ch) [content-end] minmax(0, 1fr) [hero-end] minmax(var(-gutter-min), 1fr) [end]
}

.wrapper > *,
.wrapper > .content {
   grid-column: content-start / content-end;
}

.wrapper > .hero {
   grid-column: hero-start / hero-end;
}

.wrapper > .full-width {
  grid-column: start / end;
}

You can even get really complicated using this technique if you want with 12 column grid style layout as Michelle Barker explains in Super-Powered Grid Components with CSS Custom Properties.

Pro: Very flexible as it's CSS Grid
Cons: Obviously does not work with IE11 or earlier. Requires inner element. Grid does not allow margin collapse.

You can see all these techniques and more on this CodePen!

What centered container techniques do you reach for? Are there any other techniques you've discovered?

(Cover photo by Dan Meyers)