Flat UI has been the downfall of the Windows UI. Firstly, it is ugly. Secondly, it is not intuitive. Thirdly, it is hard to differentiate from Web apps.
From a developer point of view that last point is very important. 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?
Sure, native apps are better at reducing resource consumption but if your app offers significant functionality users won’t mind if it uses some extra memory. This is the reason Microsoft’s own Teams and VS Code products were built using Web technology.
Another issue from a technical pov is that XAML, MVVM and 2-way data binding are outdated. MVVM introduced 2-way data binding to the world. Since then every JavaScript framework copied 2-way data binding including EmberJS and Angular. Today we know 2-way data binding is gimmicky and makes programs hard to debug. This is the reason React uses unidirectional data flow.
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.
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.)
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.
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.
> 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:
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?
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?
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
> 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.
> 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
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."
"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.
From a developer point of view that last point is very important. 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?
Sure, native apps are better at reducing resource consumption but if your app offers significant functionality users won’t mind if it uses some extra memory. This is the reason Microsoft’s own Teams and VS Code products were built using Web technology.
Another issue from a technical pov is that XAML, MVVM and 2-way data binding are outdated. MVVM introduced 2-way data binding to the world. Since then every JavaScript framework copied 2-way data binding including EmberJS and Angular. Today we know 2-way data binding is gimmicky and makes programs hard to debug. This is the reason React uses unidirectional data flow.