Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: I wrote a book about UI [pdf] (user-interface.io)
411 points by Akcium 33 days ago | hide | past | favorite | 151 comments



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.


One thing that I hardly see implemented is grouping of numbers and strings in 4s or 3s. Like the credit card companies do on their credit cards.

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.


There's a clever font that uses ligatures to achieve what you're suggesting.

~I'll edit (or reply) if I can dig up the link.~

Aha. Numderline. h/t @bla3



That is awesome. Thanks for sharing.


It's sad to say, but there's a strong correlation between "good programmer" and "formats things in fixed width using ``` in slack".


Is it possible to split with CSS so that when copied it won't have spaces?


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/


see your comment siblings, there are some clever font tricks to achieve that too


[1] my favorite is the Macintosh Interface Guidelines from 1992: http://interface.free.fr/Archives/Apple_HIGuidelines.pdf


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.


I agree that a lot of sites don't use the common sense.

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" :)


Was it "The humane interface"? by Jef Raskin? He was heavily involved in the creation of Macintosh and the book is a great read.


Apple has an old in-house document for UI designs, he might be referring to that one. I shall have a copy somewhere.


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.

Hmm, Maybe I should scan it...


Found this: Apple human interface guidelines: the Apple desktop interface, 1987 https://archives.design/post/645150403066003456/apple-human-... https://archive.org/details/applehumaninterf00appl/mode/2up


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.


This is a great list of current, and archival, interface guidelines: http://www.geofcrowl.com/blog/articles/2020/2/17/collection-...

I bet you can find it, or something similar, there.


Thanks! Well done.

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...


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


To be fair, many sites are based on templates/themes, and the site author is often at the mercy of the theme author.


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.

It taught me a lot of common sense.

[0] https://jenson.org/The-Simplicity-Shift.pdf

[1] https://jenson.org


I liked the points you raised, I think they serve as a good checklist for the finer details of designing UI.

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.


!! Thank you for this detail.

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 =(


Thanks for doing/sharing this. It's a great resource.

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-...


Every language has its quirks. "They" works in this case, at least in english. You can say "After they sign up". You can also say "After the user signs up", just beware the repetition.

--

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".


https://english.stackexchange.com/questions/48/is-there-a-co...

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."


And "they" uses singular verbs, for the most part.

"If the user wants"

but

"If they want"


"They" has been used as a singular since the 1300s. Example: "a person knocked on the door, but I missed them. Do you know what they wanted?"


"If the user wants to do this, they will do this" - perfectly acceptable. "They" and "them", can be plural and singular.


Never knew! This sounds weird for me, because teachers taught us that they/them used only for plural.

Superb, thank you!


I am a native English speaker and they/them being used in this way has become more accepted and recommended over time. I was taught explicitly not to do this when I was in school, but that was a few decades ago. Using he/him when gender is unknown or unimportant is regarded as exclusionary. Usually, it'a not an issue, but I find it does sometimes make things more difficult to parse or understand without additional context. In this case, there aren't really any drawbacks.


Some people will never let go "Gender" out of anything good. Does sky fall down when the book says "him/he"? Does message not delivered? Is book about "Gender" study?


No-one mentioned the "sky fall[ing] down", the OP specifically said "it sounds awkward" which is a very light criticism.


This looks very helpful! Thanks!

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.


Thank you for your feedback! Any feedback is good and I'll take everything into account for my future books :)!


Excellent work! Don't want to pile on because the overall work is excellent; but starting with focus on the first element in the form and the jumping to the first error both break accessibility rules. As a sighted user, I love them, but when I was doing accessibility work it was one of the things we had to remove from the site to be fully compliant.

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.


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.


Oh thank you!

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


Great book! Thanks for making it available for free.

Another great book about webdesign is https://www.refactoringui.com/book (by the Tailwindcss creators)


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).


Presumably we should be judging the price based on the value, not the format it comes in.

A more pertinent question should be, what does refactoringui contain that is 5x more valuable than the "average book"


Yeah, partly inspired by them I dived into the UI/UX area.

But yeah a bit expensive though :)


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.

Maybe move these two sections together?


I have a rather silly question - when designing UI features, how do UI designers test whether a design works as expected/is objectively good, and not just "Oh, this looks good to my eyes, others would probably feel the same way too!"? Off the top of my head, I can think of two ways - (i) have a private test audience, show various iterations to them, get feedback, and choose those features with highest scores given by the audience; (ii) get feedback from the end users, and make modifications as necessary. However, I'm guessing (i) is an expensive and time-consuming route, whereas (ii) could potentially lead to poor user experience and be detrimental for user retention. Is there a better way? In short, what's the "unit testing" equivalent in UI design?


That's not a silly question at all! There is an entire field of study around usability and human factors, better UI designers integrate at least some of this stuff into practice.

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.


You can also measure the end-user behavior without them knowing it. Metrics like "how long did it take users on average to fill in the form?", "how many received validation errors on this particular field?" can be used as proxies for how good the design is. Of course, this is only really an option for web applications.


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!


Getting positive comments from HN users is priceless!

Thank you!!


Nice points but honestly truth be told I am a bit fed up with UIs.

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.


Having no UI is an insight more developers should embrace. Getting a UI/UX design right is extremely hard for small systems and down-right impossible in larger ones.

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.


I think this is why I hate 2FA.

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.


I feel like the 0th rule of UI design is only build the minimal features necessary.

“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


The best UI = No UI :)


I'll buy that T-shirt!


No 51

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.


Thank you :) Got your point


