"Dark mode was one of the most requested features for Lighthouse. I refrained a long time from adding it because it adds additional work to every UI task."
This reveals a lot about the regression in OSes. Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.
I think the major Unix GUIs offered something similar. Meanwhile, Apple's vaunted UI was crippled by hard-coded colors everywhere.
Fast-forward what, 20 years? Everyone finally realizes that inverse color schemes (black text on a white background) SUCK. But what does Microsoft do? REMOVE the color-scheme editor from Windows.
We're still running around trying to deal with a "problem" that was solved 25 years ago. And, as a developer, I can tell you it has been pretty shambolic on Apple platforms. I guess you can say they never understood proper color management, but... damn. So many broken controls in iOS after "dark mode" was first added. A massive design and QA failure.
It was barely usable. Many developers used the colors of the default theme no matter what. Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background. Trying to use what we now call dark mode was a big no. At best you could replace the wallpaper by an all-black screen so you feel a little less irradiated by your crt.
“Developers who ignored proper color-palette practices.”
Agreed. Pls vouch for the comment.
"Many developers used the colors of the default theme no matter what"
Which is what they were supposed to do, resulting in usable software that honored the user's preferences. And developers didn't have to dick around with color palettes. Win/win.
"Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background"
Yep, some did. And? If developers issue defective software, the OS should be degraded? What's your point here? Let's say developers somehow mess up sound reproduction: Should the OS no longer support audio playback?
Likewise on Unix-like systems: most things can be covered with GTK and Qt themes, but some GUI programs would use a different GUI toolkit, and occasional developers would assume a dark-on-light theme, setting fixed colors accordingly.
Even TUI color interfaces suffer from that: when programs use colors outside of the 16 (that are rather practical to configure) or tweak (e.g., dim, reverse/invert) those for a particular kind of theme.
An annoying thing is that in most those cases things would have been fine if the developers simply did not touch colors. Even the linked article would have been more legible if it had no CSS, with either the usual defaults or a sensibly configured web browser: now it has a text-to-background contrast ratio slightly below the minimum of 7 recommended by WCAG.
Handing all of this control over look and feel to developers was a major mistake, and we pay for it over and over by having tools we keep having to re-learn, that look and function slightly differently from each other.
I never had a problem building my applications in Visual Studio to respect the system color scheme.
If you're going to set the colors of some elements, you have to set them all. It's not that hard a concept.
I blame the Developer UX.
In Visual Studio, objects might have defaulted to the system color scheme, but if you ever selected colors for your controls, the palette was a collection of hard-coded colors, not system color classes. The IDE gave no indication that by selecting a new color you were forgoing an accessible, system-derived hue, and the documentation I had at the time (Sam's teach yourself ____ in 24 hours) didn't give the kind of cookbook examples I would have needed to keep my own GUIs system-controlled.
The color scheme editor actually worked quite nicely up until the release of Windows 2000 [0]. After that, Windows XP introduced the "Luna" visual style (Uxtheme.dll) with inflexible, hard-coded colors. Most software developers stopped caring about color palettes, and almost all applications started using hard-coded colors in their GUIs. They tested their apps with the few skins preinstalled with Windows XP: Blue, Olive Green, and Silver.
It's not necessarily true, especially if you have a component library and "swappable" themes.
After an upfront investment of setting up the dark and light themes, you can just use your component library and rely on the themes. It's still an investment, but the investment is "constant" and doesn't scale with the number of UI tasks linearly, you don't need to reinvent the wheel, and come up with colors for every feature.
Of course it's a good idea to switch the themes every once in a while, to make sure you didn't miss something, but it's not a huge issue.
Computer makers and users referred to black text on a white background as inverse video. The Atari 8-bits even had a key to toggle between normal and inverse characters when typing (the Atari-logo key). It's even described in the manual: https://www.atarimania.com/documents/atari-800-computer-owne... To quote the manual: "Inverse video is text being shown in dark letters against a light background."
Then came the "desktop publishing" craze and some attempts to make video screens an analogy for a piece of paper. This fails because paper does not EMIT light. Nor is reading black text off the surface of a glaring light bulb all day a good way to work. Useful for previewing printed output? OK. For all work on a computer? Not so much.
And yet, perhaps in an effort to be "different" from character-based systems, GUIs migrated to inverse color schemes as their default (except for Apple's, which was always inverse and offered no color-scheme management... and still doesn't). Throughout all of this and into the current day, applications that focus on art, photography, and video & visual effects have implemented a so-called "dark" UI. That's not coincidence.
> white text on a dark-blue background, because it was deemed the most legible.
Was that really the reason, though? Where did they get that idea? I see variety in the 8-bit computers. Many booted into white or green on black, such as the Commodore PET, but the Commodore Vic-20 was blue on white. The ZX81 was black on white, the Amstrad CPC (Color Personal Computer) was green on blue.
I remember that green-screen word processors were sold as reducing eye strain, when really the reason was that green and amber phosphors were cheaper. That's incidental to the inverse video question, but it throws some doubt on the idea that it was more legible. There may have been some technical motivation.
What are you talking about in the final sentence? Photoshop, for instance, didn't have a dark UI, and as you observe, desktop publishing imitated paper, and art programs would fit into that.
Windows has a high-contrast settings, it turns applications and websites to black-on-white, it works reasonably well (I have it being turned on for some days now), although there are menu items and switch states that are not visible :/
Also the default themes all use black text on bright background for selection which is bad. White text on a dark color is much better but you can change that.
It's nice when there's only a handful of UI controls and they're all system-native. Visual Basic was a godsend.
Want a custom control? Draw one using the shape tool, but then you're in for a world of pain maintaining it and handling edge cases.
Want a shadow around it? Draw a second shape and offset it a bit below and a bit to the right of your first shape. Just don't forget when the window gets resized to move/resize not only the first shape but also its shadow separately.
For anyone in the trenches long enough will know that most of the facts, such as the ones from “Refactoring UI” are common sense. Unfortunately, I’ve realized that it is NOT, even for many designers.
Another bugbear for me personally: rounded corners. Ask online and it feels like people just parrot the idea that rounding is "more friendly and pleasing" over and over, as if blind repetition of an ideal makes it true. But I've never looked at a picture of old webpages or UI frameworks with sharp corners from 20 years ago and go "that's unfriendly." It feels like with this one, a couple research papers came out a while back showing that rounding makes users spend less energy on element identification, and then used that outcome to conclude "well, I guess a huge swathe of UI design is now a solved problem."
Subjectivity died with the need to squeeze out every last drop of "efficiency" out of every UI design. And no, I don't think that rounded corners are friendlier and more pleasing than all alternatives. In fact, I believe they are a staple of the web and modern UI design in general homogenizing into a bland, unremarkable mess, and are thus irritating. I just border-radius: 0; everything globally and call it a day.
Building a good user interface is fundamentally an engineering challenge. I see roughly two camps in building UIs, one designing a pretty picture and then tweaking the CSS until it looks like the picture, the other treating the CSS as rules of how the UI should behave. A simple example would be using display: flex; gap: 32px; on a parent of two elements instead of margin-right: 32px; on the left-most element. While the end result is identical, specifying the gap on the parent is better, because it puts the responsibility for spacing in the correct place. This also goes for the way you define CSS classes and rules, if two values are linked, like the height of your buttons and the height of your input fields, then try and capture that in a single rule, or extract it out to a variable.
A lot of building good UIs becomes much easier once you adopt the engineering approach. Consistency is almost built-in at that point, and that automatically makes your UIs better and easier to understand. It keeps your CSS more maintainable too.
While I'm sure there are ways to achieve this with Tailwind, generally I tend to see developers do the exact opposite when they use tools like that: just define everything with atomic classes inline, and forget all about the relations of styling rules to eachother. Tailwind has some great concepts, like defining a limited set of values to choose from, but be careful to keep the engineering, rules based way of building UIs.
There are so many times we've gone a direction in our products only to figure out that while we could make the page look pretty, it never would work well. It always ends up being some version of 'if we go direction X, then features Y and Z will have to be shoe-horned in and it'll look ugly'. When you get that feeling, take a step back, come up with some different approaches, and go with a better one.
The "make it pretty"-step should really be the last thing you do. If you design your UI with heavily visually simplified components and in black and white, it should still work and feel right. Make it work right, and the pretty will come.
> forget all about the relations of styling rules to eachother
This is a hot take, but the more cascading your styles are, the harder they are to read and debug. I've never been upset to find classes that just correspond 1:1 with DOM elements. And that's what Tailwind is doing.
What DOM element does "shrink-0 w-6 h-6 mr-2 -ml-1" correspond to?
I suspect there is a lot of halo effect going on, where if people were asked to judge the pure code aspect of Tailwind vs the design system separately, they'd be much more negative on the code aspect of it, but because the two are conflated and one is very good, Tailwind as a whole is judged to be much better than I personally think it deserved to be. It doesn't help either that forming an opinion on an architecture of code is difficult, and forming an opinion on a designed web page in front of you is easy.
My personal poison is just defining the Tailwind color system and a very basic system of sizes in CSS variables and then using that all over the place. It leaves an escape hatch in place of just using 5px when you really need to, but most of the time we use var(--col-grey-200) and var(--u-4) or var(--u-8)
.form-element, .button { height: 32px; }
Is something that can be easily achieved with Tailwind without either using @apply all over the place, effectively now doing regular old CSS but with Tailwind syntax, or by using JS/TS variables extensively making the styling pretty hard to read. Either way, I'm not saying Tailwind makes it impossible, but it sure doesn't make it easier. And while Tailwind has a bunch of benefits, especially where it becomes a design system rather than a syntax for CSS, you can achieve ~90% of that by just defining a bunch of color and size variables at the root of your CSS and using that.
I don't mind Tailwind too much for 1:1 mapping with DOM elements, but I also don't really see why inline styles for that case would be bad.
What is it about your example that the tailwind approach (h-8) doesn’t achieve?
Define an html component, say MyButton:
<button class="h-8 other-inline-styles-here">{MyButtonText}</button>
<MyButton MyButtonText="Click here!" />
Totally agree. I’ve fallen into the trap of chasing “cool” or fancy visuals first, but the most beautiful UI is the one that actually solves the user’s problem. A slick-looking interface that doesn’t work well isn’t really beautiful at all.
Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years. Sure there are new patterns now... "hamburger buttons" and swiping, but the logic remains the same. Human's don't change quickly. They discover things the same way.
Learn about visual hierarchy, visual rhythm, visual grouping, visual contrast, visual symmetry; the golden rule; the theory of colours etc. Think "subject" first, like in photography. Design for first glance & last glance.
Go beyond "do these align".
Think in the eyes of your user as if it's their first visit, there is no content yet, etc; as well as if it's their 1000th visit; cater for both cases; first and power users.
Understand the gestalt, understand the psychology behind design... Why does bright-red jumps at you, at a visceral level?
Feeling that something feels right is great, but understanding deeply why it feels right is a superpower.
Understand the human brain, its discovery process (how do babies discover the world), "why do westerners look top left first"? And you might innovate in design, instead of designing to not offend anyone; or worst, copying dribbble and other sources because "they spent the money".
Trust me if you can learn React or Kubernetes, you surely can learn the gestalt and understand "the design of everyday things"! That knowledge won't expire on you, you'll start seeing it everywhere and you'll carry it for the rest of your life.
So it mustn't have just been me getting it wrong every time!
Even chat apps. In Whatsapp every time I want to copy some message text I have to hunt for where the copy icon is, it appears far away from the message at the top of the screen with 5 other icons, none of which it's clear what they do.
Slack is at least a little better than this, when you highlight a message it offers similar functionality but with a modal where it's easier to find the "copy text" option as it's labelled.
Worse are the apps that try and make it hard to copy text because they want to force you to share via their app to drive engagement.
I work on a desktop PC and "hamburger buttons" frustrate me beyond reason, in the same way that many other "modern" designs. I understand that cost benefit of having just one implementation for mobile and desktop. But it is still annoying.
> Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years.
This is the part that adapting interfaces for the small tactile screen of a phone and then using them on big desktop screens seems so wrong. The design is probably fantastic but it is applied to the wrong interface. The people that designed the desktop interface were good at it and should not have changed. I wish UI designers went back to desktop interfaces for big screens. But mobile has economy of scale on its side so probably it is not going to happen.
> "the design of everyday things"
Great book.
Of course it's annoying. When desktop software is using mobile UI, that's the result of a deliberate choice to make the software worse (something you care very much about as it affects you) in order to save the company money (something you don't care about). It would be weird if you weren't annoyed by such blatant disrespect for their customers.
Let's stop pretending that "companies" could just do things better at no extra cost.
I prefer a desktop UI on a desktop, but I also prefer paying less for software I use, and halving the UI development costs to enable that is a pretty sensible tradeoff.
They're actually spending a shit-ton of money on designer-hours and developer-hours in order to have everything custom, but still with a subpar experience.
It's similar to accessibility: a huge chunk of free off-the-shelf options are more accessible compared to the non-accessible chimeric design system of most modern web apps and sites.
Are they though? My impression is that most companies are just using frameworks or sdks that promise some degree of cross platform uniformity, and that’s why they don’t use the native toolkits. The savings come from not having to develop UI for multiple OS targets.
I'm in the YC startup space, though, but have seen this also in enterprise.
It looks custom designed because... it's not designed at all :D
At this point I'm not even sure if what you said is an insult or a compliment.
Almost all projects I worked in looked more or less like the following:
- a BA meets with the client and creates unstyled wireframes with all of the requested features. (BA doesn't really think about UX here, more or less applies some generic patterns).
- the development team grabs the wireframes, uses a generic preexisting "design system" which is the cheapest for the chosen technology (can be whatever: Bootstrap, Tailwind, Material Design) and max. adjusts colors a bit to match the client's brand
That's it. There is no design.
I haven't worked in a place that doesn't use Figma, since Figma was released.
And haven't worked in a place that didn't get a dedicated designer before the company was 6 months old.
However: I must have worked with 30 different designers in 10 years and TWO of them actually knew how to properly use components and Figma. The rest just copy pasted shit around.
Of course, that’s still better than a 1 pizza team of full stack devs attempting to create their custom UI component library from scratch, now that’s a total mess.
In which industry/company size are you? Maybe I’m looking in the wrong places.
Think along the lines of companies with either <200 employees that can't spare the resources (and also might be lacking in DevOps or other regards, often times falling behind the curve when it comes to all sorts of development practices), or the likes that work in consulting instead of building the product that they sell/dogfood themselves. There you'll get all sorts of people but more fluid team structures - full stack devs that just throw something together for the front end and it's considered good enough.
Of course, it's also possible for companies without the actual means to delude themselves into thinking that they must do everything Google or other big orgs do - that's how you get bad bespoke components and frameworks without the mettle to make them good, as well as stuff like architectures based on microservices without a good reason to do so and so on.
What we really need is developers with solid design skills, that should have been part of fullstack from the start.
And the number is *two* if I count the ones who also understand technical nuances, accessibility and proper usability.
Consider the latest UI disaster - Apple with liquid glass making stuff worse in the most fundamental way - decreasing readability. Doing worse was extra cost, so yeah, in many cases companies can just do things better by not wasting the design money and spending part of it on actual design improvements. No need to bring up the myth of the huge 50% savings when using a single menu everywhere, there is no way it costs that much (neither does having different padding values per platform)!
A similar insanity happens with window borders in general, because heyaah, wow, minimalism is cool. So when you need to resize a window or, god forbid, drag it by its title bar(), that too is minimized into unrecognisability. To be clear, the problem here is, that you can't tell where window A ends and window B begins, because of design minimalism, so it is simply hard to discern where the drag-border is.
(
) which leads me to window title-bar anorexia: It has also become oh so popular to minimize and compact the windows title bar, so that there is no area left where your mouse can grab the window to drag it. Web browsers, among many other apps, are guilty of this. The intent behind is to avoid the "double windows top", where you have first the title bar, then the menu below that (they have been collapsed into one); but apparently no one thought about "but how can users then drag their windows?".. I guess we are not supposed to, because the app is supposed to be full-screen maxxed, on the tablet we are drooling on. Or if there is another way, I, director Skinner and Homer's dad did not get the memo.Of course there is a much better way for all your troubles! Window move: hold a modifier and click&drag anywhere in the window area instead of wasting time precision hunting the titlebar. Window resize: same, use a big 30%-window-width area close to the border instead of hunting for those few pixels of an actual resizable border Horizontal scroll (though strange, Win 11 explorer has horizontal scrollbar immediately visible, though maybe that's a config?): hold a modifier and use the more convenient mouse wheel (or use a window manager with shortcuts or visual grid) None of that, of course, is part of your unhelpful OS
> But modern design lunacy dictates that this scrollbar must be INVISIBLE.
In a real modern design there is no lunacy as wide/tall scrollbar is mostly a space waste as you have better control options, and narrow/short ones are still that, but also unergonomic to use. So you'd have a wide/tall invisible one, which in those smaller % of cases you need them would become visible, but still wide/tall ones
> I, director Skinner and Homer's dad did not get the memo.
That's unfortunate indeed that the bad old ways of window management and scrolling persist for so long and the better ways aren't integrated in the OS
Couple this with App and OS designers feeling a *constant* need to change things and make them "better" and you have a disaster in the works. I've been grousing about Android changing things just to change them as I get older. The other day even my 12 y/o daughter was complaining about them changing how things worked.
Anyway, my point is simply two-fold. First, any UI that requires knowing and remembering interactions that aren't easily discovered *is a problem*. Second, constantly changing UI interaction patterns, even when they are discoverable, *is also a problem*.
But these are separate issues. For example, even with the scrollbars there can be a change between two behaviors: click on the empty bar jumps to that % or jumps by 1 page. And one can be a click and another a Shift-Click - where in the OS would you discover that??? And the scrollbar width - can only find a registry hack to restore that from some tech article/blog post/ etc, nothing in that waste of the Win 11 Settings app.
Settings -> Accessibility -> Visual effects -> Always show scrollbars
No such luck for title bars, though, or the general Fisher-Price-ification of Windows overall.
Who can afford to think like this though? FAANGS? Every designer I've worked with loosely knows some design theory that is impossible to question beyond a quick "hmm maybe a few more pixels on the padding?" and is largely a pixel pusher due to pressure. If I started to talk about visual grouping and the golden rule my boss would have blown a gasket.
I can't name a single well-designed app off the top of my head. I can name a million good-looking ones though. The problem with design is people have to eat. The UI reaches an ideal point but is never frozen, it lasts a limited amount of time before they start shaping the hedge down to a stump. Linear comes to mind. Spotify too. How are you going to reach a good design for a music player when there's 7000 people that need to put in 40 hours a week?
A little lighter on the "gestalt" and a bit heavier on the "will this design murder the weekends of my dev team and scramble the brains of my users" please.
Design is everywhere in your life & career & and you'd be lost without it.
Perhaps you need to learn what design is, so you can start to notice it around you. Then, you'll be able to put that knowledge to work yourself and might become the mythical creature you desire to see in the world.
Look up the Joshua Tree principle - I recommend Robyn Williams book series "for Non-Designers" get one that interests you and open your world up!
Design isn't just "making things look nice". It's every thought that goes into the structure, function, and aesthetic of an object, whether physical or digital.
I wish I could specify the content and topology and the computer would do the styling. I don't want to select fonts, font sizes, align boxes etc.
Currently I think the best a computer can do is bullet points. Anything beyond that and you have to become a manual stylizer, which is what I specifically want to avoid.
When using tables, you already you have to start manually adjusting column widths or they become very often very wasteful and hard to read.
Who can afford to think like this? Anyone curious about the human brain.
If you're concerned about the time to design something well, I would take just as long designing a terrible solution to a problem!
Explaining with words why your design is the way it is isn't a waste of anyone's time, it's having a degree of confidence moving forward. It's having a healthy conversation about the said product.
If anything, knowing what you're doing and being able to justify decisions, leads to a quicker decision making and therefore more time for implementation.
A good design is thoughtful precisely to prevent re-work in the future. That's the point: understand, analyse, solve & apply.
Don't get me started on large companies and their design teams... Going from one design system to another, redesigning every 6 months, and never quite finishing... I've seen those and I'm too old for that.
I'd never imply that good design should be a road block or causing a late Friday evening of work; it takes just as long to implement a terrible design than a good one!
I am merely encouraging everyone to stay curious, and look into building some skills in a field that is timeless, unlike most software engineering fields, and henceforth worthy of your time.
Most people aren't those things, certainly not all at once. Most people seem to me like they mostly care about collecting a paycheck. That was their motivation for their studies and it's their motivation for their employment. You see people talking about writing obscure code so others can't replace them, you see this guy above talking about redesigning an app to justify their work week.
I think these people who don't care are the same ones who make up all these excuses - we didn't do a good job because we didn't have time. We didnt do a good job because the client asked for a bad job. We didnt do a good job because if we do a bad job we have more job security.
Any time I see these types of excuses I judge the person making them to be someone I don't want to work with. I don't make these excuses. I always strive to write good and maintainable code. I take the time I need to do things right and if someone pushes me to take shortcuts I push back if I can or I find a compromise like fixing it later(and then actually do so). If a client asks me to build something I know will be bad I tell them and suggest a better approach.
In short, I take responsibility for my own work and I do not allow others to compromise the quality of my work. I do not respect people who blame others for their own shortcomings. Quality is less about constraints and more about having the ability and caring about it. Doing bad work generally isn't faster, if anything it's usually slower at least after a while. It's just that the people who do bad work needs an excuse to explain why their work is bad.
When I contracted (for many years) I always told my employers at the time "my job is to return the value I cost, or more" and that if somehow I couldn't, I'd quit. I never had to quit. Sometimes I'd pivot internally as "it's what the company needs".
It was always a healthy relationship with my customers/employers.
I learnt early on that work is such a big part of life; why suck, or barely scrape the bottom of the barrel 40+ hours a week? Isn't that a complete waste of a life?
You might as well strive at being in the top 5% of "your people".
My business motto has always been "Find good people and do good work" - note that I don't say "the best people" or "amazing work". With age comes pragmatism; life isn't a self-help book. Having good people means that no matter the work, how terrible of a slog it is, you still wake up to work and look forward to the next week; even if this one stank! Surround yourself with people that care, that take it upon themselves to improve and that have your back (no genius psychopaths).
Sure I've come across a plethora of oxygen stealers and time robbers, and I could count on my right hand the people I'd chase up to work with again...
The key is to not let the bad apples ruin your experience (and sometimes, they're overwhelming all over, at every level, and you have no choice but to move on). Take pride in your work and ignore the bad apples. If the business is any good, they'll get weeded out. Constructive honesty works. And if you talk yourself out of job, it wasn't the one. A good dose of daily humour certainly helps.
Jobs in our industry, we change like we change cars. Often we get more jobs than cars actually. So don't get too precious about your first scratch...
Many CEO, CTO, manager, whatever, will recognise quality in their people if they see it. Weasels have a limited shelf time. No matter how good they're at lying, they're scared of people who confidently do a good job quietly. Eventually they'll stand naked in the spotlight without any excuses.
Any job worth doing, is worth doing well - my father said, he was always inspired by the Japanese culture.
When I found myself in a daily slog, I found that routine was extremely important. That walk to coffee. That walk at lunch time. That little detour during commute. Whatever could be small wins throughout the day, I'd take it. It helped the drudged work where I was stuck in for a while, because having nothing to look forward to, is depression.
Work is a marathon, not a race; even if the industry wants you to believe that you're missing out, you're too slow, etc. As long as you can sleep with yourself at night, and it brings the pay check, strive to do your best in any condition and accept the things you cannot change. But don't let bad people define your work.
When it's well designed you don't notice it. Surely you've encountered badly designed apps and interfaces in your life. Now think of the apps that don't make those same mistakes.
The purpose of digital technology is so that people who are not developers should be able to use them and be productive with them. Just like cars are designed so that people who are not mechanics or engineers can also drive them.
> I can't name a single well-designed app off the top of my head
Which wouldn't be a surprise to anybody who actually cares about good design. Precisely because a really well designed product should just help you do whatever is it needed to help you do, and be all most invisible in doing it. It just worked however you expected it to so well you barely even give it a passing thought. It was unobtrusive. It was as little design as possible. I was not trying to wow you by the fact it's one of the million good-looking apps you've seen.
I understand and share the underlying sentiment, but it seems to me like quite a lot of people are suspiciously satisfied with how learning React or Kubernetes has entirely blinded them to the fact that the everyday things do indeed have a design.
Is this the book you recommend people read to learn about "the gestalt"?
Are there any other resources/books/courses you can recommend?
What you've called out is meaningful, but it includes an implied requirement that you're not spelling out: the time and effort and attention to detail, along with the history of experience, to really apply the principles you are talking about to a project.
When I read the main article, I interpreted it from my perspective. I'm mostly a systems person. I can appreciate the points you mentioned, but I don't have those other implied things that are prerequisites for applying those concepts effectively.
Without rules of thumb like these, the UIs I design end up looking like grade school collages. Building UIs that make people _feel good_ when using them is not my core competency. I'm just looking for a baseline level of quality.
I believe there are two cohorts here: the people who want to make UIs that are beautiful, and the people who need to make UIs that are not hot garbage.. and we're reading the article from our respective perspectives.
Though I warn you, I read it 30 years ago and I still cannot enter a kitchen without cursing how bad the stove is.
Communicating through writing is hard. Just as designing something that can be easily understood is hard.
Translation: I don't need to know why I am doing anything but hey, it looks okay to my eye, and I didn't spend a lot of effort on it. Now I have more time to write a blog post about it that mostly advertises my app.
> This system is about achieving the best possible design with the least amount of effort. There’s no need to know about the psychological impact of colors, which fonts are best for which purpose, golden ratios, etc. This is expert-level design knowledge that is just distracting if you’re not on that level. The key is to focus on the few important aspects, and not try to optimize every tiny detail.
Or do you mean: simply understand all of human psychology and design UIs that work for everyone? That seems to be what you're saying, but both are impossible. Nobody really understands human psychology, especially those who think they do. Show me a psychology finding that is applicable to UI design and I'll show you a study of 30 college freshman that doesn't replicate. And you cannot design a UI that is intuitive for everyone; people are too different, and the "average person" literally doesn't exist.
So what exactly is your advice? Know everything and apply that knowledge appropriately for your specific situation? React and Kubernetes have clear documentation, tutorials, and canonical ways of doing things. UX design has a couple of clever books. The analogue of "just learn good UX design" is not "just learn React", it's "just learn how to write readable, maintainable, clear, performant code everywhere." It takes decades.
So much software these days doesn’t let me do things like “do Z on all Xs matching Y”, instead forcing me to repeat the same slow sequence of actions over and over (swipe, tap button; wait for animation to finish. Go back, swipe, tap button; wait for animation to finish. Go back, swipe, …)
So much of modern UI seems to be created by people whose focus is on "looking good" and less about actually using it daily. For example, YouTube has awkward details that make certain common actions painful, or even impossible. Like a modal window that covers up part of the screen where selection is being made, and it can't be moved or closed without losing all selections. Whoever designed it clearly had not used it enough (or at all) because it's impractical and infuriating as a user. I don't care how good it looks if I can't get it to do what I need.
But why the logo of the website/app should be aligned with the icon of the actions?
> The icons are thin, compared to the text, which is bold.
Why this is an issue?
I can somewhat agree with the other points, but I wouldn't call this "bad design." Just because the information can sometimes be presented better doesn't mean the previous way was bad.
There's nothing objective about using ctrl+s for save, but it's an obvious best practice. So not following can be considered bad design fairly uncontroversially.
The two you mentioned are obviously not in that category. I take issue with the logo one especially, because I find the style of the "bad design" better and more functional.
>[...] I’m probably the only one who noticed that it’s calmer.
Ugh.
Anyone have recommendations for UI/UX books for a more modest budget?
https://www.amazon.com/Design-Everyday-Things-Revised-Expand...
Don't let your boss add features one at a time. It creates terrible UX.
Visual "breaks", such as color changes, spaces, or variation in contrast can help a lot (and still look good). A good example are paragraphs in text: A large chunk of text is more difficult to go through, or re-discover some section, than one divided into paragraphs.
I've seen a lot of developers feel like they have to write their own components as much as necessary and the results are very, very often underwhelming, especially when they have a bunch of deadlines - underdocumented, not as good looking as something dozens of people have polished over months or years and more often than not buggy.
That's why I think that for most developers (myself included, I can describe myself as a full stack developer, but definitely not someone who specializes in UI design) grabbing something that can be used off the shelf will be the more sane thing to do, personally I quite like PrimeVue, PrimeReact and PrimeNG for this, alongside PrimeFlex and PrimeIcons, they all fit okay well enough. Maybe some of the others + Tailwind for the brave.
Here's a concrete example of why something like that is a decent example: https://primevue.org/datepicker/
I weep for our field, because this should be true beyond the confines of each app.
Instead even on the desktop we have hoards of local "optimisations" - one in each bloated Electron POS.
There's a place for novelty UI - entertainment.
Productivity should have no place for it.
The most sensible approach is one by mpv. Ship the core logic of your app in a bundle/library. And everyone can build the environment specific UI for that.
- the vertical ruler between the sidebar and the content is gone, making page structure less pronounced - the redesigned dropdown menu has no borders or shadows and blends with the primary background - the redesigned dropdown menu lost the little dot which highlighted currently selected option, replacing it with a folder icon, but now it's not useful, because it's the same folder icon for each option - the old design had really nice and noticeable "Add URL" button. I suppose, it was removed in favor of the "plus" button in the sidebar, but it's not nearly as noticeable and without the label it's not clear what it actually does
Sure, the issues in the old version are valid, but I think the redesign introduced more severe usability issues instead of mostly aesthetic issues
- Refactoring UI
- UI Pedia
And all video courses from Tailwind CSS team
>> It’s best to build on top of a good component library, and not develop your own.
This, so much this. Suffering greatly at work right now because my predecessor decided to go with ShadCN as opposed to using a full-blown, fully-featured component library. Their reasoning: it's better to have "lego blocks" with which we can build our own components because that would give us full control.
Yeah, no. In 99% of cases, you ain't gonna need that level of granularity. Just take something that exists and tweak it until it looks the way you want.
But, kidding aside, it's a mechanistic view patterned on avoiding egregious missteps. It's rules for creating not-bad-looking user interfaces.
And... I take that. It's better than a lot of what's built. But I encourage every developer to ask "why" when looking at these rules, or when looking at components in a component library. It's a valuable exploration. It will also teach you the most important thing - and understanding when you can break the rules.
Because without an occasionally broken rule, the design will be lifeless and flat.
E.g. making a bad looking Qt App takes a lot of effort. If you use the things everyone else is using, the same frameworks, the same layouts and standard components, then users will be immediately familiar and know how your interface works. No, you aren't special, no you do not need to reinvent UX with your SaaS product.
You can find PDF versions of the old Apple HIG online; I just found a GitHub repo that has them:
https://github.com/gingerbeardman/apple-human-interface-guid...
It was a design movement, with zealots and influencers.
Was comparable to Jeffrey Zeldman's "Design with Web Standards".
The books go into reasons for the design decisions they made.
As such, it's still worth reading, more concrete than Norman's "Design of Everyday Things".
Terretta•4mo ago
The "what good looks like" example provided, HeroUI, avoids aligning these:
https://www.heroui.pro/components/application/layouts
travem•4mo ago
It appears to be related to my display settings on Mac OS. When the text size for the display is set to the "Larger text" it shows this vibrating. When the text size is set to one of the smaller sizes the shaking/vibrating does not appear.
boxed•4mo ago
empiko•4mo ago