Show HN: I wrote a book about UI [pdf]
fifty.user-interface.io
fifty.user-interface.io
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.
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.
One critique I had when I was reading through is the use of he/him when referring to a hypothetical user. This is likely region-dependent, but it sounds awkward to me to assign gender to an unknown user.
Some authors prefer they/them and some (more rarely) prefer an equal number of masculine and feminine pronouns.
Great work, nonetheless.
The problem is that I'm not native speaker. Could you tell me, if it's correct to say, e.g.
"If the user wants to do this, they will do this"
I mean, if I need to use a single, not plural, how to properly refer to ... him/her?
I put him all the time because "a user" in Russian language has a gender, while in English it doesn't have a gender.
I'm always confused about this.
For example, "Imagine you have a user who wants to sign up. After (___) sings up"?
Please, give me advice here, this is really a problem =(
Superb, thank you!
--
In portuguese, "the user" has a gender as well ("o usuário" i.e. "(the male) user"). We usually ignore linguistic gender in most places, which causes all sorts of confusion to people coming from countries where nouns are "un-gendered".
And yes, it's absolutely correct to go with "...they will do this" when referring to a hypothetical genderless user. Defaulting to 'he/him' (and presuming a gender) is less and less acceptable.
>"Imagine you have a user who wants to sign up. After (___) sings up"?
"After they sign up, ..." works there and can be used to refer to the singular person. Just make sure the verbs agree ('they sign' vs 'she signs').
One other thing I'd note: you'll almost never hear a native English speaker use the phrase "fill the form".
Now, whether a person opts for 'fill in' vs 'fill out' is another question and seems to vary by english region.
https://english.stackexchange.com/questions/1514/fill-out-a-...
You can use "they" as a singular pronoun.
You can use "one" like: "if one wants to do this, one will do this."
You can use "his or her" like: "if the user wants to do this, he or she will do this."
Some writers like to rotate "he" and "she". So sometimes they write "if the user wants to do this, he has to do this first." Then later, in another paragraph, the writers write, "The user doesn't like this widget. She prefers that widget."
"If the user wants"
but
"If they want"
The entry called "Place input labels correctly" is vital, in my experience. I'm partially sighted and use screen zoom and pan&scan a lot. This workflow magnifies any of the problems an average sighted person would have with things like line-lengths, horizontal grouping, etc. Zoomed in, it's often *impossible* to see the form control linked to its label; then when I scan across to find the control, I can't see the label. I have to zoom out to see the association, but then I can't read the label and need to rely on memory, or counting the lines of controls up/down from some known fixed point.
Even Apple and Google's Material Design get this one wrong often (by which I mean *every list of controls they have made in the past 4-5 years). Most modern "list of controls" interfaces (iPad settings, browser settings, Material lists, and many others) force justify the label and control to the far edges of the screen.
---- addition -----
I disagree strongly with "Autoscroll to the first error in large forms". Personally, I find autoscroll abhorrent. It totally messes with my orientation, my sense of 'where am I": tell me where I went wrong, but let me drive my point of focus. I think it would be much better to keep the user at the same place, but to add meaningful feedback at that point: list the problems, with links to the place where the problem occurred , rather than scrolling them to get there. Autoscroll sits with the other bad UX devices like variable height adverts and carousels at the top of pages that cause the content below them to move up and down; and page headers that snap to the top as you scroll up but also change size when they do this. They make me angry, but also just on the edge of physically sick. The older I get, the worse this physical sensation of sea/sickness seems when devices trigger unexpected foreground motion.
Sorry, I went off topic to let out some UX frustration. Hopefully this'll seed useful conversion but sorry if it comes across as vomiting design bile.
A lot of your other items take view-ability into account are very much required for accessibility, so you may want to caveat those two items.
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
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 :)
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?
Sometimes it's required because you are in a regulated market: if you are designing a nuclear power plant or a radiotherapy machine or whatever, you are probably required to do some work to show your user interfaces are confusing in a way that can cause dangerous results.
Some of this stuff is expensive, you are right; on the other hand it follows a similar ramp up to other development work - namely that the later you discover something the more expensive it is to change.
Thank you!!
It is just a thing to get from an intention to insight or execution of an action.
I spend a lot of time with UX designers debating a lot of things in this doc, there are of course standards that reduce friction and help us get to decisions quicker but I much prefer investing time to get rid of the UI in the first place if possible through automation.
For example if output from one UI interaction is an input to another UI and the human actions across those UIs can codified into rule(s) then you can start to get the knife out and really reengineer your business processes.
Obviously this takes some serious commitment but the payback can be huge.
When you have simple problems try not to overthink them and avoid designing or adding feature that will lead to the need for more UI interaction.
I worked on simple problems (e-commerce) where we added different purchase options, payment methodes that would only be preferred by a tiny minority and weird shipping companies. It complicated everything, just so we could have options only a few percentage of users would care about. It generated a ton of work for support. The main question was: “Don’t people read?” No, mostly they don’t. Users rely on imagery and visual clues, not line after line of text. If your UI is so complex that people are fequired to read, then you already lost.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
― Antoine de Saint-Exupéry, Airman's Odyssey
I know it keeps me and my stuff a little safer, but it's very uncomfortable, too often. The Apple one is the worst because most of the time the one-time code is on the same screen on the same device, but through a different service.
Use HTML when you share content on the internet, so the users client can decide how it should be displayed (font size, text flow, aspect ratio).
Use PDF only if the content will be printed or pixel-perfect design is needed (it probably is not).
---
I like most of the advice, nice work.
It has other benefits if the links go to different pages in that you can perhaps assess what is important too through logs or analytics. You can then consider refining tips that are less popular.
One note, and I'm not sure this one is in - 'Don't rely on dots in gallery sliders'
For the last image, left and right buttons on galleries, I prefer it so the left and right buttons are near each other somewhere (below the image on the right usually) so if you have to go left and right, there's not much distance to move the mouse. I'm not sure that's a major note though.
You don’t need the password confirmation since he can restore it via reset password form.
I don't know about anyone else, but I just Ctrl-A,Ctrl-C, then Ctrl-V the password into the confirmation box, thus totally defeating the whole point of it being there.
But I DISAGREE with the example used for this :
Put frequently used options on top
The example given is a countries list that has the USA at the top, then all the countries below it in alpha order. This is offensive to anyone who isn't in the USA - it basically screams 'we made this app/service for Americans, you global users need not apply'.
Yes! I was thinking the same thing. I would expect the author to suggest automatically guessing the user's location instead of blindly placing your own country at the top.
The rest of the document is precious, though
> Consider removing borders
Don't this rule goes against good contrasts levels ?
Yes, hard high contrasted borders are bad (& ugly), but with my astigmatism, I tend to prefer interfaces with subtle "soft" borders and clear separators rather than background color differences which tends to be some low contrast color over another low contrast color.
Even HN does't have border for the background.
So of course sometimes they are okay. Bad thing is that when you have too many lines. E.g. if you have a bordered table, bordered table filters, bordered buttons, bordered icon buttons etc..
btw, you won a subscription to your website.
Please use a serif font for large blocks of text. Why do you think The New York Times uses a serif font for body text? It is more readable. Can you imagine NYT in a sans-serif font? It would be ugly and harder to read. Sans-serif fonts are good for headlines and small snippets of text. On low res screens sans-serif fonts may be more readable even for body text, but 96dpi screens are relics of the past at this point.
Even more important: Don't add inter-character spacing for body text. It just makes the text harder to read. I am looking at you, Microsoft Edge. Edge has a "Immersive Reader" button for rendering web pages with just the text and important photos. Great feature, but the font they use has too much gap between individual characters, which makes the text hard to read. And better readability is he point of Immersive Reader! Then they added themes to change the background color, but you can't change the font.
Please don't.
> Why do you think The New York Times uses a serif font for body text?
Because they come from a print medium where serif fonts are the norm.
> 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.
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.
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?
Do other OS not do that? It's a terrible thing to do by default — I wish we could convince Apple, (etc.?) to fix their mistake rather than having to work around it.
I manytimes wondered why Material UI made placeholders as mainstream in their design (https://material-ui.com/components/text-fields/#textfield). Small label that comes above when a value is set is not visible easily.
We'd all benefit if much of this advice was default behavior implemented by the UI frameworks.
For example, I once wrote a custom layout manager which had proper line height and label placement built-in.
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...
Yeah, just a collection of tips. I'll write a real book later, this is the first try of writing at least something :)
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...
> 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..
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 -_-)
Awesome, thank you!
Example: Email -> "john@company.com" or "enter your email here" or else?
I wouldn't put john@company.com, at least in complex forms. On the one hand you provide sample data, but on the other hand... for example you'll need to provide a fake phone number, some fake data that is not personal.
I tend to leave inputs empty (while having labels above them!) and only if they have some kind of masks I show the placeholder.
Any hints about how to fill the form I place BELOW the input, so that when user starts typing, they don't disappear.
So looks like I just keep them empty most of the time.
Or, if it's a super simple form (e.g. only email on landing page), I put "Enter your email here". Since it's kind of call to action, like "do this!".
Love it! Thanks for sharing!
Thank you!
> Make links look like links
This is a trade off between making links look beautiful and functional.
What are some ways (and examples ) you can achieve both?
:)
Later I'll make a better book, this was my first try.
Well, 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.
1. I wanted to make a PDF because later on I want to make a big fundamental book that I will sell :) It's kind of practice for me.
2. HTML is harder to make. I mean, decent HTML. The book was made in Sketch, so it's way easier.
3. I use the book for getting emails for newsletter. But for HN I decided to put the direct link, so that the community doesn't have to sign up
They make too much sense.
I saw two typos, I think:
p.51 traction of seconds -> fraction
p.24 first input input
Thanks for sharing
Nice list though.
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.
---
> 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.
---
> 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.
---
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".
It was easier for me to put it in Sketch and export as PDF, rather then making HTML