For what it's worth looking at the resulting UI, both the before and after screenshots do not look visually attractive. Whether or not that's a problem for this product, I don't know.
Rules for creating good-looking user interfaces
141–150 of 183 posts
Re: Rules for creating good-looking user interfaces
#142Earlier quoted context omitted.
>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. 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 eve…
I remember being able to change the color of every window frame, button, selector, scroll bars, and so on. For a time most people had their windows using bright colors with zero regards for good design, they just liked colors.
The same people still send emails and write documents with half a dozen differnet random font faces, colors, and sizes.
Re: Rules for creating good-looking user interfaces
#143For engineers doing UIs once in a while, I can recommend Refactoring UI [1]. It has a bunch of practical tips for making your life easier: Picking a color palette, font sizes, margins/padding etc. [1] https://www.refactoringui.com/
The first example on that page ("Contacts" box) looks way better in the "before" style. Turns me off their entire proposition because it's obviously incredibly subjective.
Re: Rules for creating good-looking user interfaces
#144Sorry but based on this person's website, they have no business giving UI advice to people.
Re: Rules for creating good-looking user interfaces
#145Re: Rules for creating good-looking user interfaces
#146Saw a lot of words here. Not a lot of examples. "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…
> properly-written apps would inherit it and work fine
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.
Re: Rules for creating good-looking user interfaces
#147Earlier quoted context omitted.
I don't understand when people see Tailwind as anything other than a syntax for CSS. > 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.
I'm not necessarily arguing in favor of deep cascading, but I don't see how something like this: .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…
The equivalent tailwind is to just put h-8 (or whatever it is) on whichever form elements and buttons you want to be that height. Tailwind recommends you never use `@apply` - it’s basically an escape hatch for weird, niche interop requirements if you’re not all-in on Tailwind.
What is it about your example that the tailwind approach (h-8) doesn’t achieve?
Re: Rules for creating good-looking user interfaces
#148Earlier quoted context omitted.
> I understand that cost benefit of having just one implementation for mobile and desktop. But it is still annoying. 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…
> blatant disrespect 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.
I too prefer to get things cheaper (all else being equal). But in this case they aren't equal, which is kind of the rub. I would much rather have desktop software which doesn't suck, even if I had to pay more for it. And of course don't forget that just because the company is saving money, doesn't mean you the customer do. Companies are very happy to cut their own costs and pocket the extra profit, so it's difficult to say whether this reduction in software quality is actually benefiting us by making things cheaper.
Re: Rules for creating good-looking user interfaces
#149Saw a lot of words here. Not a lot of examples. "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…
Most of the world consists of dark objects against a light field. Written letters made with a pen were dark on light for a couple of thousand years. Your scheme is the inverse one.
Yeah the hate for light mode is very badly overstated. It's fine to prefer dark mode, but that doesn't mean light mode sucks in some kind of objective way.
Re: Rules for creating good-looking user interfaces
#150Earlier quoted context omitted.
>Trust me if you can learn React or Kubernetes, you surely can learn the gestalt and understand "the design of everyday things"! 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.
Everyone wants developers to learn everything all the time... Software development, infrastructure management, testing, business analysis, design, even marketing and communication sometimes. We have to pick our battles. Guess what employers ask for from developers during interviews and 90% of the work. Plot twist: not design.
Nor anything else that's as much as intended to be based on taste and good sense, really.