[HN Gopher] Show HN: I wrote a book about UI [pdf]
___________________________________________________________________
Show HN: I wrote a book about UI [pdf]
Author : Akcium
Score : 365 points
Date : 2021-05-19 15:26 UTC (2 days ago)
(HTM) web link (fifty.user-interface.io)
(TXT) w3m dump (fifty.user-interface.io)
| 12ian34 wrote:
| 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.
| Akcium wrote:
| Reminded me this
| https://twitter.com/vponamariov/status/1394692100239855617
| kmarc wrote:
| 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.
| bobbyT314 wrote:
| 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.
| zczc wrote:
| 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
| kwanbix wrote:
| 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.
| specialist wrote:
| 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
| bla3 wrote:
| Maybe https://blog.janestreet.com/commas-in-big-numbers-
| everywhere... ?
| eatonphil wrote:
| That is awesome. Thanks for sharing.
| da39a3ee wrote:
| It's sad to say, but there's a strong correlation between
| "good programmer" and "formats things in fixed width using
| ``` in slack".
| machiaweliczny wrote:
| Is it possible to split with CSS so that when copied it won't
| have spaces?
| 4lun wrote:
| 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/
| radley wrote:
| 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.
| tarsinge wrote:
| [1] my favorite is the Macintosh Interface Guidelines from
| 1992: http://interface.free.fr/Archives/Apple_HIGuidelines.pdf
| szhu wrote:
| 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.
| javahippie wrote:
| Was it "The humane interface"? by Jef Raskin? He was heavily
| involved in the creation of Macintosh and the book is a great
| read.
| bayindirh wrote:
| Apple has an old in-house document for UI designs, he might
| be referring to that one. I shall have a copy somewhere.
| formerly_proven wrote:
| 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.
| bayindirh wrote:
| 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...
| Akcium wrote:
| 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" :)
| chompychop wrote:
| 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?
| lancebeet wrote:
| 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.
| ska wrote:
| 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.
| gnrlst wrote:
| 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.
| Akcium wrote:
| 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 :)
| krono wrote:
| 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.
| Akcium wrote:
| 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.
| krono wrote:
| 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.
| Ensorceled wrote:
| 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?
| rammer wrote:
| Thanks for sharing, Very well written
| codegeek wrote:
| I ended up reading almost all of it. Very impressive work indeed.
| Precise and useful tips.
| Akcium wrote:
| 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 -_-)
| rammer wrote:
| Thanks for sharing, beautifully written book
| kmgb wrote:
| 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.
| ElectricMind wrote:
| 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?
| oneeyedpigeon wrote:
| No-one mentioned the "sky fall[ing] down", the OP
| specifically said "it sounds awkward" which is a very light
| criticism.
| Akcium wrote:
| !! 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 =(
| dormento wrote:
| 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 usuario"
| 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".
| interestica wrote:
| 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-...
| makotoNagano wrote:
| "If the user wants to do this, they will do this" - perfectly
| acceptable. "They" and "them", can be plural and singular.
| Akcium wrote:
| Never knew! This sounds weird for me, because teachers
| taught us that they/them used only for plural.
|
| Superb, thank you!
| [deleted]
| quitethelogic wrote:
| 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.
| langitbiru wrote:
| 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."
| JJMcJ wrote:
| And "they" uses singular verbs, for the most part.
|
| "If the user wants"
|
| but
|
| "If they want"
| zacharycohn wrote:
| "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?"
| alexcnwy wrote:
| Very helpful, thank you!
| fluffyllemon wrote:
| Nice!
|
| I saw two typos, I think:
|
| p.51 traction of seconds -> fraction
|
| p.24 first input input
|
| Thanks for sharing
| sva_ wrote:
| Little visual artifact: p.45 the "Select Language" label
| doesn't look to be centered right, which I think it should.
|
| Nice list though.
| tuxie_ wrote:
| 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!
| Akcium wrote:
| Yep! Good idea. I have many ideas, so I hope that by the end of
| the year I'l implement them all
|
| Thank you!
| tuxie_ wrote:
| 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! :)
| valuearb wrote:
| No one is going to follow these rules.
|
| They make too much sense.
| victor106 wrote:
| 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?
| devops000 wrote:
| 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?
| bennyp101 wrote:
| 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
| Akcium wrote:
| 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!".
| nathias wrote:
| great stuff
| Akcium wrote:
| Thanks!
| typon wrote:
| 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!
| Akcium wrote:
| Ha, thank you :)
| mro_name wrote:
| 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?
| tored wrote:
| Looks great, but does this book follow its own first rule of
| headlines? Distance looks quite big, however I'm not a designer.
| Akcium wrote:
| I constantly make mistakes too =( We're humans after all
| chrismorgan wrote:
| 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.
| brailsafe wrote:
| 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.
| Akcium wrote:
| 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.
| oneeyedpigeon wrote:
| > 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.
| ddek wrote:
| > > 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?
| chrismorgan wrote:
| 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!
| tuxie_ wrote:
| 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.
| krono wrote:
| 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...
| tuxie_ wrote:
| 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.
| krono wrote:
| 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#iss
| uecomment-5175...
| monkeydust wrote:
| 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.
| the_other wrote:
| 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.
| mrweasel wrote:
| 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.
| Akcium wrote:
| The best UI = No UI :)
| monkeydust wrote:
| I'll buy that T-shirt!
| intrepidhero wrote:
| 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-Exupery, Airman's Odyssey
| croes wrote:
| 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.
| Ensorceled wrote:
| I really like this format: simple, concise, actionable combined
| with very clear examples.
| Akcium wrote:
| This is because my friend told me to remove all that text I had
| before :D
| janjones wrote:
| 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!
| Akcium wrote:
| Ha! :D
|
| Nice one. Indeed :) Gosh..
| julienreszka wrote:
| Why is this in a PDF tho?
| Akcium wrote:
| Well... I don't know :D
|
| It was easier for me to put it in Sketch and export as PDF,
| rather then making HTML
| Ensorceled wrote:
| So I could drop it into my Books folder, of course!
| dutchblacksmith wrote:
| Thanks, these are good tips, I am going to change my current
| project.
| Akcium wrote:
| If you're on twitter, https://twitter.com/vponamariov, you can
| share the result with me =)
| yoz-y wrote:
| 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?
| oneeyedpigeon wrote:
| 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 P,
| 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...
| the_other wrote:
| 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.
| [deleted]
| Akcium wrote:
| Thank you for your feedback! Any feedback is good and I'll take
| everything into account for my future books :)!
| Ensorceled wrote:
| 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.
| jeanlaf wrote:
| Honestly great work on the format! You can easily skim through
| and understand all your points by looking just at the graphics.
| Akcium wrote:
| 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"
|
| :)
| sthottingal wrote:
| 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.
| Akcium wrote:
| Sooner or later I'll do the catalogue of the tips that I'll
| fill from time to time
| itsbits wrote:
| > 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.
| mattowen_uk wrote:
| 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'.
| bruh2 wrote:
| > 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
| flowerlad wrote:
| 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.
| godfreyantonell wrote:
| 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.
| Akcium wrote:
| Thank you.
|
| Later I'll make a better book, this was my first try.
| catchmeifyoucan wrote:
| I think this book is more UX, but it has a good set of basics
| that I can agree with.
| Akcium wrote:
| 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.
| uxcolumbo wrote:
| 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.
| z5h wrote:
| As an ex-"backend-only-ignore-ux" developer, I find this quite
| helpful. Excellent work. Thank you.
| cjsawyer wrote:
| I'm a big fan of the simple, one tip per page layout
| progx wrote:
| Absolute standard work that every designer and developer should
| have read!!
|
| Awesome, thank you!
| Akcium wrote:
| thank you for the kind words!
| math-dev wrote:
| 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
| Akcium wrote:
| Sooner or later I'll do that. Thank you!
| [deleted]
| webwielder2 wrote:
| Non-snarky question: why isn't this a web page?
| Akcium wrote:
| 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
| specialist wrote:
| 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.
| alexanderisora wrote:
| 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.
| Akcium wrote:
| 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
| [deleted]
| pabe wrote:
| Great book! Thanks for making it available for free.
|
| Another great book about webdesign is
| https://www.refactoringui.com/book (by the Tailwindcss creators)
| Akcium wrote:
| Yeah, partly inspired by them I dived into the UI/UX area.
|
| But yeah a bit expensive though :)
| esel2k wrote:
| 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).
| epow wrote:
| 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"
| ChrisMarshallNY wrote:
| 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...
| Akcium wrote:
| 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
| ChrisMarshallNY wrote:
| To be fair, many sites are based on templates/themes, and the
| site author is often at the mercy of the theme author.
| the_other wrote:
| 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.
| ChrisMarshallNY wrote:
| 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
| abhishekbasu wrote:
| 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.
| Akcium wrote:
| Thank you! :) Glad to hear
| chrisheidorn wrote:
| Really nice work Victor!
| Akcium wrote:
| Thanks!
| pjerem wrote:
| 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.
| Akcium wrote:
| 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..
| pjerem wrote:
| 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.
| polyterative wrote:
| Great work
| oneeyedpigeon wrote:
| > 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.
| Akcium wrote:
| I'm not sure, have been on Mac for ages. But this indeed
| sometimes drives me crazy
| huhtenberg wrote:
| 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.
| Akcium wrote:
| 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".
| taffit wrote:
| 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!
| Akcium wrote:
| Getting positive comments from HN users is priceless!
|
| Thank you!!
| emaro wrote:
| 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.
| Akcium wrote:
| Thank you :) Got your point
| zerkten wrote:
| 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.
___________________________________________________________________
(page generated 2021-05-21 23:03 UTC)