As long as all the important things are on screen and easily reachable/visble you're good.
For example, the emergency button should really be a big red button that doesn't require a good aim to be pressed in a critical situation and no one cares about how many cores the system is using as long as it works as expected.

Good decision, most programmers are terrible at design. Here's some handy tips: https://digdeeper.neocities.org/ghost/design.html

>>383
>The linked website has white text on black background
Fun fact: turns out dark mode is also a terrible design choice as it doesn't actually offer any advantages.
Humans are better at recognizing shapes (e.g. reading some text) when the shape is darker than the background and there is high contrast.
The only real positive thing dark mode has is that you can use it in a dark room at night, but people wouldn't need it if they were to sleep during the night instead of shitpost.

Anyway that guy is full of crap. Many of the things he complains about are actually good things, he's only talking about his own experience and as such doesn't hold any particular weight aside from being, well, an opinion.

>>384
Provide a better guide then.

>>366
Learn HTML5 and CSS3 in general, but nowadays you'll need at least some JavaScript too.
Then get familiar with frameworks like bootstrap everyone uses (and learn how their css stuff works), single page applications and responsive webdesign. Today's frontends come with quite a bit of logic, there are frameworks like React or Angular the give you quite a nice toolbox for UI design.
>>384
I always use dark mode. If there's too much white background or the screen is too bright in general it makes it exhausting to read and gives me headaches over time.

What can help is putting yourself as user.
Just use your interface and it's possible you'll notice inconsistencies, manipulations that irks you because too cumbersome, or whatnot.

UI and design is a whole different world to discover.

>>388
Great advice. I wish devs would do the same thing and eat their own dogfood. Maybe then we wouldn't have so many shit code interfaces.
>t. coder

>>386
Why should I? Aside the fact that the guy isn't completely wrong (though his opinions are still debatable), it would still be just a list of opinions, not facts nor tips.
Design isn't a science and what is wrong in one context or for one user is right in a different context or for a different user.
It all depends on what you want to accomplish and who you are targeting with your program.
The only real rule would be that "one size fits all" does not exists.
For the rest, it's all a matter of being judicious about other people's opinion, which is not hard if you have an ounce of intelligence.

>>388
Yeah, if you make a UI that already starts to piss you off while developing it, it's prbably not a good concept. Try to make things immediate, without a thousand confirmations but still put in some kind of safety net that keeps the average boomer from doing something stupid.

>>383
It's just tips without structure from some guy. There are no good resources to learn interface design not intended for mouthbreathing normalfags too inept to choose between two buttons or high power level autists that need a UI with the complexity of a commercial airplane cabin. Raskin's Humane Interface? Some early 2000s talks by Microsoft and Apple? No fucking clue.

There's a lot of tips on the UI part of things. Any tips on the art side of things? Making it look scifi, that sort of thing?

>>401
you mean like systemspace?

>>401
I'll be honest anon, if you want something to look scifi, you're barking up the wrong tree. Usability and "styleizations" are usually add odds with one another. I won't try to tell you either one is wrong, but I will tell you that they can't coexist peacefully and that you should pick one. What are you making interfaces for anyway?