I'm not a UI/UX guy, but the presentation in the book was so good, I decided to read it all in one sitting! As a user, I have faced the problems you describe in pages 38 and 57, websites should always try and make it clear where there are more options/content that may be hidden due to lack of screen real estate.
Thank you for providing these useful hints. Some are known, but you can easily forget these.
Also the presentation is very well done, IMO. Very clear and concise and also the images give you an immediate impression on why you should do certain things.
Thank you!
Such comments motivates me to do more and improve. I've just read your bio and I'm feel like you: I'm teaching even thought I am FAR from being an expert.
This way I learn. And I do mistakes too. Just skimmed through the book and found a mistake (in the "increase clickable are section" the cross icon on the second picture don't have increased area -_-)
I’d be interested to know what pattern other than the date would be suitable for "self links". So far I’ve seen them used on Twitter, most blogs (but title also works there), forums (e.g.: right here on HN) and all chat apps. Would an explicit "link to this" be better?
I was also interested in the Twitter example. I'm always one for encouraging links to look like links, but there have to be exceptions — menu nav is the canonical example where you can usually get away with not blue-underlines because the menu nav is usually obviously links.
The typical defence against custom-styled links is that blue-underlines look 'ugly'. Whilst this sounds initially like a poor argument, if you reword 'ugly' as 'distracting', you start approaching a good UX argument.
Maybe the equivalent of such 'self links' is the convention around fragment identifiers and elements with IDs that sites 'expect' that you might want to link to — e.g. headers. Typically, when you hover over such a header, you'll see a ¶, or similar symbol, which is linked to that ID.
On twitter.com listings, the entire tweet is now a link to the individual tweet page — was that always the case? It's not perfectly discoverable, of course, but it's pretty good. Hmm... I've just realised that's also not a proper link, of course...
At first I wrote a looot of text, but then my friend told me that "Come on, remove all that text, it's idea that matters, you can describe it way shorter"
Very nicely done - congrats. You should create website with the same content and try and get css-tricks and others to link to it, this is a good resource for many
Thanks for another link. I however am always baffled how some PDF are free are some are insanely priced. I am fine paying for work but why do certain people think just because it is on a fancy page it is worth 99USD (average book price is 18-20USD).
Although I ~never used Apple products, a good ten-fifteen years ago I ran through a quite expensive "Apple Human Interface Design"[1] book. After that, whenever another "book" / blog series / etc came out about "UI", I was discarding them saying "and now what, that's just common sense".
It. Is. Not.
The more companies and people I had been working with, the more I started to see that most of the UI design (or for that matter, displaying information on a UI / document / advertisement) what I thought had become "common sense", hadn't. Most of my colleagues cannot properly position / color a button. Cannot structure a document (headers, tables, bulletpoints) to be easily comprehensible, consumable. Struggle to summarize information in an email.
This 50 UI tips is great! Thanks for this. I will share as a baseline with my team.
[1]: I can't find which one. Maybe its title was something different.
Microsoft used to have one as well (600-odd pages or so). The current one is more like $randomFrameworkDocs where they have a short page with a screenshot for a few UWP components / patterns. Before that one they had something similar for Aero, but neither is a real HIG, they're just describing components. I can't find the old one, maybe they removed it because it shames their newer products.
Documentation used to explain the philosophy and system behind the thinking.
My old HP Deskjet 500C came with a thin book(let) titled "How to Use Color". It tells all the basics and then some for effective color documents and presentations. I hold on to it like it's gonna save my life. It's that good.
I love reading older material like this for two reasons:
(1) Since people were less familiar with computers back then, the way that things (like the cursor and drag-and-drop) are explained in this guides tends to be more explicit. Being re-introduced to concepts we take for granted is refreshing and helps with coming up with new concepts rather than just being confined to what we already see around us.
(2) Seeing what advice still applies decades later is a great way to figure out which pieces of advice are timeless and universal.
Yep, you can use separate HTML elements, the key bit is to keep the closing and opening tags directly adjacent with no whitespace or newlines, example https://jsfiddle.net/z65qwuvp/1/
The UI standards mess goes all go back to when Microsoft needed Windows to look more like Mac OS. They didn't want to "copy" Apple, so they reversed the order of UI elements like dialog and window buttons.
This was fine when the platforms were separate, but it made it impossible for websites to have a uniform standard. At best, consumer websites follow Apple guidelines while enterprise, government, and SAAS sites follow Microsoft.
A lot of useful tips for sure, and it's good work. However, as a UI designer who has read (too many!) books on the topic, I wouldn't call this a book. It's 50 web design tips combined in a PDF. Probably better defined as a "quick guide" than a book.
I think you can have something up and running very easily with static site generators like Gatsby or Hugo. I think this is kind of the ideal use case for those tools. Wish you all the best with the project! :)
This is why I don't understand terraform's convention of aligning all equal signs. It looks nice as a block of text but it's a lot of unnecessary cognitive effort to follow the invisible line between an attribute and its value.
The syntax plugins for Prisma ORM auto-format their schema files in a similar way [1]. It bothers me so much that I can't bring myself to use their solution - which I realise is incredibly petty :)
I couldn't really put into words why this column style formatting bothers me so much for this type of data, but thanks to one of the comments there I think I do now: this information belongs together horizontally, but it is formatted in a vertical manner which takes more mental processing.
By the way, I’m subscribed to your newsletter. For anyone interested, check out https://user-interface.io. This guy sends random stuff about UI. Pretty decent.
It's an unsorted collection of web-oriented tips and tricks. The UX entries almost exclusively focus on improving user experience around conversion points, and are not generally applicable.
Hints on spacing, layout, text formatting, etc. are largely trivial, but there's probably value in verbalizing them for people who are just starting up. However, it would've probably been better - for a book - to "group logically related elements" together instead of having them scattered around the place.
There are some less obvious items that pick up on right things, but what prompted me to comment is that many "hints" don't apply universally and are highly context-specific. There also some that are way off.
---
From the "way off" department -
> Make links look like links
In general, yes, but the Twitter example given shows that the OP doesn't grok why it's done that way. UI elements have UX priorities. If you give prominence to all actionable elements regardless of their importance, you will end up with a circus. And if you tuck them away behind an expander or a burger, then you hinder the usability. So the common "trick" is to de-emphasize secondary elements, yet keep them discoverable. Just like Twitter people did it here.
> Consider removing confirmation modals
This makes no material difference - it's either user mindlessly clicking on "Confirm" or being retrained to mindlessly click on "Restore". Potato-potata, just looks different. Besides there's also an in-place modal-less confirmations.
> Submitting verification code
Oh, don't you dare. Stripe does this (auto-submits the form on the last digit entry) and it is exceptionally annoying. People make typos, including the last digit. Allow for that.
---
From the "don't apply universally" department - pretty much everything that's form related:
> Don't hide form tips
> Require fewer fields
> Use labels instead of relying on placeholders
> Use reasonable width of inputs, the splitting date into three fields part
> Don't use complex forms in modals
This squarely depends on the form. It's one thing if I am trying to convert a visitor into a user and another if I am trying to make a back-office data entry person happy.
---
All in all, it's a solid domain name, with a good potential; the list itself is OK if a bit random and in a need of some clarification.
But the PDF is neither a book nor is it about UI per se.
Even thought tips about e.g. colors/contrast are trivial, as I know ~90% of sites fail to the AA requirement (cannot provide proof but I remember I saw a table with such data).
Even hacker news has its posts too close to each other, in my opinion.
Regarding twitter - isn't it an important action to get to the tweet? This thing I always needed, plus I asked few people. So I even used third party services just to get to the link to the tweet. In my opinion it's almost the most crucial one, I'd add a button "View the tweet" or whatever.
Working on focus is important, but not that you won't even guess that the function exists
Anyway, this is my first try, bare with me :) I'll make another one, this time really a "book". This one is made out of my tweets, so I didn't put that much effort.
P.S. I think I called it a book for getting attention. On the cover it says "50 tips".
Very good collection of very small but high-leverage changes that make an interface just more enjoyable.
I only think the reasoning you provide in the "require fewer [form] fields" chapter is really out of place. For example, whether or not to require an email for demo-signups is a business-level decision that might tie in directly with your sales strategy.
Yeah, it's a business decision, no doubt. The only thing is that when a solo founders make their products, they tend to ask users information just "why not"?
I mean, the thinking process is like:
- Okay, we need a sign up form
- Let's make users table
- Okay, first name, last name, password, email
- Okay, now let's make the form: first name, last name, password, password confrimation, email
While some apps just ask your email even without password :)
Of course if business needs those fields, then yeah. Just when developers work as businessmen, they tend to ask too much.
On a fundamental level, though, the actual datapoints that you gather through a form have nothing to do with UI or arguably even UX design.
That notwithstanding I fully agree with you on all points! GDPR is also very strict on what you can register, how you can use this data, and how you should inform the "data subject" (person) of what will happen with this data once they have sent it in.
I think of this as coupled with the "paged" form suggestion, if you actually need this much information, page it out into individual information blocks instead of one looooong form.
Back in 2009 there was a 5-minute Apple video "how to design great apps" that focussed on empathy and a precise goal (app definition statement). It disappeared from the website somewhen. Am pulling my hair out for not having a backup. Hints anyone?
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...
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!
> 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.
> … 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.
> When I google something related to programming and find an article without a date, there is no point in reading it because you cannot be sure that it is not outdated.
But the book itself doesn't have its publication date anywhere!
I'll tell you honestly that when I done some review of people sites on Twitter, I really saw quite a lot of common sense mistakes.
1. Grouping is the first one.
2. Text is the second (contrast / small size / line-height / headlines etc)
3. Poor forms (validation, no masks, no help for user)
So yeah, there is nothing that complex about UI, it's not nuclear physics. Less clicks, less actions, understandable, VISIBLE interfaces
I have arguments with people about this fairly often. Common sense is learned, not common.
I think what happens is that if you get lucky, and learn a mental model for the underlying system that better explains the process you're following, it becomes indistinguishable from "reality" and appears "common sense". If you get really really lucky, someone teaches you (or you spot it), really young.
That's why things like this PDF are so important. It applies especially to areas in which we may not have learned "common sense" (like typography, or even basic Usability).
One of the seminal books in my canon is "The Simplicity Shift,"[0] by Scott Jenson[1] (who used to run Google's Mobile UX team).
He wrote that in the era before smartphones, and it was all about brutally triaging UX priorities for a limited mobile user interface.
155 comments
[ 2.7 ms ] story [ 191 ms ] threadWell, UX and UI often goes together. I like more to talk about "interfaces" in general.
Pure UX for me is making research, personas, usability testing and all that.
UI Design is a subset of UX, as the UI is one (major) factor that shapes the user's experience of your product.
So saying 'this book is more UX' somehow implies UX and UI are separate - which they are not.
This book covers several UX disciplines, including some UI design tips.
Thank you!!
This way I learn. And I do mistakes too. Just skimmed through the book and found a mistake (in the "increase clickable are section" the cross icon on the second picture don't have increased area -_-)
Later I'll make a better book, this was my first try.
It was easier for me to put it in Sketch and export as PDF, rather then making HTML
The typical defence against custom-styled links is that blue-underlines look 'ugly'. Whilst this sounds initially like a poor argument, if you reword 'ugly' as 'distracting', you start approaching a good UX argument.
Maybe the equivalent of such 'self links' is the convention around fragment identifiers and elements with IDs that sites 'expect' that you might want to link to — e.g. headers. Typically, when you hover over such a header, you'll see a ¶, or similar symbol, which is linked to that ID.
On twitter.com listings, the entire tweet is now a link to the individual tweet page — was that always the case? It's not perfectly discoverable, of course, but it's pretty good. Hmm... I've just realised that's also not a proper link, of course...
:)
Another great book about webdesign is https://www.refactoringui.com/book (by the Tailwindcss creators)
A more pertinent question should be, what does refactoringui contain that is 5x more valuable than the "average book"
But yeah a bit expensive though :)
It. Is. Not.
The more companies and people I had been working with, the more I started to see that most of the UI design (or for that matter, displaying information on a UI / document / advertisement) what I thought had become "common sense", hadn't. Most of my colleagues cannot properly position / color a button. Cannot structure a document (headers, tables, bulletpoints) to be easily comprehensible, consumable. Struggle to summarize information in an email.
This 50 UI tips is great! Thanks for this. I will share as a baseline with my team.
[1]: I can't find which one. Maybe its title was something different.
My old HP Deskjet 500C came with a thin book(let) titled "How to Use Color". It tells all the basics and then some for effective color documents and presentations. I hold on to it like it's gonna save my life. It's that good.
Hmm, Maybe I should scan it...
The most (!) common thing that I notice is wrong grouping/spacing.
Literally, I went to another site about covid, and they had a chart. And 2 checkboxes that enables 3 or 7 days moving average.
But you'll never guess which checkbox enables which MA, they are too close to each other.
Same happens with forms. I'm like "is it too hard to add margin-bottom: 10px" :)
(1) Since people were less familiar with computers back then, the way that things (like the cursor and drag-and-drop) are explained in this guides tends to be more explicit. Being re-introduced to concepts we take for granted is refreshing and helps with coming up with new concepts rather than just being confined to what we already see around us.
(2) Seeing what advice still applies decades later is a great way to figure out which pieces of advice are timeless and universal.
For example, if you need to show me on a website my CBU, international account number which is 24 numbers long, please, don't show them like this:
345234234665232423247322
Show it instead like this:
3452 3423 4665 2324 2324 7322
It is much much easier to read.
90~95% of the time were numbers (or even characters!) are listed, nobody splits them.
This I learned in Isaac Asimov's book "Asimov on Numbers" IIRC. Great book by the way.
~I'll edit (or reply) if I can dig up the link.~
Aha. Numderline. h/t @bla3
This was fine when the platforms were separate, but it made it impossible for websites to have a uniform standard. At best, consumer websites follow Apple guidelines while enterprise, government, and SAAS sites follow Microsoft.
I bet you can find it, or something similar, there.
Yeah, just a collection of tips. I'll write a real book later, this is the first try of writing at least something :)
Love it! Thanks for sharing!
Thank you!
This is why I don't understand terraform's convention of aligning all equal signs. It looks nice as a block of text but it's a lot of unnecessary cognitive effort to follow the invisible line between an attribute and its value.
[1] https://github.com/prisma/docs/blob/main/content/200-concept...
While I don't agree with their views it may shed some light on where they are coming from.
I couldn't really put into words why this column style formatting bothers me so much for this type of data, but thanks to one of the comments there I think I do now: this information belongs together horizontally, but it is formatted in a vertical manner which takes more mental processing.
The comment: https://github.com/prisma/prisma/issues/90#issuecomment-5175...
At first I put the book under the email wall, but I thought that I'll just publish the direct link.
Those who want to subscribe, will subscribe :)
P.S. If anyone interested I don't sell any ads or whatever, just send UI stuff as I learn
Hints on spacing, layout, text formatting, etc. are largely trivial, but there's probably value in verbalizing them for people who are just starting up. However, it would've probably been better - for a book - to "group logically related elements" together instead of having them scattered around the place.
There are some less obvious items that pick up on right things, but what prompted me to comment is that many "hints" don't apply universally and are highly context-specific. There also some that are way off.
From the "way off" department -> Make links look like links
In general, yes, but the Twitter example given shows that the OP doesn't grok why it's done that way. UI elements have UX priorities. If you give prominence to all actionable elements regardless of their importance, you will end up with a circus. And if you tuck them away behind an expander or a burger, then you hinder the usability. So the common "trick" is to de-emphasize secondary elements, yet keep them discoverable. Just like Twitter people did it here.
> Consider removing confirmation modals
This makes no material difference - it's either user mindlessly clicking on "Confirm" or being retrained to mindlessly click on "Restore". Potato-potata, just looks different. Besides there's also an in-place modal-less confirmations.
> Submitting verification code
Oh, don't you dare. Stripe does this (auto-submits the form on the last digit entry) and it is exceptionally annoying. People make typos, including the last digit. Allow for that.
From the "don't apply universally" department - pretty much everything that's form related:> Don't hide form tips
> Require fewer fields
> Use labels instead of relying on placeholders
> Use reasonable width of inputs, the splitting date into three fields part
> Don't use complex forms in modals
This squarely depends on the form. It's one thing if I am trying to convert a visitor into a user and another if I am trying to make a back-office data entry person happy.
All in all, it's a solid domain name, with a good potential; the list itself is OK if a bit random and in a need of some clarification.But the PDF is neither a book nor is it about UI per se.
Even thought tips about e.g. colors/contrast are trivial, as I know ~90% of sites fail to the AA requirement (cannot provide proof but I remember I saw a table with such data).
Even hacker news has its posts too close to each other, in my opinion.
Regarding twitter - isn't it an important action to get to the tweet? This thing I always needed, plus I asked few people. So I even used third party services just to get to the link to the tweet. In my opinion it's almost the most crucial one, I'd add a button "View the tweet" or whatever.
Working on focus is important, but not that you won't even guess that the function exists
Anyway, this is my first try, bare with me :) I'll make another one, this time really a "book". This one is made out of my tweets, so I didn't put that much effort.
P.S. I think I called it a book for getting attention. On the cover it says "50 tips".
I only think the reasoning you provide in the "require fewer [form] fields" chapter is really out of place. For example, whether or not to require an email for demo-signups is a business-level decision that might tie in directly with your sales strategy.
I mean, the thinking process is like:
- Okay, we need a sign up form - Let's make users table - Okay, first name, last name, password, email - Okay, now let's make the form: first name, last name, password, password confrimation, email
While some apps just ask your email even without password :)
Of course if business needs those fields, then yeah. Just when developers work as businessmen, they tend to ask too much.
That notwithstanding I fully agree with you on all points! GDPR is also very strict on what you can register, how you can use this data, and how you should inform the "data subject" (person) of what will happen with this data once they have sent it in.
Maybe move these two sections together?
Back in 2009 there was a 5-minute Apple video "how to design great apps" that focussed on empathy and a precise goal (app definition statement). It disappeared from the website somewhen. Am pulling my hair out for not having a backup. Hints anyone?
> 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...
Such a feedback! Thank you!!
I'll take all that into account. Btw, regarding grammar, obviously grammarly didn't help me but I tried as much as I can.
> 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?
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!
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.
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.)
The php.net front page should certainly not have autofocus, though perhaps https://www.php.net/search.php could.
> … 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.
> Don't forget to put the post date
> When I google something related to programming and find an article without a date, there is no point in reading it because you cannot be sure that it is not outdated.
But the book itself doesn't have its publication date anywhere!
Nice one. Indeed :) Gosh..
Awesome, thank you!
As noted below, most of this is “common sense,” but there’s a saying:
“Common sense. So rare, it’s a God damn superpower.”
https://www.joeydevilla.com/wp-content/uploads/2007/12/commo...
1. Grouping is the first one. 2. Text is the second (contrast / small size / line-height / headlines etc) 3. Poor forms (validation, no masks, no help for user)
So yeah, there is nothing that complex about UI, it's not nuclear physics. Less clicks, less actions, understandable, VISIBLE interfaces
I think what happens is that if you get lucky, and learn a mental model for the underlying system that better explains the process you're following, it becomes indistinguishable from "reality" and appears "common sense". If you get really really lucky, someone teaches you (or you spot it), really young.
One of the seminal books in my canon is "The Simplicity Shift,"[0] by Scott Jenson[1] (who used to run Google's Mobile UX team).
He wrote that in the era before smartphones, and it was all about brutally triaging UX priorities for a limited mobile user interface.
It taught me a lot of common sense.
[0] https://jenson.org/The-Simplicity-Shift.pdf
[1] https://jenson.org