Hacker News Reader

Totally agree. I occasionally work on family member's Windows PCs and hate it every time. Everything is huge, I can't tell what is supposed to be an actionable element and what isn't, and its just subjectively ugly.

Information density took a huge hit in the later Windows versions and I find it incredibly frustrating to use. The first thing I always have to do is figure out how to open the old version of control panel so I can actually accomplish something.

Glad to know I'm not alone in these thoughts, thought maybe I was just being stubborn in adopting the new style.

I think Flat UI can look absolutely awesome, the problem for Windows is that Microsoft hasn't done it well. I don't know what it is exactly, but their new UIs look bloated, yet barren. It feels like there's a lot of noise, yet no functionality. It's certainly not helped with the serious UI layering MS has been doing for the last decade (take all the basic functionality, create a new UI for that, create a link that opens a dialogue for the old functionality). Nowadays you have to enter 4 dialogues to access anything slightly advanced in outlook.

It feels like it was designed with shapes in powerpoint

According to an anonymous insider, in fact it was: https://news.ycombinator.com/item?id=11387759

> I think Flat UI can look absolutely awesome

Can you show me some "absolutely awesome" examples of Flat UI? Our sense of beauty and aesthetics comes from the physical world, which contains gradients, shadows, dimensions and so on. Simple geometric shapes can be elegant, but I haven't seen examples of Flat UI that is awesome as well as doesn't suffer from usability issues.

Not op, and don’t generally love flat, but here is one that I think qualifies:

https://apps.apple.com/us/app/clear-todos/id493136154

Screen with blue todos is using white text on gradually lighter background in the end the contrast is terrible IMO. Also the gradient looks tacky and pointless

For a to do list, I think that makes a lot of sense. The items at the top of your list are higher priority, so having higher contrast text and a more saturated background up there draws your attention to the stuff that's most important.

I'll grant that -- but it's also a to-do list, which is pretty much the simplest possible application. It's a common "hello world" for GUI toolkits, and it's the first use case in the org-mode tutorial.

Is there any software more sophisticated than 'a 3x5 card with a pencil' which uses this user interface paradigm? I think any paradigm, no matter how confusing or clumsy, is sufficient for that case.

I agree they can look awesome, but I still struggle to find actionable components when using them, so I find them to be counterproductive most of the time.

It is definitely possible to devise a flat UI visual language that would make anything clickable easy to identify, etc.

Two problems: (1) It takes a real and complex design effort, and (2) it's nearly guaranteed to be at odds with the "clean look" aesthetics.

I think it's the minimalist aesthetics that caused the fad of flat design and unidentifiable controls. It strives to make a page / form visually simple, thus hiding its real richness and the irreducible complexity stemming from it. In a misguided attempt to avoid cognitive overload it turns UIs into impenetrable puzzles.

There is a fundamental tension between "clean and simple" and "rich and comfortable". It's much easier to sell "clean and simple" and pretend that it's "intuitive" and does not take any learning. But once you've bought that, and want the power features, they are either not there at all, or are very well hidden ("have you tried triple-drag this to the right?").

Ideally there would be a switch between "beginner mode" and "pro mode", but there's little incentive form the market, because people are just used to put up with the limitations.

I think the "clean look" is not aesthetic. It is like a white canvas that has just been purchased from an art supply store but has not been painted on yet.

Microsoft Fluent Design principles was thinking of Screen + Holography first, as flat surfaces look good in AR/VR.

Nielsen, in 2012, had some particularly striking examples of "bloated, yet barren": https://www.nngroup.com/articles/windows-8-disappointing-usa...

Since then, details were improved, but the overall concept has never felt natural or appealing for me. It always feels like something I have to work against. (And I usually do appreciate reasonable white space, distinctive typography, and clear geometry.)

> Today we know 2-way data binding is gimmicky and makes programs hard to debug. This is the reason React uses unidirectional data flow.

It makes sense for simple apps that are mainly rendering and outputting information/data.

Writing a React that handles even simple forms is however a trip back to the early days of web, where you gotta handle your own DOM events. I'm unclear when repeating the same DOM handlers all over the place became "easier to debug"

