So here again MSFT produces some bright shiny new object and then loses interest scant years later. Nothing is immune to it, not even Visual Basic, MSFT’s original cash cow / trademark innovation, or various other discarded things that were sold to us over the years: .NET Remoting, Classic ASP, original ASP.NET, even ASP.NET MVC 5 (not compatible with the current ASP.NET MVC Core, which feels a lot like they just renamed namespaces and reorganized classes just to break things – sound familiar, Xojo refugees?). And certainly not, say, Visual FoxPro.
I worry that .NET MAUI may be another one of those, or it may at least experience uncomfortable churn before it settles down. In the article he’s thinking Blazor is the way to go for now, and he may be right, IDK. WASM is definitely attractive to me for keeping everything in the C# realm.
It is becoming increasingly impossible to trust vendor’s roadmaps. I actually give props to Xojo for putting a disclaimer right on their roadmap – the subtext is “here’s our plan, at the moment, but it might be different tomorrow, so it’s kind of aspirational”.
The best roadmap I’ve seen recently in terms of the reality pretty much matching the plan is Lianja’s – they have an extensive and detailed roadmap and mostly just keep delivering on it. At worst, it falls behind 2 or 3 releases. But once they promise a functionality, they deliver on it. I haven’t worked personally with it and so can’t speak to whether what they deliver is fully fleshed out or sort of a minimalist window dressing like it tends to be with Xojo’s mobile efforts.
I agree. My read in having looked at the various options in this space is that, if you want to develop for the desktop, C#/.Net/WinUI3 is the MSFT solution. If you want cross-platform from Microsoft, I expect Blazor may well end up being their solution because, again, C# and they completely control the stack (unlike MAUI, where they will have to continuously adjust the abstraction layer where it contacts the “other” platforms). But, either way, C# seems to be your safe bet here, and I’d be cautious about getting into MAUI – just no actual incentive for it to survive the shiny object phase, as far as I can tell. AvaloniaUI seems a better bet for cross-platform “classic” UI development, though the author’s note of caution on it being persistently beta is worth considering, too.
C# does seem as decent a language as any
UI toolkit and bindings to the OS is where I wonder - although poking around in C# it looks like its not so hard for them to expose native controls on macOS or Windows with much the same approach
Whether that makes x-platform easier or harder in MAUI I dont know - yet
The exposing part isn’t hard; it’s maintaining it. Witness Xojo and every other native controls abstraction layer approach I can think of at the moment; they fall behind. Compare to the render-your-own or web-based (which is a kind of render-your-own, I suppose) approaches.
That sounds right to me, but they still need to map it to the underlying OS native controls, so if Apple, for example, did something like MSFT did in moving from WinForms to WPF to UWP to WinUI2/3… you’d have to rewrite that mapping. If you render your own, no problem.
To emulate one - or just say screw it and make your own ?
With emulation you have similar problems and a re always playing catch up to adjust to whatever new appearance etc the platform adopts. Or adds new controls, etc.
If you just dont bother trying to look platform correct sure you can do anything but then you DO look “not platform correct”. That may be ok
Anyone remember Kai’s Power Tools which looked way out of place when it originally came out. But it was VERY well done - but it was most definitely NOT platform correct in any way
And it may not be OK
For me the worst is looking very close to native button acting like native
Its definitely a tricky choice of which way to go
MAUI seems to be heading for “native” and I dont think thats a bad thing with what I’ve seen so far
Well, as I’ve argued elsewhere, I’m not sure that “platform correct” is as much of a thing as it was 20 years ago. I don’t even know which UI toolkit on Windows is the “correct” one at this point.
I don’t advocate for emulation. With GTK, for example, I’m not a fan of platform themes, though I guess a user can apply one if they are. I’d say that GTK and AvaloniaUI ought to have their own “platform look” as well as good integration with platform-specific features (e.g. menu bar on the Mac), which is what I think users really expect these days. For something like Flutter, where there is no “Flutter native look” (Material Design, maybe?), I’m not even sure what to say “correct” is by default, but I’d agree, don’t bother trying too hard to emulate native. Not worth it, and more likely for users to see the seams.
THIS is quite uniquely a “Windows” created issue since M<S couldn’t figure out what toolkit to use, support etc
Apple chose a different route & updated their API’s such that IF your code was done according to spec you just got the new UI with no work. For most of the mac’s life this was true and still sort of is except you may have to update as API’s are rapidly rewritten & revised lately.
MS chose to make multiple UI toolkits instead
If you’re going to ACT differently then looking differently isnt bad (KPT for instance)
But many toolkits do try to look and act mostly "native;’ but get things wrong that give them away as emulated in some way
I will say I do think users are less “fussy” these days esp when you consider electro ui’s, web ui’s etc
Maybe “more sophisticated and can recognize different looking UI’s just as well as native” is a better way to say it
I somewhat agree with this statement. How true it is, depends on the user and the problem domain. The advent of Electron and similar means that a lot of desktop apps are just web apps running in a desktop container. The container might manage the platform menu bar or whatever. The app thinks it’s running in a browser. Some users readily accept this, particularly if they are running a downloadable app for their OS and are expecting it to look like it does on the web or mobile.
I am not so sure that people gravitate to macOS or Windows based on “look and feel” in the way that they did 20 or even 10 years ago. Nice-looking GUIs that respond to a mouse are commonplace now. I suspect for the average user the turn-offs aren’t so much nuanced visuals and behaviors as it is the computer getting slower and slower with age and similar issues. Certainly Apple’s cohesive control over the whole software and hardware ecosystem can appeal at least in concept. But I can’t imagine most users complaining about the controls being “wrong” in some way when web sites are more or less random and often minimalist in control appearance and behavior and that is where they spend a lot of their time.
I think what people expect today (actually always have, but they rarely got it before) is always an intuitive UI, w/o RTFM. It just has to work like it does on a mobile device, simply and logically. And getting that right was never easy but it’s getting harder and harder for us developers as we get more functinality in our hands.
I’m always amazed when developers say for example, that they think “touch” is stupid. Well, I don’t personally use touch on my laptops either, although my Windows box can. But in 2023 I can’t infer others from myself. If customers want it, then so be it.
And that affects more and more UI aspects. Dark screen, etc. For some that’s nonsense, for others with poor eyesight, for example, simply a must. Of course, this also applies to the entire topic of accessibility. That is a field in which web-based solutions often make life easier for us developers, as everything is built-in, you just need to use it.
And with all those issues, enterprise development is still a good deal easier than developing for the masses. For a small company, you can let the customer weigh up which UI functions are important to them. If they don’t like touch, no touch for them, done. But if I’m developing an app for the mass market, I can hardly avoid covering everything in 2023. Even if nobody uses it, someone will blow your mind that you didn’t implement it
I have good eyesight but simply find dark mode appalling. I want something that looks more like a sheet of paper. And I don’t mind small-ish fonts because I like lots of real estate. Obviously, with dark mode all the rage, that is a minority view, but you can bet that if a commercial product foisted dark mode on me with no real alternatives in some misguided effort at “with-it-ness”, they would have to walk on water and raise the dead in all other areas to overcome that constant annoyance.
Conversely, if I were building a commercial product or an internal product that demanded dark mode, then I would definitely support it. I understand, as was mentioned earlier in this thread, I can’t extrapolate from myself to all others.
We are on the same page. That’s exactly my point. I (!) personally agree with your remaining points too. There are even medical studies that show that the light mode is actually more productive for the majority of users because it is like paper. I definitely count myself among them. I doubt that it is only related too my age, child books are still printed on white paper too
Conversely, there is one Xojo developer in our ranks who unfortunately only gets along with the dark mode, or for whom the dark mode simply means a relief. I, on the other hand, use the dark mode selectively (if this is possible with an app) to identify it immediately
Since I work a lot for non-profit and social organizations, we often have selective requests for solutions that focus on accessibility. Good for us, often business, just because “big” solutions don’t offer anything here.
I don’t know if that’s true, but I read that Facebook is “blue” because Zuckerberg is color blind.
In any case, accessibility is becoming more and more important in Europe. Unfortunately also sometimes purely for political reason (requirement of the company’s code of conduct etc.). It’s not about whether someone in an organization urgently needs it, it’s about taking that into account, as with the gender topic, precisely because it’s politically correct or en vogue. But that’s going too far now and is another topic.
But it’s also a piece of the puzzle in my opinion that it’s becoming more and more “complex” what you have to cover as a developer, despite if we find it useful or necessary.
My wife is not in IT but loved dark mode immediately before she even knew what it was called. She reads a lot with the Kindle app and feels it is easier on her eyes. Often I think this is just an issue that people have the brightness turned up too much or need it turned down automatically at night / bedtime but this is not a hill I choose to die on. Despite that my wife likes dark mode and it has invaded every corner of her laptop, I still love her just as she is, lol
I read a lot of my iPad. In normal daylight it uses a white background and when the lights are off it uses the dark background. When it’s using dark mode I have to increase the size of the font a bit to get better contrast but it is easier on the eyes at night.
In general, I despise dark mode for applications. Call me old - I don’t care (says the old guy).