Be careful with this. A non-trivial fraction of the custom file inputs that I’ve seen have been imperfect in ways that made me wish they’d stuck with the default. (This used to be a much more common problem; now it’s normally done right, or right enough.)
> Autofocus the first input input
Be careful with this. Focusing a field is disconcerting if the user didn’t expect or desire it: on desktop computers, Space is commonly used as equivalent to the Page Down key, but if you’ve focused something, it won’t do that; and on mobile devices, it’ll probably pop a keyboard open, perhaps blocking the user from seeing what’s actually going on. Only ever autofocus anything if an explicit user action has indicated they certainly want to interact with the form (some examples for the public internet: the user clicked a “log in” or “sign up” link, or you’re a search engine and they opened your front page; but if you’re an advertising landing page and have a form you want the user to fill out, don’t autofocus it; or if you have a search bar, don’t autofocus it).
if the page you’re loading has only the one If there’s anything else on the page, don’t autofocus anything.
I’d argue that most forms shouldn’t use autofocus.
(Also, s/input input/input/. While I’m thinking of this, I noticed a “recuve” that I think should have been “reduce” earlier in the document.)
> Help users fill the form without errors
> 3. In login/signup forms provide social authentication methods.
That’s… quite a way out of scope for UI design considerations. Subjectively so, anyway.
> 4. Use masks for such fields as dates and phone numbers so
that users don't guess the correct format.
Strong disagree, with prejudice. Masks are evil. Unqualifiedly so. It’s difficult to implement them in a way that won’t lead to unpleasant surprises anywhere, and outright impossible on the web. Do not use masks. Rather, prefer to validate and reshape data afterwards. e.g. accept all kinds of date formats, then on blur rewrite it to an unambiguous and well-understood format if possible, or at least a canonical and clearly-described format (e.g. for dates if you really want to put the month as a number rather than a name, make sure the order is clear, otherwise you’ll confuse either those pestiferous middle-endian people or the rest of the world).
> 6. Limit the symbols that the input accepts. For zip code it's reasonable to allow inputting only numbers.
Be careful with this. If you’re in the US, not all ZIP codes are just “five digits”: ZIP+4 codes are formatted like 12345-6789. If you’re in the UK, postcodes are alphanumeric. Oh yeah, also make sure with all of these things that you still represent them as strings, never numbers, or you’ll drop leading zeroes (e.g. in Australia, Darwin City is 0800) and probably run into validation problems in frontend, backend or mailing. Related: not all payment card numbers are 16 digits long. They can be 8–19 digits long.
> Show validation errors in the right place
But at the same time, make sure that the user can find the errors. I’ve definitely had forms where… there’s an error somewhere, but where is it?—because they didn’t make the styles clear enough.
> Put an overlay on images for better text contrast
Also consider blurring the image (in whole or in part). That’s very effective. For a detailed background image, a 30% black underlay and blur may be more effective than a 70% black underlay.
> You can quickly check the contrast level with chrome developer tools.
Wah, I dislike singling out just one browser. No idea about Safari, but Firefox has had this sort of stuff for a while too. (With these sorts of things, it’s a mixed bag as to which browser gets them first, but the other usually follows not long after.)
> Watch your shadows
The “good” example here actually shows a problem: the blur radius on the second box is too large and so sits on top of the first box. It’d be really nice if you could specify a different z-index for box-shadows to avoid this, but you can’t. So if your blur radius is large enough to collide with other containers, you have to be very careful about z-indexing. (If the shadow increases on interaction, like a hover effect, you may wish to pair that with a z-index bump so that the element draws on top of its previous and next siblings.)
> Don't rely on dots in gallery sliders
… but at the same time, consider whether you want to keep the dots as a supplement to indicate position. Or some kind of M of N indicator. (I say consider; it may or may not be useful.)
> Label your icons
You can even try going further: see what it’s like if you ditch icons altogether in favour of labels. Often it works out nicer this way (though you’ll probably still want to keep icons in a few places, for well-standardised icons).
> Leverage empty states
But be careful with this: you should strongly prefer your empty state to guide the user to the UI that will persist after the empty state is no more, e.g. draw an arrow up to the “add new” button, rather than putting an add button in the empty state that will only appear that one time. It’s all about training the user.
> Use skeletons
Skeletons are drastically overused these days. You might not notice it if you’re in the USA, but come visit us in Australia (once COVID border restrictions are done!) and experience the high-latency internet, and you’ll get tired of seeing skeletons, especially animated ones. I’m going to glibly say: just make the stuff load faster, and come up with alternatives to skeletons. (“Don't show loader right away” a couple of pages later deals with the periphery of this problem, thanks. s/traction of seconds/a fraction of a second/ there as well.)
> Button loading state
Ah, good times. I’ve designed a UI before where it would have multiple rows, each of which could have an “Add” or a “Remove” button, and I wanted them to be the same width, but it wasn’t a grid or anything. I settled for rendering both labels inside the button, with the false label given a height of zero (and hidden from screen readers too, don’t forget them). I was quite proud of the trick.
> It will give users some assurance that the app is working and not broken.
Except that I am very unlikely to believe the text, because I’m used to the idea that if it took longer than a few seconds, it’s probably not going to work, for various possible reasons (e.g. JS client error, network error, server error).
> Forbidding users to enter lengthy content by limiting the
number of characters they can input
This is far too likely to backfire. Either you’ll upset people because the limit is too low and now they can’t enter something that they need to enter, or you haven’t actually solved the problem because someone keeps spamming ﷽ just because it’s typically so absurdly wide for a single Unicode scalar value. (And here I’m not even getting into the discussion of how you define “characters” in your limit.)
----
There are also quite a number of grammatical errors that you might want to look into dealing with.
> Be careful with this. Focusing a field is disconcerting if the user didn’t expect or desire it: on desktop computers, Space is commonly used as equivalent to the Page Down key, but if you’ve focused something, it won’t do that; and on mobile devices, it’ll probably pop a keyboard open, perhaps blocking the user from seeing what’s actually going on. Only ever autofocus anything if an explicit user action has indicated they certainly want to interact with the form (some examples for the public internet: the user clicked a “log in” or “sign up” link, or you’re a search engine and they opened your front page; but if you’re an advertising landing page and have a form you want the user to fill out, don’t autofocus it; or if you have a search bar, don’t autofocus it).
I would argue that Space as an alias for Page Down is anachronistic and should be phased out. Without going any further down that particular rabbit hole, though, I agree with your overall point. I'd like more sites to provide this kind of behaviour as a preference. At the very least, give me a keyboard shortcut to focus your search input.
As an example, when I'm doing any PHP programming, I'm visiting php.net several times a day and 99.99% of the time, I want to use the search input immediately — even though I could want to scroll down to read previous version announcements. Maybe this fits into your 'search engine front page' case.
At least writing this ~~rant~~ response has made me go view source to find out the accesskey of that specific input, then go check the keyboard shortcut to activate an accesskey with my specific combination of OS and browser. Now I just need to force myself to use it until it's in muscle memory.
I mentioned Space as it’s the one I’m used to, but now I think back on it, all the other navigation keys get messed up inside a text box too (Up, Down, Left, Right, Home, End, Page Up, Page Down), so it’s not actually just about Space.
Dunno why you’d consider Space for page navigation anachronistic. Space has always been a flexible “do all kinds of different things as useful” key, and Space/Shift+Space scrolling in focusable caretless content areas has always been popular and universally supported. But if we were talking about troublesome old key behaviours, I’d be with you on Backspace to go back being bad, which some browsers still do. (And in file managers, it goes up a directory, which is a useful operation, but you can use Alt+Up for that too. All up, if it weren’t for muscle memory, I’d say nuke non-deletionist Backspace behaviour, but muscle memory is a serious thing, so we’re stuck with Backspace being weird like this.)
I trained myself out of using backspace for back precisely because of the number of times I'd end up in an input box and it would stop working. I use something like cmd-[ now, I think. I guess my point about space for pagedown is that it just seems unnecessary - I wonder how many keyboards don't have a PgDn key. Overloading printable characters, when non-printable alternatives exist, seems like a mistake.
Most laptop keyboards don’t have a Page Down key, though most that don’t will have Fn+Down emit Page Down. Space and Shift+Space are super useful on laptops especially.
The only one I have a bit of a gripe with is about icons. I wouldn't say everything needs an icon, but by trying to get rid of them you're just making a big bet on language and good translation. If you can visually and linguistically describe something, you're more likely than not creating more robust UI imo. Too many icons, or even any can be ugly, but probably not so much so that the added value isn't worth it.
> > 4. Use masks for such fields as dates and phone numbers so that users don't guess the correct format.
> Strong disagree, with prejudice. Masks are evil. Unqualifiedly so. It’s difficult to implement them in a way that won’t lead to unpleasant surprises anywhere, and outright impossible on the web. Do not use masks. Rather, prefer to validate and reshape data afterwards. e.g. accept all kinds of date formats, then on blur rewrite it to an unambiguous and well-understood format if possible, or at least a canonical and clearly-described format (e.g. for dates if you really want to put the month as a number rather than a name, make sure the order is clear, otherwise you’ll confuse either those pestiferous middle-endian people or the rest of the world).
I get the argument, but how would you determine something like 06/09/2021? In the US, that would mean 9th June, but in most of the world it means 6th September. The format doesn't give us any clues as to which.
Granted, masks, don't help us out here either (!), but structuring the input might?
The gold standard for avoiding ambiguity is to normalise to a format with month names: so for a US-centric thing, you’d normalise “06/09/2021” to “June 9, 2021”, and for the rest of the world, you’d normalise it to “6 September 2021” or a similar format. This is one way of clearly describing what you’re doing. But if you’re definitely doing numeric dates, then you need to label it to at least minimise the scope for confusion, like writing “DD/MM/YYYY” above or below it. (Another option, shown by the OP, is splitting day, month and year into separate text boxes. I have mixed feelings about that technique, as it suffers from expectation issues: if you shift focus automatically as you type, you’ll upset some users, and if you don’t you’ll surprise other users.)
As an example of doing all this well in practice, I like how snoozing an email in Fastmail for a custom period of time works. You get a little popup with a date text box and a time text box on one row, then below it a couple of renderings of the date and time it’ll snooze until, and the Save button on the right of that. If I type “tuesday” into the date text box (which it interprets as “next Tuesday” since it needs a future time), the two lines below change to “Tue 25 May 8:00 AM” / “In 3 days 9 hours”, and when I then blur the text box, its value is normalised to “25/05/2021”. (I also feel like mentioning that when the date is in this normalised format and there is no selection, the Up and Down keys work as you might desire, wherever your cursor is in the date field, increasing or decreasing the date by a day, month or year, and keeping the cursor in the same position. nmjenkins does a thorough job on this sort of interaction design, he was a pleasure to work with when I was at Fastmail for a few years.)
(This is all proper-endian dates because I have Fastmail in the British English locale. If it was in American English, it’d have normalised to the middle-endian abomination that is “05/25/2021”, and the first description line might have been similarly ordered differently, though I haven’t confirmed that one.)
Of course, the types of values you should accept will vary by the semantics of the date. If you’re asking someone for their date of birth, parsing “tuesday” is probably not useful or helpful!
> … but at the same time, consider whether you want to keep the dots as a supplement to indicate position. Or some kind of M of N indicator. (I say consider; it may or may not be useful.)
Also, consider not using gallery sliders at all, especially if the page is long enough to not fit on screen anyway. Instead, show all items and let the user scroll the page as needed like for any other content. And for fucks sake don't automatically move to the next slide after the user has manually gone back.
> Replace default file inputs with custom ones
Be careful with this. A non-trivial fraction of the custom file inputs that I’ve seen have been imperfect in ways that made me wish they’d stuck with the default. (This used to be a much more common problem; now it’s normally done right, or right enough.)
> Autofocus the first input input
Be careful with this. Focusing a field is disconcerting if the user didn’t expect or desire it: on desktop computers, Space is commonly used as equivalent to the Page Down key, but if you’ve focused something, it won’t do that; and on mobile devices, it’ll probably pop a keyboard open, perhaps blocking the user from seeing what’s actually going on. Only ever autofocus anything if an explicit user action has indicated they certainly want to interact with the form (some examples for the public internet: the user clicked a “log in” or “sign up” link, or you’re a search engine and they opened your front page; but if you’re an advertising landing page and have a form you want the user to fill out, don’t autofocus it; or if you have a search bar, don’t autofocus it).
if the page you’re loading has only the one If there’s anything else on the page, don’t autofocus anything.
I’d argue that most forms shouldn’t use autofocus.
(Also, s/input input/input/. While I’m thinking of this, I noticed a “recuve” that I think should have been “reduce” earlier in the document.)
> Help users fill the form without errors
> 3. In login/signup forms provide social authentication methods.
That’s… quite a way out of scope for UI design considerations. Subjectively so, anyway.
> 4. Use masks for such fields as dates and phone numbers so that users don't guess the correct format.
Strong disagree, with prejudice. Masks are evil. Unqualifiedly so. It’s difficult to implement them in a way that won’t lead to unpleasant surprises anywhere, and outright impossible on the web. Do not use masks. Rather, prefer to validate and reshape data afterwards. e.g. accept all kinds of date formats, then on blur rewrite it to an unambiguous and well-understood format if possible, or at least a canonical and clearly-described format (e.g. for dates if you really want to put the month as a number rather than a name, make sure the order is clear, otherwise you’ll confuse either those pestiferous middle-endian people or the rest of the world).
> 6. Limit the symbols that the input accepts. For zip code it's reasonable to allow inputting only numbers.
Be careful with this. If you’re in the US, not all ZIP codes are just “five digits”: ZIP+4 codes are formatted like 12345-6789. If you’re in the UK, postcodes are alphanumeric. Oh yeah, also make sure with all of these things that you still represent them as strings, never numbers, or you’ll drop leading zeroes (e.g. in Australia, Darwin City is 0800) and probably run into validation problems in frontend, backend or mailing. Related: not all payment card numbers are 16 digits long. They can be 8–19 digits long.
> Show validation errors in the right place
But at the same time, make sure that the user can find the errors. I’ve definitely had forms where… there’s an error somewhere, but where is it?—because they didn’t make the styles clear enough.
> Put an overlay on images for better text contrast
Also consider blurring the image (in whole or in part). That’s very effective. For a detailed background image, a 30% black underlay and blur may be more effective than a 70% black underlay.
> You can quickly check the contrast level with chrome developer tools.
Wah, I dislike singling out just one browser. No idea about Safari, but Firefox has had this sort of stuff for a while too. (With these sorts of things, it’s a mixed bag as to which browser gets them first, but the other usually follows not long after.)
> Watch your shadows
The “good” example here actually shows a problem: the blur radius on the second box is too large and so sits on top of the first box. It’d be really nice if you could specify a different z-index for box-shadows to avoid this, but you can’t. So if your blur radius is large enough to collide with other containers, you have to be very careful about z-indexing. (If the shadow increases on interaction, like a hover effect, you may wish to pair that with a z-index bump so that the element draws on top of its previous and next siblings.)
> Don't rely on dots in gallery sliders
… but at the same time, consider whether you want to keep the dots as a supplement to indicate position. Or some kind of M of N indicator. (I say consider; it may or may not be useful.)
> Label your icons
You can even try going further: see what it’s like if you ditch icons altogether in favour of labels. Often it works out nicer this way (though you’ll probably still want to keep icons in a few places, for well-standardised icons).
> Leverage empty states
But be careful with this: you should strongly prefer your empty state to guide the user to the UI that will persist after the empty state is no more, e.g. draw an arrow up to the “add new” button, rather than putting an add button in the empty state that will only appear that one time. It’s all about training the user.
> Use skeletons
Skeletons are drastically overused these days. You might not notice it if you’re in the USA, but come visit us in Australia (once COVID border restrictions are done!) and experience the high-latency internet, and you’ll get tired of seeing skeletons, especially animated ones. I’m going to glibly say: just make the stuff load faster, and come up with alternatives to skeletons. (“Don't show loader right away” a couple of pages later deals with the periphery of this problem, thanks. s/traction of seconds/a fraction of a second/ there as well.)
> Button loading state
Ah, good times. I’ve designed a UI before where it would have multiple rows, each of which could have an “Add” or a “Remove” button, and I wanted them to be the same width, but it wasn’t a grid or anything. I settled for rendering both labels inside the button, with the false label given a height of zero (and hidden from screen readers too, don’t forget them). I was quite proud of the trick.
> It will give users some assurance that the app is working and not broken.
Except that I am very unlikely to believe the text, because I’m used to the idea that if it took longer than a few seconds, it’s probably not going to work, for various possible reasons (e.g. JS client error, network error, server error).
> Forbidding users to enter lengthy content by limiting the number of characters they can input
This is far too likely to backfire. Either you’ll upset people because the limit is too low and now they can’t enter something that they need to enter, or you haven’t actually solved the problem because someone keeps spamming ﷽ just because it’s typically so absurdly wide for a single Unicode scalar value. (And here I’m not even getting into the discussion of how you define “characters” in your limit.)
----
There are also quite a number of grammatical errors that you might want to look into dealing with.