Great list, but Twitter is really not the best platform for this kind of content. Some of the screenshots have such bad compression artifacts that it's difficult to make out the before/after changes. For example: https://pbs.twimg.com/media/DDf7ef1XkAMh3Gp.jpg:large
This is a much more readable version (though doesn't include the handy CSS annotations):
One of the benefits of using Twitter to publish these tips is having the constraint of 140 characters. This forces me to be creative and simplify the tips down to something that is super digestible. I publish tips regularly and Twitter makes it really easy to share them.
So set yourself a 140 character limit when you write a list on your blog? In this case though, I really wish there was more substance to the list, because I'm finding it a little difficult to see what exactly he means. As another commenter here said: "I wish the author included more info explaining their reasoning." which, of course, doesn't work in a 140 character limit.
My personal opinion is that for-twitter content has always been sub-par compared to for-blog content, at least in my experience, and Twitter is really just useful for sharing links to other content. But that's just my opinion based on my experience. Obviously your experience is very different from mine! Luckily we have a good mix of content, so we can both be happy.
I also find Twitter incredibly difficult to find things on, so unless I happen to check it at exactly the right time (when you post it but before other people I follow post too much), there's a big chance I'll never see it[1]. I also find the way the replies are threaded difficult to navigate.
[1] On HN, popular things stay at the top of the list for a few hours, so the chances of me seeing things here are much higher and obviously submissions like this one mean that I do see the twitter content.
Whatever mechanism makes it likely you'll keep posting is the right one. Thanks a bunch for highlighting some thoughtful approaches to basic design decisions that often get overlooked. The effort is appreciated.
I agree, and clearly we're all grateful that you took the time to write up the tips even if they are on Twitter. Perhaps it's best to treat Twitter as a place for drafts, then take the time to write up a more polished piece after?
This is a great guide/collection! It does a great job for those who know the basics to step up the game, thank you so much.
However, something notable that IMHO is missing is accessibility. This is clearly a DESIGN guide and should NOT be treated as a UI/UX guide. Some of the color in the page for instance don't pass the WCAG 2 AA guidelines, which is a really flexible one, let alone the WCAG 2 AAA (a more strict one). The mid-gray text over white background looks great; but it's quite bad for reading.
I was going to comment on much the same thing; I had to adjust my monitor angle a few times to find a sweet spot where I could actually see what the guy was talking about. Also, a fixed font size in the age of responsive design is a huge no-no in accessibility; as well as, general UI/UX.
Do you mean like using px values instead of ems? If so, don't most rendering engines convert internally to px anyway, rendering ems irrelevant for zooming these days? That was my understanding at least.
em is more important when dealing with allowing fonts to be able to handle going from phones to tablets to large screens; while rendering engines do convert to px on the fly; using em allows them to handle it for the machine it's rendering on. At least that's what I was fed as reasoning a few years back.
I don’t want to start a flame war of any kind here but I did want to state that I very much dislike googles designs, I find their UIs very hard to navigate and generally ‘displeasing’ to the eye.
For colors and contrast, use something like http://paletton.com/ where they have it set up to show a color scheme for multiple types of sighted issues.
For fonts and text; the Google guidelines aren't awful, assuming you're not hand calculating your px and use em (they talk about it, but it's extremely brief).
Or were you asking about something completely different?
Clever or novel often gets precedence in many of these UI collection blogs. It's easy to get caught up in busy-work with design, possibly more so than with programming.
That's why I like UI changes that come with a/b test results. Although sometimes it's hard to measure the right metrics with this stuff, especially when it's entirely qualitative or highly abstract like emotional gratification.
Some of these seem a bit arbitrary. I wish the author included more info explaining their reasoning.
I'd be amazed in all these examples pass a basic accessibility checklist. It's fine to want to add in small design details here and there, but don't sacrifice accessibility to achieve that goal. Personally, I found a lot of the examples a bit difficult to read.
Tips mosyly priviledge prettiness over usability. E.g. advice like "mix background hue into grey text" is why we have so much unreadable, non-contrasting text.
I guess I have an axe to grind because, as a colorblind person, I often feel like "designers" just wish I didn't exist, like user needs are an inconvenience and not _the whole point_. /Rant
" A subtle link for negative secondary actions often works better than a big bold button"
Careful with that one. "Better" and "negative" are in the eye of the beholder. Take it too far and you're into dark patterns or at least a confusing UI.
Mostly good, except the button examples at the end. It is completely backwards to recommend buttons that don’t even look like buttons and then add gray text to make them look even less available!! A list of buttons is just fine.
No, you want the primary action to look clearly like a button and the others to look like secondary links to minimize cognitive load. A list of button-like shapes that do wildly different things is not good UX.
There is a lot more "cognitive load" when I wonder why something that I need is apparently disabled, or when I can't even find an option because it is being presented in a way that doesn't remotely resemble something that should trigger an action. Consistency counts too.
If a button is "dangerous", it can be dealt with in other ways, such as:
- More space from other buttons
- An ellipsis "..." to indicate to the user that a confirmation will appear (making it more "safe" to experiment with the button)
> I wonder why something that I need is apparently disabled
That is also bad. It's not a choice between two bad things.
> I can't even find an option because it is being presented in a way that doesn't remotely resemble something that should trigger an action.
Then we should not do that either! One solution is obvious links, which are known to trigger events, for secondary and/or tertiary actions.
The list of buttons in the examples is not good.
- More space doesn't address the problem (and after some amount of space it stops being a single "list of buttons" as opposed to multiple buttons strewn across the interface).
- An ellipsis does signal a confirmation, but that is not the problem being addressed.
- The buttons already have different colors in the "before" images. That is how the problem is presented.
I don't know. The specific examples are obviously adapted to current-day webdesign styles. But the general guidelines and direction to take on improving details on today's webdesign styles seem to me exactly the same as webdesign 10 years ago (weight, colour, shading, hierarchy, white/spacing, balance, affordance, it's all there).
There's only maybe one or two examples that wouldn't be applicable 10 years ago because we didn't use those stylistic elements. Like putting a coloured line at the top of your page for a splash of colour. That wasn't part of the shiny-button web2.0 style back then :) However, I remember reading design-tips back then and "add a splash of colour" was definitely part of the tips, just used a different trick to implement it that fit the design of the era better (use coloured headings, for instance).
A lot of great little tricks are included here, many that I never noticed until this pointed them out and now I can think of multiple places where specific things are in use. Bookmarking this for future design work.
At our firm we had used a few of the examples set out in this article. We stumbled upon them by trial and error. It is good to see them formalised here.
This is a much more readable version (though doesn't include the handy CSS annotations):
https://codepen.io/tyrellrummage/full/ZJPXgy/