That’s because React isn’t a form library, it’s a rendering library. People have built form libraries on top of it. Here’s one I’ve used and contributed to that builds two-way binding for form state in React:

https://github.com/Shopify/quilt/blob/master/packages/react-...

Okay, but if React isn't going to handle forms for me, why am I wasting 100KB on it?

If you're going to use a "if React isn't going to handle X for me, why am I wasting 100KB on it?" argument, then it wouldn't be 100KB for very long, now would it?

Vue is smaller than React and does not need a form library.

Classic webdev reply. Hey how should I properly work with data binding and forms in react? npm install react-proper-use-of-binding-and-forms-duhhh!

There are libs that make it trivial, one is Formik.

It kinda feels like you're trading hard to debug data binding bugs, for hard to debug formik bugs.

For the record with Angular 2+ two-way binding is greatly deemphasized and not the default behavior. Everyone collectively learned that it’s not great for performance to do thousands of dirty checks a second. React definitely showed the way here. Nowadays you can implement the flux pattern with Angular using NgRx, but if you’re creating simpler things the binding concept is more intuitive. With Angular 9 you can breakpoint debug your template as well, so tooling is definitely catching up here.

>Today we know 2-way data binding is gimmicky and makes programs hard to debug. This is the reason React uses unidirectional data flow.

Uh no we don't. I've spoken to a lot of engineers who curse redux and the entire ecosystem around it. The reality is, 99% of apps don't need that kind of craziness. "time travel debugging" is a meme. I'm tired of it being highlighted as some insane victory. Over what exactly?

Previous poster wasn't talking about Redux though? Just React.

This is super confusing to me, because you're talking about your dislike of redux, when it wasn't brought up or mentioned?

Are you really super confused, or just pretending?

I was confused. The reply wasn't really responding to the parent comment.

But it was all right, everything was all right, the struggle was finished. He had won the victory over himself. He loved Big JS Bundles.

In Back to the Future — I can't remember which — Doc says at some point: Why are things so heavy in the future? Is there a problem with the Earth’s gravitational pull? If you told me he was talking about websites I'd believe ya

Then don't use Redux. Use a different way to manage state.

> If your native app is not going to look or feel any different than an app built using Web technologies why limit your customer base to Windows users?

BTW, It specifically mentions that WinUI supports React Native for Windows.

https://microsoft.github.io/react-native-windows/

> Another issue from a technical pov is that XAML, MVVM and 2-way data binding are outdated.

UWP XAML emphasizes OneTime binding more than OneWay/TwoWay when you use the new static bindings (using x:Bind rather than Binding), it's been a source of frustration for some people coming from WPF

Isnt vue.js a MVVM library with 2-way data binding? It works well. As far as I know, Aurelia is also a modern mvvm library.

> Isnt vue.js a MVVM library with 2-way data binding? It works well.

Not for me. I ended up just following the old way - on change handler to handle the changes in the form. It eliminated lot of issues/bugs.

Vue is nice because it takes the boilerplate out of simple variables that map to <input> while also supporting events for more complicated data flow.

Just curious, what do you find hard about MVVM to debug?

Here's the key developers behind Embersj talking about why they moved away from two-way data binding: http://thechangelog.com/131/ (fast forward to 0:44):

"It is easy to end up in a state where you can't yourself explain how data flows through it. Even though both Angular and Ember have events and data bindings, data bindings feels so cool that people started tunneling events through data bindings. People are abusing two way data bindings to express something that is fundamentally an event. Ember 2.0 is moving away from two way data bindings as the primary method of communication to events. We added too much sugar around two-way data bindings and that led people to use two-way data bindings as an event bus."

Reminds me of people using exception handling to push message objects around (data).

Why is it necessary to be able to distinguish windows apps from web apps? That's just silly.

"Silly" is a strong word. I imagine one of the points would be that a native app has direct access to your filesystem so you'd rather have users be cautious with it?

But I agree that having in native apps the UI patterns people are used to seeing in webapps is simpler for the majority of users.