Rules for creating good-looking user interfaces

Aesthetics vs Functionality

• Many commenters prioritize functional, fast, and discoverable UIs over “good‑looking” ones; they see modern design trends (animations, hidden controls, mobile patterns on desktop) as slowing apps down and hurting usability.
• Several note that “good-looking” in the article mostly means styling; deeper UX concerns like task flows, feature discoverability, and bulk operations (“do Z on all X matching Y”) are often neglected.
• There’s strong support for the idea that usable, even slightly ugly interfaces age better than trendy but awkward ones.

OS-Level Theming, Dark Mode, and User Control

• Long discussion about historical Windows/Unix color-scheme editors vs today’s per‑app theming.
• One side argues early OS theming “solved” dark/light and accessibility by letting users set global colors that apps inherited; we’ve regressed into isolated “design fiefdoms” and broken dark modes.
• Others respond that many developers ignored system colors or mixed system and hard‑coded colors, breaking non-default schemes even back then.
• Several wish the OS, not individual apps, controlled colors, fonts, and basic styling for consistency and accessibility.

Component Libraries, Tailwind, and an Engineering Approach

• Broad agreement that most developers should lean on mature component libraries instead of rolling custom UI: you get consistent behavior, states, and accessibility “for free.”
• Tailwind is seen by some as a helpful design system (constrained sizes/colors); others criticize it for encouraging atomic inline classes that obscure relationships between elements and harm maintainability.
• An “engineering” mindset for CSS—shared variables, layout rules on parents, encoding relationships once—is recommended over pixel-perfect tweaking from static mockups.

Design Principles vs Rule Checklists

• A strong subthread advocates learning fundamentals: gestalt principles, visual hierarchy, rhythm, grouping, contrast, color theory, and classic works like The Design of Everyday Things and Jeff Johnson’s Designing with the Mind in Mind.
• Others find “learn gestalt/psychology” too vague or unrealistic for busy developers and see rule lists as useful to reach “not hot garbage.”
• Several stress that rules about alignment, weights, and spacing are mostly about avoiding obvious mistakes; truly good design requires understanding why and knowing when to break rules.

Reactions to the Article’s Examples and Site

• The Lighthouse “after” screenshot is criticized for losing useful structure (divider line, clear “Add URL” button, legible dropdown counts) and arguably worsening usability while fixing minor aesthetic issues.
• Some disagree with the article’s judgments (e.g., aligning the logo with sidebar icons, icon weight critiques), preferring the “before” versions.
• Multiple people note ironic flaws in the blog and product sites: mobile overflow, gray text on dark backgrounds, misaligned elements, missing strikethroughs—leading some to question the author’s authority.

Platform Trends and Usability Regressions

• Frequent complaints about minimalist trends: disappearing scrollbars, ultra-thin window borders, cramped title bars, and gesture‑only interactions that aren’t discoverable.
• Many dislike mobile‑style patterns on desktop (hamburger menus, hidden controls) as deliberate quality tradeoffs justified by “one UI for all platforms.”
• There’s nostalgia for older, more consistent desktop ecosystems (classic Windows, GNOME/KDE, TUIs, old Apple HIG) where shared conventions reduced learning and improved productivity.