WinUI and WinRT: Official modern Windows API now universal thanks to WebAssembly At Microsoft's recent Ignite conference, the company promoted WinUI as the best path for desktop developers, and pointed towards the third-party Uno platform as an option for Windows 7 or web deployment. "WinUI 3.0 is the future of native UX development on Windows," said Microsoft's principal program manager, James Clarke, at …
For how long? When MS will "pivot" again and change idea?
Moreover, most business application need a "simple" GUI often needing to display a lot of information in a single window - something that can be created quickly enough and without a resident graphic designer to create too much material.
If I understand it, the notion was to avoid confusion by having the same UI for PCs and mobile devices.
But we adapt easily to different environments: it's what we learn from birth. People don't get on a bus and try to order a pizza. Microsoft's enormous investment in "universal apps" seems to solve a problem that doesn't exist.
That's something managers like "write once, run everywhere" - where "write once" means "spend less time and need less developers, so save money".
Users on the other end would like to interact in different ways when they are using 30" monitor(s) and keyboard/mouse or a 5-6" display with their finger. 10-12" tablet maybe with a keyboard and a pen fall somehow in the middle.
For example, I hate my bank site. When displayed on my desktop it uses only one third of the screen, being designed for vertical mobe screens in mind. Just most people will perform more complex operations on more powerful devices.
If I ask a list of bank transfers, it can't display needed information but clicking on each line to expand it - which will collapse the previous one. If I export the list to an Excel spreadsheet I can read everything at once. It could have been done in the site display too, but it would have required two different UIs.
Or you can design a UI system that can adapt to different devices properly, or any design which needs to be used on the least powerful device will look ugly and useless on anything better.
Also, people have different devices because they are good for different things.
If I want to check how much money there is in my bank, or make a payment to someone that's already set up as a payee, I use my phone. If I want to perform detailed analysis on my bank transactions, then I will use a desktop computer with a pair of 28" 4k monitors. If the results of my analysis mean transferring money between current and savings accounts, then I will pick up my phone to do that.
So, on different devices, it probably needs a completely different design, because the use case is different.
The same GUI for a mobile device, or a touch screen or TV, or screen+keyboard+mouse is NONSENSE.
Also Win10 GUI is the worst dumbed down flat windows GUI since Windows 3.0.
Vista was the opposite issue, distracting eye candy.
What was wrong with the clear, simple visual styles and clues from Win 3.1 3D update to the simpler win9x / NT4.0 possible on WIn2K and XP?
You can't even choose on Win 10, like you could on Vista or XP. It's a disaster, never mind how universal it is to program. Also what market share has Windows outside of x86/x86-64 on something with 10" or larger screen, mouse and keyboard? Maybe less than 0.5% now. Yet since win8 they have been wrecking the windows "desktop" experience. Rapid development of a desktop application was crippled by demise of real VB6 and replacement with the VB skinned .net. Impossible to port most of the existing VB programs. Then a mess of .net runtimes
We have been going backwards for fifteen years on Windows. This isn't the future, but the last hurrah.
What was wrong with the clear, simple visual styles and clues from Win 3.1 3D update to the simpler win9x ...
Upvoted. The win3.1/9 UI isn't perfect. But it's quite usable. I've seen six year olds who are none too sure of parts of that alphabet thingee master the Win 9 interface well enough well enough to run simple games. And it doesn't handicap adults or us elderly. Let's quit screwing with it and see what we can do about a phone/whatever interface that works as well. And let's not then impose an interface optimized for small touchy screens on PC users.
Remove (window) borders, remove buttons, mangle window title bars beyond all recognition, mystery meat navigation, inexplicable UI inconsistencies, daft belief that web pages are modal applications, throwing away web standards and accessibilities in favour of 400Mb of the latest JavaScript library behemoth collections that often just badly replicate browse behaviour instead of enhancing it, inconsistent user interfaces, dumbing down of everything while discarding all notions of efficiency, reproducability and accountability... yep. Welcome to "modern" development.
Sometimes I really wonder what the hell happened to quality.
The last time round ("XAML is the future"), I tried to implement an interface in the super-dooper new paradigm.
It didn't have a date-time picker/display, and it didn't have a Chart control.
I don't have time to find replacements for controls that existed in WinForms, or to re-implement them.
So if WinUI 3.0 is to become an actual replacement, it needs to have 100% coverage of the previous controls.
Otherwise, (and speaking as someone who still has a set of VC++6 CDs in a cupboard), I'll just hang on to a Visual Studio version which does build what I want it to. I suspect I'm not alone.
ack.
And (everyone) *PLEASE* *STOP* *CALLING* *THAT* *UI* *MODERN*!!!. ('that' is to 'modern' as '70s disco' is to 'music', or 'etch-a-sketch' is to 'art', etc. and don't even get me started on the 'FLUGLY'...).
I'm sticking with Win32 API for windows applications, and the (older) MFC framework, compatible with Windows 7, and NEVER tie my application into ".Not". NEVER CLR nor anything that requires it.
If Micro-shaft DEPRECATES Win32, it'll be at their OWN PERIL (with devs - if you do not believe me, check out the TIOBE index with respect to UWP and ".Not" and C# and VB.NET and other such things, as compared to C, Java, C++, and even Python!!!)
I wholeheartedly agree. Microsoft is notorious for having a lack of good UI controls included by default. One should not have to rely on third party for pay controls for this. They did the same thing with Windows Forms. A robust grid component and an editable combo box should come standard. Same thing with things like numeric text boxes and date and date/time pickers. On the web side of things, Microsoft is trying to force people off of Web Forms and onto Blazor which of course has the same issue with a lack of UI controls. Though it's better than MVC, which was a complete joke.
Whereas UX specialists have been banging on about productivity and consistency since CLI days, the idea of a platform-owner dictating the rules for application behaviour is history: websites and mobile apps follow the "rules" only when they're impossible to evade and go their own sweet way, and that's how most users are going to interact with applications in the future.
I've wondered for a long time why someone hadn't come up with an application that looked a lot like a browser, but only did rendering, with a wire protocol for interaction between logical UI elements and a remote application (so at a higher level of abstraction than, say, X) and a more secure means for client-based programming of the UI operation. A sort of universal front end that wasn't tied to a document model.
It does look like we're headed in that direction with Blazor+WebAssembly or Uno, but "in a browser" is still a bit of a problem - something that can be better secured and doesn't offer the option of stalking you everywhere would be more appropriate. Of course it might threaten the viability of "app stores", but that can only be a good thing.
Yes, that's why apps UI are going backwards and become slower, less useful, less friendly and less powerful with each iteration.
When writing business application being able to deliver a consistent UI quickly is very important, most of the time you don't have time to fiddle with some "great design" - you want the users to be able to use them quickly without extensive training and keeping mistakes as low as possible. While complex UI requires widgets that need to be rendered quickly, and offer high interactively with the user - and different input methods (keyboard, pen, touch, etc.).
And look at what should be the showcases for the new Windows UI, take Mail, for example, it does a fraction of what Outlook Express did (security issues aside), and does it in a far worse way - while you have to desperately guess where the various pieces, commands and settings are, while hiding important info - i.e. if it doesn't sync no useful error information are displayed.
Your idea of a common UI would require a standardization everybody abides to - HTML achieves something alike, but as every attempt is just a least common multiple - and many libraries for different UIs are built atop it.
UI are a product differentiator that can bring a product to success or failure, so don't expect companies setting up a committee to design a comprehensive standard soon - and we know what committee usually design.
> Your idea of a common UI would require a standardization everybody abides to - HTML achieves something alike, but as every attempt is just a least common multiple - and many libraries for different UIs are built atop it.
Warm Braw's idea is what OSI layer 6 (the presentation layer) covers. Any new proposal doesn't have to be standardised as alternatives can exist alongside each other. For example, way back there was VT100/200 compatibility for Unix and Vax apps but 5250 compatibility for IBM mainframes and midis. They didn't interoperate but that didn't matter as organisations typically went with one or the other.
HTML could have been the new standard presentation layer for 3-tier apps but for the self-interest of the browser makers.
"HTML could have been the new standard presentation layer for 3-tier apps but for the self-interest of the browser makers."
That makes no sense at all. What did you really mean? Speculative underfunded software makers scraping-by were supposed to automatically be cross-platform OS-interaction-capable rich-UI foundations for desktops/mainframes to do business development? Wut?
a 'qualified' agreement with your explanation, but not the topic in general.
I would say that there's ALWAYS a future for writing applications to target the native UI, especially if they're performance-related.
However, in the case of ".Not" UWP and all of that *CRAP*, it's not "the native UI" and should *NEVER* *BE*! Win32 *is* the Windows API, and it should REMAIN that way!
Otherwise, Micro-shaft will be SHOOTING THEMSELVES IN BOTH FEET if it ever is NOT.
Most UX specialists are abject morons who have abolute no concept of whizz-bang-shiny. I should know, my thesis was on User Interfaces...
There is an enormous amount of value in consistency and "write-once" in the functional side of applications (Model and Controller in MVC). However there is considerably less so in the visual (View) presentation side of applications. MVC was a step in the right direction with this, however the non-text book reality is that it is genuinely impossible to cleanly separate the UI from the operational side of anything but an utterly trivial application - mostly, but not wholly so as one will necessarily dicate the capabilities of the other and they will wind up more closely linked than purists would permit. Being able to replace as necessary the View part of the MVC process is the dream, unfortunately just never well realised.
None of this was helped by Microsoft's abhorrent attempts to foist MVC into web browsers using the worst combination of JavaScript and non-standard components with a sprinkling of ActiveX along the way...
"Most UX specialists are abject morons who have abolute no concept of whizz-bang-shiny. I should know, my thesis was on User Interfaces..."
since you brought it up... the whole "User Experience" thing (vs a 'User Interface') is one of those "new agey" "feelie" phrases that cause me nausea every time I think about it, so I tend to ignore it to keep my lunch from explosively leaving out one end or the other...
Instead, I'll just say that it reminds me of a joke:
Q: How many people from Silly Valley does it take to change a light bulb?
A: It takes at least 3. One to change the bulb, and at least 2 to "share in the experience"
And I think my point has been made, now.
Indeed how long, and how about versioning? The problem with .NET is always that there is no single version default available on all targets. (and if win7 is pushing up daisies, it will probably be replaced by old corporate LTS versions of Windows 10)
If you need to deliver something simple like a tool to configure a piece of hardware then you are stuck with a runtime versioning mess with anything but the win32/64 subsystem.
Just how many layers of APIs, frameworks and interoperability platforms do they think are needed in order to do the simple task of specifying the screen layout of standard UI components for an application? Surely the answer is one, i.e. a simple layout definition in readable text format created from a drag and drop GUI designer. All the rest of the work, whether targeting a web browser or desktop window or particular OS should be done automatically during the compile and build. I shouldn't need a desk's width of breezeblock sized reference books covering all the different component layers or have to change any UI layout definitions when different versions and combinations of the implementing tech change, or new ones emerge, as they seem to every month for Microsoft. The way to standardise a sijmple solution to a simple problem is not to add more and more layers of complexity.
Yup, not sure why MS can't see this.
Old days. Open a Visual Basic app, drag and drop controls. Go
Now, open C# UWP app. Scratch head why basic controls are missing. Learn XAML to have an "adaptive" layout :/ Learn MVVM (what?) learn asynchronous pattern, and how that maps to MVVM (er, what?) Looks for datagrid, oh look there is a community one, add it, fight that it doesn't do what you want and the docs are meagre, and realise not many people got to this point to get community "help". Spend time wondering why you bothered and go elsewhere :/
Overly complicated.
Don't get me started with "MVVM" - not the concept (it does make sense), but the fucking acronym, "Model, View, ViewModel".
Can you spot the problem? It's like the braindead middle-endian American date format that nobody else on the rest of the planet would think of using: A view sits on a viewmodel, which in turn sits on a model, so why on earth is is called "MVVM", and not "VVMM", or even "MVMV" if looking at it from the other end? Either way, the view doesn't sit in the middle of the stack...
Abstracting things out into layers is supposed to make comprehension and maintainability of the code base easier for all involved. Inconsistent jargon doesn't really help the fisrt of those...
However, it is still a confusing picture, especially for .NET developers who bought into XAML and WPF or perhaps Silverlight, a cross-platform version of WPF which a decade ago looked like it might be the future. One of the annoyances is that WinUI XAML is different from WPF XAML, and Xamarin Forms XAML different again, with no easy porting between the three
Micosoft needs to unify XAML so it's the same across WPF, WinUI and Xamarin. Converting WPF to .NET Core and the development of Xamarin Forms 4 would have been the perfect time. Maybe rethink it in Xamarain Forms 5 when .NET 5 comes out next year.
As for XAML Island, when it was introduced it just felt like a stop gap that would last a couple of years.
Reviving Windows RT? Reviving XAML? Continuing to pretend that Mono is a Microsoft product?
This is, what? The third, fourth iteration of Let's Run Windows On Something Other Than X86/X64-instruction set processors? When, do you suppose, will they abandon it this time?
XAML was a knockoff, or maybe the bastard child of, GTK and Android's XML description language for UI assets, does not and had not ever allowed us lowly programmers to "converge" Web and desktop UI design.. What, exactly, is it "converging" with these days?
Finally, Microsoft's attitude to the New Dawn Of the Multi-Platform CLR, to which Novell and the Mono team beat them by twelve years or so, seems to be "If we take credit often enough, people will begin to believe." Hey, it worked for Herman Goreing and Karl Rove, so why not?
Oh, and have I mentioned that Hell is full and the dead, now imbued with Breathless Hype, are walking the Earth? Yeah? OK then. Still, we need to be reminded now and then.
"Hey, it worked for Herman Goreing and Karl Rove, so why not?"
The name is actually spelled; "Hermann Goering". And equating Goering and Rove without also including Clinton and Obama is a cute little political jab. Rove IS an ass (as are all those mentioned above), but hardly a Nazi. This is a tech article about something that's relevant. In the tech field. Next time try to keep your petty irrelevant little political opinions to yourself.
it does not detract, I think, from the idea that MS is basically issuing PROPAGANDA again... with respect to "the future" and their 'offerings' etc..
What, Silverlight was excluded? heh.
Perhaps less on the detail, and more on the concept. And it's ok to laugh at subtle jokes.
(it's my opinion that creative-minded people generally don't like 'inspector/detail' types and usually don't get along with them...)
I hopped over to the github page for WinUI and started reading the front page documentation. And what do I see at the bottom of the page?
Data/Telemetry
This project collects usage data and sends it to Microsoft to help improve our products and services. See the privacy statement for more details.
For more information on telemetry implementation see the developer guide.
Yeah, I think I'll stick with Win32, thanks.
I spent the last three months working on automating some UI tests for a plugin to Word. If u$'s own tools would actually do what they claim to do, if they had documentation as to what they do, if the associated libraries were properly searchable and linked, if they used public apis, and, if Azure were not the usual u$ **********, I would not be so very, very glad to be moving on from that work.
Yep, I don't think I ever want to touch that pile of filth again.
Jérôme Laban, Uno Platform CTO... OK, MS found brand new De Icaza, new apprentice in search for his own green card.
Speaking of Miguel, please let him retired. Mono, Silverlight, Moonlight... again? "Anything a Silverlight application can do, you can do with Web Assembly." WOW.
Next step will be Xamarin-Uno ActionSript API, adapted to WA through WxWidgets XAML version, which could run anywhere if your browser is Edgium with UWP patch which will merge TIFKAM with brand new version of XNA for xCloud that is easily controlled by slightly modified version of ASP.NET Razor.
So simple. The future is bright.
The system works today, Laban said. "Mono for Web Assembly needs to improve, ... so lots of things need to move for the whole thing to be more efficient. But it is in a damn good place for now. It actually works. It is not efficient enough for some specific scenarios...
...just like the rest of De Icaza XimianXamarin's few hundred unfinished projects (aka "the purest Xamarin" ADHD quality) .
a) underwhelming
b) as exciting as a MUZAK concert
c) as attention-grabbing as watching paint dry (reminds me of a movie I read about on El Reg...)
d) Ben Stein looks like a Dallas Cheerleader by comparison when he does his deadpan 'Wow.'
And if this means that MS is ONCE AGAIN trying to SHOVE the development world towards MONO and/or ".Not Core" for cross-platform, I'll just have LAUGH AT THEM and remind them that Java has been cross-platform from the beginning, so where have THEY been???
That, and Python GTK. And guess what's looking REALLY good in the TIOBE index right now?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
