I'm a full-stack developer that is passionate about good user interfaces. In my newsletter, I talk mainly about UI/UX stuff. You could expect an email or two in a month, I'm not aiming to spam you with non-useful info.
Use multi-column layout for forms
|
Hi Reader! Wait, what?Okay, I admit it's a clickbait. Somewhat. Shouldn't we use one-column layout for forms? You should. However, one-column layout is not the same as placing each input on a new row. Don't take it too literally. Yes, it's better when you go from up to down. But if a group of fields is tightly related, they are perceived as a single group. And users don't have a problem recognizing that, Card Name - Expiration Date - CVC is one group. So the thing is to avoid Z-pattern, but it should be indeed the Z-pattern, otherwise the app where I'm writing the newsletter also violates the rule - there are many columns, links, elements placed across the app. “Hey, but that’s your opinion right?” - one may say. Well, may I refer to Baymard Institute: Notably, separate fields that are highly associated or can be thought of as a single coherent entity — such as
- dates (e.g., day/month/year fields);
- first, middle, and last name;
- city/state/ZIP or postal code;
- and credit card details (e.g., card number/expiration date/security code)
— can be placed on a single line within a form.
Across multiple rounds of checkout studies, having 2–3 inputs on a single line didn’t cause issues when they logically belonged to the same single entity — and so long as the rest of the overall form layout only consisted of a single column.
In short, there is a distinction between “some lines having 2–3 fields per line” (an acceptable practice in certain cases) and an overall “two-column form layout” (generally problematic and never recommended).
Thanks for reading, and have a nice day! |
Victor Ponamariov
I'm a full-stack developer that is passionate about good user interfaces. In my newsletter, I talk mainly about UI/UX stuff. You could expect an email or two in a month, I'm not aiming to spam you with non-useful info.
Here is a quick recap of all CSS prefers-* queries that you can use to adjust to user settings. Prefers Reduced Motion (95.57% global support) Indicates whether the user prefers less motion to avoid VIMS - Visually-Induced Motion Sickness. Here we disable any animations or transitions, but we can be flexible here (e.g., REDUCE motion but do not disable it completely) Prefers Color Scheme (95.16% global support) Detects whether the user prefers a light or dark color theme. In this example we...
Today we'll cover another CSS media query: prefers-reduced-motion, and how to load (or avoid loading) styles based on user preferences — this is genuinely cool stuff! I've just posted the same article on LinkedIn, for my first time. Accessibility concern There’s a condition called VIMS: Visually induced motion sickness (VIMS)—a subcategory of motion sickness that specifically relates to nausea, oculomotor strain, and disorientation from the perception of motion while remaining still. To...
After a rough patch, I’m getting back to writing. More practical stuff that you can apply directly in your projects. One topic that looks really good is how to use modern CSS to support UI/UX and accessibility. Preference Media Queries Preference Media Queries allow you to adapt your UI based on the user's system-level settings and personal preferences — like reduced motion, high contrast, or dark mode. They're mostly used to improve accessibility and user experience. Let's cover one of them....