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.
Live and learn. Either CSS is developing so fast, or I'm so slow, but I feel like I knew 80% of CSS in 2015, and now I know at most 50%. Today we'll talk about env function in CSS. Yeah... there are environment variables in CSS, just like in NodeJS 🤯 The env() CSS function can be used to insert the value of a user-agent defined environment variable into your CSS. The syntax is simple: env(<environment-variable>, <fallback>) But what kind of environment variables do we have and how can we use...
When I first dived into the topic of colors, it seemed to me that I was at least studying nuclear physics. It still does, though. 😅 Disclaimer: I might have some inaccuracies in this article. Sometimes I used definitions provided by Google AI, because it was challenging for me to convey/explain the ideas with precise words. But mostly there are links and definitions from Wikipedia and other resources. There are many notions and abbreviations: CIE 1931, RGB, sRGB, HSL, CMYK, Oklab, LCH, OKLCH,...
There is the grayscale filter in CSS that can make your pictures completely grayscale. It's useful when you want to show a bunch of logos, making them grayscale by default, but when you hover over them, they become colorful. But! Another trick is to use grayscale on the <html> tag. This way you can look at your app from a different perspective and see how it looks without colors. This is useful if you want to see what draws users' attention most, whether such elements as links, buttons, and...