They missed a most important point. If this was HTML it would be easier to enable linking to specific tips. This is important for pointing people to a specific tip instead of having to open the PDF and search.

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.


This is fantastic! I love it, learnt a few things, the line height one was new to me. And I never thought about putting all the password rules with their state below a form. Thanks!

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.


I 100% agree with:

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'.


> Put frequently used options on top

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


Really interesting, easy to read, thank you. :)

> 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.


The idea is that sometimes people overuse them. Like, putting borders EVERYWHERE.

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..


I do agree with you, but I have a real issue with the current trend of UIs where everything is just text & icons thrown on the same panel (like here in HN, or the latest macOS). I tend to miss the old paradigms where applications had/tried to respect a minimum of visual consistency with others and things such as OS-wide theming allowed to adjust ALL applications to your taste and visual abilities.

btw, you won a subscription to your website.


Also:

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 use a serif font for large blocks of text.

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.


Miscellaneous feedback from skimming through:

> 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.


> 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.)

The php.net front page should certainly not have autofocus, though perhaps https://www.php.net/search.php could.


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!


> > 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.)

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.


Woah!

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.


Wonderful write.

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?


> Especially on MacOS, when the scrollbars are hidden.

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'm not sure, have been on Mac for ages. But this indeed sometimes drives me crazy


> Use labels instead of relying on placeholders

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.


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! :) Glad to hear


I hate centered text blocks. Makes me unnecessary scroll vertically for longer texts. Gets worse for code listings and the center column layout. Had to deal with websites where I needed to scroll horizontally to view the right most part of the code and at the same time the page was two thirds blank.


As a recovering UI designer, weary of UI advice, this collection of 50 heuristics is solid. Nicely done. Great presentation too.

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.


Useful tips, decent illustrations, strongly focused (~60%) on web form tips. Also, on p18 "Show password rules right away", I would change this to "Remove the requirement for so many pointless password rules" encouraging people to focus on entropy through length.



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...


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.


Agreed. I think I made the title so that it's a clickbait... while on the cover is says 50 tips.

Yeah, just a collection of tips. I'll write a real book later, this is the first try of writing at least something :)


Page 16: Place input labels correctly.

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 :)

[1] https://github.com/prisma/docs/blob/main/content/200-concept...


Interesting, I just found this discussion on the subject: https://github.com/prisma/prisma/issues/90

While I don't agree with their views it may shed some light on where they are coming from.


Good find, thanks for sharing the link.

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...


Last tip:

> 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!


Ha! :D

Nice one. Indeed :) Gosh..


I ended up reading almost all of it. Very impressive work indeed. Precise and useful tips.


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 -_-)


Looking at the left hand side examples of what not to do triggered irrational anger in me because of the associated negative memories of using UI that hit almost everyone of these bad examples. Thanks for this book!


Ha, thank you :)


Absolute standard work that every designer and developer should have read!!

Awesome, thank you!


thank you for the kind words!


Could you add some information about what to write in the placeholder (input form) ?

Example: Email -> "john@company.com" or "enter your email here" or else?


This is the question I don't know myself how to answer.

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!".


I like to use the details of the company, so if the placeholder is for a a phone number, I'd put the company phone number in as the placeholder. Same for email etc. It's useful to see how you want the user to style the input, but with 'real' data not a '0000 0000-0000' kind of thing


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


Sooner or later I'll do that. Thank you!


This is great! Have you considered an html version of it? I can see myself sending links to people pointing them to a specific tip.

Love it! Thanks for sharing!


Yep! Good idea. I have many ideas, so I hope that by the end of the year I'l implement them all

Thank you!


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! :)


Thanks for this. I learned a few new tips. If it is not too much work, a web version of this will be helpful. Also for search engine friendly.


Sooner or later I'll do the catalogue of the tips that I'll fill from time to time


Looks great, but does this book follow its own first rule of headlines? Distance looks quite big, however I'm not a designer.


I constantly make mistakes too =( We're humans after all


From the pdf

> 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?


Honestly great work on the format! You can easily skim through and understand all your points by looking just at the graphics.


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"

:)


Good job. At the end of the day, you just need to go for it. I am inspired to get off my duff and improve my life.


Thank you.

Later I'll make a better book, this was my first try.


As an ex-"backend-only-ignore-ux" developer, I find this quite helpful. Excellent work. Thank you.


I really like this format: simple, concise, actionable combined with very clear examples.


This is because my friend told me to remove all that text I had before :D


I think this book is more UX, but it has a good set of basics that I can agree with.


UX = User Experience. It's a broad term that covers many disciplines.

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!

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.


Thanks, these are good tips, I am going to change my current project.


If you're on twitter, https://twitter.com/vponamariov, you can share the result with me =)


Non-snarky question: why isn't this a web page?


Honestly?

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


I’m a big fan of the simple, one tip per page layout


No one is going to follow these rules.

They make too much sense.


Thanks for sharing, beautifully written book


Nice!

I saw two typos, I think:

p.51 traction of seconds -> fraction

p.24 first input input

Thanks for sharing


Little visual artifact: p.45 the "Select Language" label doesn't look to be centered right, which I think it should.

Nice list though.


Thanks for sharing, Very well written


Very helpful, thank you!


Really nice work Victor!


Thanks!


Great work


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.


Thanks for your critique.

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".


Why is this in a PDF tho?


Well... I don't know :D

It was easier for me to put it in Sketch and export as PDF, rather then making HTML


So I could drop it into my Books folder, of course!


great stuff


Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: