> installed desktop web apps are really starting to look and feel like native apps
I think we are having the opposite problem: native apps are really starting to look and feel like web apps, and in many cases, they are.
The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all. It was made for documents, not apps. If you want better than that, you have to rewrite it all by yourself, or more likely, import a framework that does it for you. Traditional Windows apps all use system provided common controls, because they are good, and therefore they have a consistent look and feel, even through OS updates. It is even user customizable. Now it is not uncommon to see 10 different styles in a single screen, Windows since 8 is not even consistent with itself, and it is becoming worse every version. And it is not just aesthetics, there are serious usability concerns here, and system-wide customization is gone.
> Traditional Windows apps all use system provided common controls, because they are good, and therefore they have a consistent look and feel, even through OS updates.
This hasn’t been consistent since at least Vista and the release of WPF, which does totally custom control rendering. Circa 2006.
I think web is taking over on Windows because any of 10 or 15 different design systems can get you to a better app than the native (whatever that means) toolkits in much less time. It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do).
Even Office and Visual Studio (not Code) are using web technologies to render substantial parts of the UI.
> I think web is taking over on Windows because any of 10 or 15 different design systems can get you to a better app than the native (whatever that means) toolkits in much less time. It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do).
I'll grant you that it's probably easier and cheaper to get a workable "color picker in a web app," but I don't grant that going that route will get you a "better app than the native."
The reason why the web stuff is taking over is because it's cheaper while providing minimally-viable functionality, full stop. It's not actually good in any other way.
IMHO, the trend here is similar to the one consumer printers took.
Yes, it’s cheaper, meaning that it allows you to ship more stuff faster. You could make the argument that this results in lower quality, but this isn’t always the case. (For example, VS Code feels great!)
Still, I’d often rather have twice the features at 80% the quality, instead of an extremely high quality product that doesn’t have the features I need.
VSCode replace Sublime, Visual Studio(full) and IntelliJ IDEs for so many developers. It has all the features >90% of developers and it is faster than VS and IntelliJ IDEs
Of course it is comparable. They are not quite the same thing, sure, but for many people they are definitely comparable and more often than not, VSCode is the better option. It may not support some things, but the same can be said about the “full blown IDE”.
tngranados said "many people" and did not say anything at all about the "majority" of people.
Judging from the fact that many people choose VS Code over JetBrains IDEs, despite being aware of JetBrains existence as an option, seems to be prima facie evidence that it is in fact the better choice for those folks.
It offers about 5 to 10 percent of all functionality of an IDE like IDEA. Much like devs on emacs and vim, most devs on VS Code have literally no idea what an IDE offers [1].
The things that worked in VS Code's favor:
- free. "All software must be free as in beer" is still a prevailing thought in IT, and people are loathe to pay for anything, even if that anything is extremely useful and very difficult to realise and support. On top of that IDEA still has a reputation of being expensive
- reasonably fast
- plugin system is decent and much easier to get into than IDEA, to keep IDEA as an example
- LSP is an overmarketed hype, but it worked in VSCode's immense favor. While it only covers a tiny sliver of things needed for a fully featured IDE, it covers enough of the important features, and is easy enough to implement. This way even languages that never had anything decent beyond broken syntax highlights in emacs and vim now enjoy at the very least an autocomplete
Not really, I’d say VS Code is the only electron app that can stand up to native apps. It’s not the best, but it’s pretty good.
Now, for electron, it’s certainly not a compliment. From electron apps I’ve used, only VS Code is great, Discord is good, and everything else is just really, really bad. It’s apparently extremely hard to use electron and have something close to decent performance.
Hah, nah. Electron gets no compliment at all, backhanded or otherwise. When almost no one can create an app on it that doesn't suck, there are deep issues.
But VSCode isn't cheaper. They had to pour millions of dollars and countless man hours into it. And none of those translated into any meaningful improvements of the platform.
It isn't cheap wrt hardware requirements either. My 2.5 year old work laptop becomes unbelievably sluggish if I have to keep multiple Electron apps open.
I think I agree with you, but I need a clear definition of "cheaper."
To me, "cheaper" means that companies are putting fewer resources into Windows-specific app development. That's not unexpected, given large portions of their user base are using MacOS, Android, or iOS. Why would I hire 8 developers to make 4 apps, when I could hire 6 developers to make make 3 or even 2 apps? Oh, as an added bonus, now my app can also be loaded straight from a browser, no installation necessary? And I don't have nagging complaints from small-market-share users (Linux and BSD) complaining that my app doesn't work on their machines? Seems like a no-brainer.
From a business perspective, if the end product is good enough that the customers don't complain, what reason is there to not* use web technologies?
Don't get me wrong, I hate that half the software I use today is just a glorified Chrome tab. I hate how I need 16GB of RAM to do my job.
> I think I agree with you, but I need a clear definition of "cheaper."
I think the best definition of MS products in regard with quality and usability is "cheaper" as in "he is cheap". (i.e. only using the lowest quality crap available)
Also the deployment makes much more sense in the web. Users are always in the latest version of the software with no install / update shenanigans. This has other implications as well. The application may change internal formats since it doesn't have to worry about older instances of itself etc.
And if you build an updater in your app like chrome / firefox then it needs to be disabled for Linux distributions that have their own package manager.
> It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do).
What is a decent color picker? Everybody's idea about that is different so basically no 2 websites use the same color picker. In fact, this paper [1] found that the kind of picker (RGB vs HSV, etc...) doesn't really matter, but that better feedback made the difference. So will we get instant feedback from our color pickers now (for example text immediately turning into the color selected)? No, because designers design how they think it should look and feel, not based on how people actually interact with applications.
Compare to the best I can find for WPF: https://github.com/dsafa/wpf-color-picker - no live feedback, dialog only, no documented support for modern .NET. There are some commercial controls available from syncfusion and the like if you want to pay for such things.
WinUI has a decent color picker, but there are other trade offs going with WinUI that make it inferior to the web environment (e.g. broken rendering of SVG/paths).
> This hasn’t been consistent since at least Vista
Yes, I believe the Windows UI (at least until 10 since I haven't tested 11 deeply) is becoming increasingly inconsistent because of the many UI frameworks out there. And, while I understand that each app's developer is free to choose whatever framework UI they feel is right for them, I find it hard to understand why Microsoft is not sticking with a consistent framework for all of its apps, it went even far by using Electron for its Teams app! However, the thing that I might never get is: Why is Windows itself (and its system apps, i.e Calculator, Notepad) isn't sticking to a single framework? Yesterday, at night, I turned "Dark Mode" on and was surprised to see that "Task Manager" keeps its Light theme. It's weird how Notepad++ has a "Dark" theme while Task Manager has not!
I didn't think it's a good video. If Microsoft s latest apps don't have a consistent design, they have spent more money on designing each of them separately. Each of those hover effects and custom title bars needed to be coded separately. That undermines the idea that MS "hasn't prioritised spending on design because it won't help their enterprise customers" and shows it's just an organisational problem.
> This hasn’t been consistent since at least Vista and the release of WPF, which does totally custom control rendering. Circa 2006.
Ignoring 3rd party apps, to me the windows UI died with XP where the consistency stopped being somewhat pushed on the base OS/UX itself.
Strictly speaking nobody cares what APIs are being used or if there are multiple of them as long as they convey a consistent UX. If a consistent UX is pushed on a system level, even custom apps will try to stick to it (see macos).
But the sad truth is that on windows there is no longer one. W10 can show you dialogs from the windows 3.1 style up to a WPA, and you'll likely encounter a mixture all the time because there's no consistency.
I sometimes watch retro hw channels and looking at windows from 3 to 2k reminds me the stark difference.
Office is using web technologies because they don't want to rewrite their code for Office 365, so native users get the Web stuff on a Web widget instead of a proper native UI.
Which is kind of tragic, given how Office was the testing ground for many Windows UI components.
????? Nobody is saying that there aren’t webviews in office I am saying that your statement that most of the desktop office ui is now non native is false and misleading. After reading your other comments in the thread it seems like more of a personal vendetta than factual statements. lmao
Nope, you're the one interpreting that way, I only mentioned that they are adopting Web stuff as means to reduce code duplication between Web and desktop, via Webviews exactly.
So unless you're on the Office team and want to tell us anything, please do lmao.
Personal attacks will get you banned here and ethnic/national/racial attacks will also get you banned here, therefore please don't post like this to HN.
That's the problem: it does not work. I don't care if the programm is written in assembly or in rust as long as it functions properly.
But when the blinking cursor stops blinking, when the scrollbar or window border is so thin that i cannot select it with a mouse, when the title bar is so cluttered with buttons that any click brings up a menu instead of being able to double click or click and hold, then _it matters_.
I stop here in order to not throw profanity at MS engineers.
This is evidenced by the layers of settings UIs in modern windows from old school systems properties dialog to newfangled display settings, and in between. It is horrible. They just bundle these UIs atop one another there is no overall usability oversight.
The Diagnostic Tools window is implemented as a web view, probably since its introduction in… VS2017?. I’m not aware of any other GUI parts implemented using web technologies.
This is what I was thinking of. Kind of a telling statement of Microsoft’s perception of WPF when they turn to WebView2 to render newer parts of the UI in their WPF app (which was never ported to WinRT, UWP, or WinUI). They didn’t even use XAML islands for the newer parts, they just jumped straight to web.
I also spent quite some time building desktop and mobile apps (5, maybe 6 years) and also more than 10 years of building web apps and don’t really share this sentiment.
My feeling is exactly opposite. CSS is messy and hacky way to build layouts (the famous “how to center a div”, etc.) while with UI toolkits it tends to be much more straightforward and standardized.
When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.
> When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.
The html-apps-as-a-local-app (like electron-based stuff) became popular prior to "how to centre a div" was answered.
IOW, they became popular in spite of having shitty layouts specifications.
Before flex and grid CSS had most complex, least friendly and (probably) least powerful layout definition system compared to everything I knew. Creating unecessary elements just to trigger primitive CSS mechanisms was commonplace as was having >3 methods to do some primitive layout task (like centering) depending on where that task was needed. Tables were popular so long because you could do 80% of what CSS could do while knowing <10% of what was needed to do layout without them.
After flex and grid it is just most complex and least friendly. You still need to know all the gotchas if you work with legacy projects or with imported components, but at least there are some sane ways to do basic layout tasks.
For me still nothing beats Adobe Flex when it comes to layout. Without much experience I could easily create UI that looked and behaved good without any resizing problems (although as I remember mobile phones were never supported).
Adobe Flex is one of those things that while I really enjoyed it, Adobe just isn't a good steward of projects/products like it. I do wonder what it would be like if some other large tech company either invented, or took it over.
Flex could be used on mobile through Adobe AIR, but it was slow, and felt all kinds of wrong. This was one of the downsides to Flex, too, in my experience.
IP Address Control -> Is this really so common it needs a custom box? does it handle IPV6?
List Box -> Not sure but making a list you can scroll through is trivial in HTML. you set a height of the container and mark it as overflow: auto. Done.
Pager -> seems irrelevant on a browser
Progress Bar -> progress tag
Property Sheet -> N/A
Rich Edit -> This was never good on Windows and it's also not good in HTML. In both cases if you want something that actually has a good UX you have to roll your own or find a library
Rebar -> Flexbox/Grid
Static Control -> most of HTML and far more easier to style
SysLink -> anchor tag
Tab -> trivial to implement in HTML but ok, maybe should be standardized?
Task Dialog -> dialog tag
Track Bar -> input type=range
Tree View -> You can do this with nested detail tags. Not sure it's any more work (in fact I suspect less) than a tree view in C++
Up/Down Control -> input type="number"
It seems all there are far more flexible.
I don't really know which apps you're referring to but I feel like most of the windows apps I use are not using those default controls or if they are they've added heavy customization
It means that you've never really developed an actual app. And that you haven't ever thought about all the controls and layouts (with their complex interactions) even in the apps you use daily.
No. Menu isn't "the one control". Menu is one of multitude of controls. Go ahead and try and implement a treeview correctly with nested details (including all the necessary keyboard interactions). Meanwhile treeviews have been a part of native UI kits since... the 80s perhaps?
Oh, and since listviews are so "easy" in HTML, can I finally properly animate adding elements to one or removing elements? With height:auto? And without needing to redraw and re-layout the entire page? Right...
Dialog tag? Does it keep keyboard focus inside the dialog, or do you have to write non-trivial amounts of JS to have this required accessibility feature?
And so on and so forth.
And those are just the most trivial things native UIs solved half a century ago.
>List Box -> Not sure but making a list you can scroll through is trivial in HTML. you set a height of the container and mark it as overflow: auto. Done.
As long as your list doesn't contain elements that are too complex, or has too many elements. Otherwise, you enter the world of lists with recycled items, and while Win32 and pretty much every other toolkit has it by default, and oh boy does the web suck at that.
Recently I needed to work with low-level Windows API and default controls. The experience was horrible.
Windows GUI API after 30 years still does not provide any kind of a layout manager forcing to position everything manually on size changes.
A trivial-sounding task like background image beneath controls required days of tries and many lines of code that looked like Voodoo practice than any rational programming.
Then the code uses a custom title-bar that was necessary to update to support Windows 11 snap layout menu. It turned out in the initial release of Windows 11 it was impossible to get that and rounded corners around the application window. Windows relied on undocumented heuristics to infer the desired behavior and if their guess was wrong, one is out of luck. At least Microsoft added API to fix that in a later Windows 11 update.
So it is not surprising that many applications just gave up on that and use WebUI. At least that works much more reliably and in the worst case one can look at the source code.
I think you're not being very fair when it comes to web apps; I think they're a much lower barrier to entry in these days than native applications, especially if you want to target developers who will demand Windows, MacOS and Linux apps from day 0. There are no good cross-platform alternatives out there, with as big a pool of developers or as big an ecosystem.
I mean webapps suck, cross-platform mobile apps suck, and native apps on both desktop and mobile are vastly superior and I will die on that hill. But I understand the tradeoff.
> I think they're a much lower barrier to entry in these days than native applications, especially if you want to target developers who will demand Windows, MacOS and Linux apps from day 0.
Let's be honest, we had multiplatform apps well before desktop-web apps. We are in this situation because GAFAMs pushed very hard the paradigm of always connected web applications (because they had no control over applications running solely on your computer). And since they won this ideological battle, there is not any more investment on multiplatform toolkits.
I really think that all of this is due to political reasons and it have never been about the superiority of the web technologies.
HTML+CSS started as basically a desktop publishing technology, but that's not the case anymore. There's fantastic support nowadays for building app experiences, from the perspective of layout and interactivity. Fair point on system-wide customization, although I really don't miss it. Maybe it's the experience of the web, but it no longer seems weird to me that apps have different design paradigms. But realistically, desktop hasn't had unified design since Java applications started becoming popular 20 years ago.
I actually wish programs do not put content in the Title bar area. The title bar area is meant for users to move the Window around.
Try opening Microsoft Word, make the window narrow and drag the window. You have to hunt for a small bit of empty space in the title bar or you have to understand you could drag on the Title text, Search box and the Sign in Username, but not the Auto Save text, Upcoming Features icon, or the Ribbon Display Options icon.
I much prefer what a lot of Linux desktop environments support, which is holding down alt and clicking anywhere on a window to move it. With that + a keyboard shortcut for closing a window you can get rid of title bars on apps entirely if you want. Sadly Windows doesn't support it natively, although there's another comment on this thread talking about ways to make it work.
I love this feature and it's since become indispensable to me. I find it pretty funny that my #1 favorite desktop UI feature is from Linux. One of the first things I'll put on a fresh install of Windows or MacOS is a utility that re-creates this behavior.
That's awesome, I remember when I was a CS student in college I also fell in love with the alt+drag of windows on Linux and I wanted to bring the same on my Windows PC so I wrote this extremely hacky and very unstable tool: https://github.com/Morgawr/EmptyWM
It was one of my first "open source" projects and a great learning experience, I would never recommend anyone to use it because it was full of bugs (also I haven't touched it in like 10+ years) but I used it every day and it was such a great feeling just being able to improve my own life with tools I created myself. :)
I'm hoping that Microsoft just implements it natively eventually - their window snapping/tiling-lite functionality has been steadily getting better so they clearly have people working on this kind of window UX QOL stuff.
There's a Microsoft utility calls powertoys that makes the window snapping/tiling even better with it's Fancy Zones feature. Also has a color picker which someone in this thread was decrying the lack of on windows.
On the flip side, I have become so used to AltDrag behavior on windows, that now I consider KDE alt-drag subpar because it lacks the right-button drag to resize.
Me too. Don't forget about right-click + key to resize the window. I have to use a mac for work and so use Easy Move+Resize to get this same functionality.
Desktop windows should be able to have tabs sticking out of them (independent of whatever window title bar they may or may not have, but possibly showing the title or document name or message), along ANY edge, that you can drag around to the desired edge and position, that help you arrange the windows in piles and rows and columns.
Restricting tabs to the top edge of the window is stupid, because text is much wider than it is tall, so you can fit a lot more labeled tabs in a vertical column along the left or right edge of the window, than in a horizontal row along the top or bottom edge of the window. The tabs you get along the top edge of Chrome are useless when you have a lot of tabs opened, because all you can see are the icons, and none of the labels are visible.
That way the tabs are all visible even when the window isn't, and they afford a very easy way to see all the window titles at once, bring the window to the front, drag it around, and pop up pie menus to do things like push it to the back or front (down/up gestures), iconify it, make it full screen, and other window management commands.
>HyperTIES browser and Gosling Emacs authoring tool with pie menus on the NeWS window system (1988)
>HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab. This screen snapshot shows the HyperTIES authoring tool (built with UniPress's Gosling Emacs text editor, written in MockLisp) and browser (built with the NeWS window system, written in PostScript, C and Forth). The tabbed windows and pie menu reusable components were developed by Don Hopkins, who also developed the NeWS Emacs (NeMACS) and HyperTIES user interfaces. (Sorry about the quality -- this is a scan of an old screen dump printed by a laser printer.)
Tabbed windows in combination with pie menus are the ingredients for a great window manager.
Ok as a compromise perhaps developers can show custom content in the title bar for a few seconds after startup. That way, the developer can show that they have mastered control of that area, while the user can still drag the window. Win-win.
Windows has pretty decent keyboard shortcuts for manipulating windows‘ positions, though. Clicking and manual window manipulation should very rarely be necessary, shouldn’t it?
I also dislike how apps are now disabling the classic win32 app icon in the top left corner. If you click on it, you get a menu with window management options and double clicking it closes the window. It’s so burned into my muscle memory as the way to close a window I get frustrated when apps hide it.
About 15 years ago, I remember being aghast at Skype hijacking the X in the top-right, minimizing itself to the taskbar instead of either exiting or minimizing to the system tray. Because there was a clear standard action that was intended by that interaction, and Skype had gone out of its way to override that standard action.
I won't say I'm not annoyed at it. When I want to switch back to the Linux partition and Windows instead decides to spend half an hour installing updates, it becomes another reason not to switch to Windows the next time.
Well, here's an AHK script for those that want to move away from depending on the titlebar drag. Use Alt+Shift+Mouse drag anywhere on ANY window to move it on Windows (puns unintended):
I would paste to gist.github.com but the corporate overlords won't let me
If you already have a script running at startup and all that, you can save this as a standalone file called e.g.
winmove.ahk and add the following to your existing script:
I have something similar in my Linux setup, Win+LMB anywhere on a window drags it, Win+RMB resizes. Never used a title bar again, highly recommend if you can get a similar setup.
For moving things around across monitors & snipping them to specific half of desktop I personally use Winkey+[shift]+arrows shortcuts, I recommend you check it out if you haven't already! I honestly don't remember when was the last time I needed a window with custom size. Maybe when placing 2 windows side by side? But even then, the OS recognizes that I want to see 2 windows at the same time and adjust sizes of both windows...
Same thing with, e.g., firefox on ubuntu. Not only do you have to hunt for free space, but because of visual design (in turn because of vanity and frivolity, IMO) it's not clear where it is until you mouse over it and display its highlighted color. The "close" button barely even changes color on the default theme, so god forbid you single-click it. And tabs can accidentally be dragged, rather than just failing to drag the entire window.
This next part is more of a funny absurd story than a complaint, but I once had a recurring bug where the browser UI was shifted down a hundred or so pixels from the top of the window, replaced by some flat "blank" color. But the interactions were still taking place in their expected areas. So in order to fix that, I had to hunt around with my mouse at the top of the window, look for UI elements to become highlighted in the middle of the window, and then move left or right until I was confident I was over the title bar (which I couldn't know for sure, since it itself doesn't highlight).
The most basic of window operations shouldn't require a hotkey.
Rearranging windows on MacOS and Windows now requires video game precision aiming. It is absurd.
What's more, every app places things in different parts of the title bar, so I have to search for "where to click" based on which app window is up. Absurd.
The move to controls in the title bar is absurd. It used to be Windows had standard chrome, title bar, then menu, toolbar, then content area. Now days it is the wild west what UI elements are where.
The most basic of window operations wants to be bound to a hotkey because it's a basic window operation and there should be easy and quick access to it. Linux does this by default and I find it's an indispensable feature.
The most basic of window operations should have a visual affordance right in the UI because they're basic and no one should have to pause and ask themself "how do I move/resize a window?"
Remember your Bruce Tognazzini. Shortcuts are just that: shortcuts. They are NOT your primary interface. Everything should be visible and usable with just the mouse.
It's for this kind of nonsense that I have "alt-space -> s -> down -> right" burned into my fingertips followed by moving the mouse cursor to resize a window deterministically (along with "alt-space -> m -> any arrow" for move, doubly useful to "rescue" an off screen window)
Default behavior for Windows applications (since 3.x, I think). Alt-Space brings up the Window menu.
Some odd-ball apps will replace it with their own menu, but few apps go to the effort to override the default shortcut it, even if they otherwise hide it.
Works on windows for me. Also never really thought about this for rescuing a stuck window, I've always used winkey + arrow keys and kept mashing buttons until it appears on one of my monitors :P
Gnome doesn't have menu accelerators in the window menu though, so "alt-spc n" does nothing: the alt-spc brings up the window menu, but the n doesn't activate "minimize". This interaction not functioning in Gnome keeps me off Gnome entirely.
super+h minimises. pretty sure you can make it anything you want.
if you're looking specifically for "alt-spc n" to minimise I'm sure you can find a way to make that work - but why? to retain muscle memory between windows and gnome?
Random sorta related complain: at work when I'm using two different-sized screens, sometime when doing a click and drag to move a fullscreen window from one screen to the other, it's not the top one that's going to get dragged, but instead one 'below' it. Really annoying
Hard disagree. Vertical space is a scarce resource and I hate when it's used for dead space I can't get rid of or use productively. Alt-drag is the way to go.
Vertical space should not be scarce. 16:9 or worse display is the root issue. Framework has a 3:2 and it is lovely though a bit glossy for my taste. Portrait external is another option.
Both on my main machine at home and in the office, I have a 32" 2560*1440 screen and a 24ish 1080p (they work out more it is the same pixel pitch) beside it, which I often effectively use as three portrait screens, sometimes using FancyZones so that the divide on the 32 isn't right in the middle. The setup is a bit tall when sat thought, potentially causing neck strain, but I tend to use the standing desk in up position so that isn't an issue. Tall screens are much nicer than landscape IMO.
The Windows style for bars (both title and status) is way too large. Ditto for the task bar.
It's no wonder people are tempted to not use status bars, and shove as much as possible at the title. If applications could exploit the task bar, they would too.
(Anyway, you don't need an entire bar for system interaction. But applications aren't designed in a way that allows this.)
The older I get, the more I respect bigger user interface elements and text.
It's not even failing eyesight either; I'm still in my mid 30s and have great eyesight and dexterity. I've come to respect bigger interface elements because they are quicker to work with.
I don't have to peck for a title bar if it's there, big and empty in front of me. I don't have to hunt for a scroll bar that hides itself and reveals a 1px wide sliver if I hover over it just right, if the scroll bar is big and always visible. I don't have to aim my mouse like I'm playing a fucking sniper in a fucking FPS if the buttons are clearly texted, colored, bordered, and large.
Being able to /just fucking use the interface/ with broad motions is a fucking godsend. The trend of minimalism, hide-everything, gray-on-white interfaces gets in my way and wastes my time and nerves.
Unfortunately, the designers all seem to have 72" 8K professionally color-calibrated monitors and a $1000 mouse, and think if it works for them that's good enough.
I saw the start of this in the mid-2000s when the web trend was for grey-on-grey 8px fonts. I went to the designer and asked what the heck he was thinking and he showed me his screen; and yeah it was kinda legible there. Still bad design.
Nowadays the trends are flat UI where you don't even know what's clickable/actionable, hidden things that only appear when you mouseover them, and on touchscreens, secret functions that only trigger if you swipe in just the right way with just the right number of fingers in just the right pattern.
Design has just been getting progressively worse and worse ever since 2000/Windows XP.
> Unfortunately, the designers all seem to have 72" 8K professionally color-calibrated monitors and a $1000 mouse, and think if it works for them that's good enough.
Years ago I came across a project developing software for use by soldiers (maps, messaging, that sort of thing). The devs made really tiny icons for the various map symbols. One day an actual soldier came in with a ruggedised terminal and asked the devs to demo the software on it, using combat gloves. Needless to say it was unusable and there was a great gnashing of teeth.
The same project also gave rise to the best bit of user feedback I've ever seen. At an exercise where the software was being trialled, the commanding officer asked one of the soldiers what he thought of the software. He replied (in a northern English accent) "The fucking thing is fucking fucked, sir", and the trial was cancelled about ten minutes later.
The larger the elements that you don't use all the time, the smaller all the other ones have to be.
If you have large high resolution screens, you won't miss the space, but you can't blame people for optimizing their own applications for the screens most people use.
You're telling me I can't afford an 8 pixel wide scroll bar on a fucking 1920 pixels wide monitor?
Meanwhile nearly every article nowadays has a useless header image that takes up the entire screen, pushing the content out of view until scrolled down.
Give me nice and thick title bars and window borders, give me wide scroll bars, give me ginormous buttons with proper borders and textual descriptors. Minimalism is nonsense if critical contextual information is denied.
> If you have large high resolution screens, you won't miss the space, but you can't blame people for optimizing their own applications for the screens most people use.
Have you seen the new Microsoft calculator ? (i.e. calc.exe).
It seems to be designed to be operated by spear throwers from 100 foots away.
It's not, or at least it wasn't prior to ~Win8 or so. Yet monitor resolutions have steadily increased, so perhaps it's a reasonable on with a huge monitor.
Anyway, you don't need an entire bar for system interaction
Having to click on a tiny area to move a window, instead of a relatively wide rectangle, is a huge regression.
That’s a real problem, of course, but it seems fairly equivalent to any native app you install that can update itself or otherwise make a network request to obtain instructions.
Native apps that autoselfupdate have RCE vulnerabilities by definition and should be considered remote access malware already, before the developer release keys are compromised.
I am the reason Signal desktop now has a preference to opt out of autoupdate.
I agree with you. On the other hand, in the case of a native application, we can hope that the antivirus removes it. I hope that Microsoft has planned to update Defender accordingly.
That was my first thought as well, but I couldn't remember the name for that boundary. I hope there is a well-designed per-site control/setting/user consent system to keep tech support scam sites (or worse!) from adding one more tool to their arsenal.
With all this Electron and PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system, that could be avoided. An extra layer which occupies RAM space and processor time which feels unnecessary but it is where we are headed. I wonder if the reason is simple, that we (myself included) have not provided anything better or the reason is that big corporations who control most of the market have pushed this technology forward. I hope we can learn from this and bring back some of this lost performance while keeping the productivity and security gains.
The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer.
The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.
I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me.
Now, I've never ported an app to mobile, and that may be entirely different. However, and this may be an unpopular opinion, I don't want developers building an app that's meant to be used on a mobile device and a desktop. They're 2 separate ways of using a computer and they should be treated as such.
When I think of desktop apps like Photoshop, Outlook, Word, Chrome, and Da Vinci Resolve, they all look and behave very differently than their mobile counterparts (if they have one). If you want to develop for mobile and desktop, then you need to invest the time to make it a good experience on both. I hate desktop apps that have been mobile-ified to support mobile-first design. Design a proper UI and UX for the platform you're targeting. Otherwise don't bother "supporting" a platform you never test, intend to test, or design specifically for.
> Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.
Out of all the apps that I listed, I don't believe any of them use native desktop widgets/controls/ui frameworks, except the Microsoft products. And even then, the Microsoft products are definitely using customized widgets which means they're writing a lot of custom rendering code anyways.
Edit: I'd also like to add that the original comment said that electron is portable, implying that portability is a tremendous feat. This is what I'm arguing against. Sure if you wrote your entire app in WPF, that's going to be next to impossible to port. But if you want to make a cross platform app, then it's not difficult to use a framework like QT to have a native cross platform app as opposed to embedding an entire browser runtime to get a portable app. This false dichotomy is what I don't get. It's not 2000 anymore, there's no reason portability has to be treated as some boogeyman that can only be solved by shipping extremely bloated software for a native cross platform app.
Java Swing apps were portable across Windows, Mac and Linux desktops waaayy back in 2004 and probably earlier. Write once run everywhere _was_ very much possible back then.
The biggest complaint was they didn't look native. From working on a Swing application back then, management and marketing would often ask if we could make it look more like other Windows applications, because looking like a native Windows XP application suggested it was modern and cutting edge.
As soon an iTunes landed on Windows, the requests for UI improvement changed from "make it look like Windows" to "make it look sexy" - which meant different things to different people.
Electron, to me, feels like an attempt to take a browser engine and turn it into a poor replacement for the JVM.
I worked on Java apps around that timeframe. Despite spending a lot of effort refining our widgets and using some animated transitions (ref the "Filthy Rich Clients" book) the applications generally felt more dated and cheaper-looking than native apps.
For enterprise apps with no strong competitors these minor aesthetic issues didn't impact revenue so those UIs remained in Java. But for everything else it was worth it (financially) to migrate to native.
I sometimes armchair quarterback and wonder whether Java would have been more successful if the Swing folks had focused more on design. It seemed like the most they ever did UI wise was attempt to catch up to platform native widgets so they were perpetually several years out of date and slightly inconsistent. Had they skated to where the puck was going to be rather than where it is perhaps Java applications would be the ones people pointed to when asking devs to "make it look sexy" instead of iTunes.
Yep, we did some deep customisation of a couple of key UI widgets and found it very time consuming. Changing the Look and Feel to Nimbus was a major improvement, but that came with semi-regular breakages when performing minor version JVM updates. I vaguely remember us overriding a couple of Nimbus defaults but finding that could have unexpected consequences elsewhere in the UI (ie LaFs are complex), so we didn't go down that path much.
While Swing styling support wasn't that great, I miss the flexibility of nesting layout managers for composing complex, resizable UIs.
When Java FX was first announced, I started learning it to see how we might use it for our applications. At the time it lacked a lot of widgets we needed, but it had much better support for styling. Sadly I didn't keep up with Java FX. While I have no direct need for it in my current job, I still get the itch to whip up the occasional desktop app, so I plan on getting back up to speed soon.
> The optimistic scenario is that WASM becomes the single target that everyone settles on
oh hell no. I reject this in the strongest possible terms. You don't need a web browser to create a program. This is pure laziness. I am a developer. Browser based app is fine for small stuff. But nothing as large as Visual Studio Code, should ever be created as a browser app. This is just an awful idea because it results in dogshit performance, an order of magnitude worse than native solutions.
I encountered hell the other day. I saw a corporate Citrix deployment that had 45 users running three electron apps on an underprovisioned server with the CPU, disk and memory rammed at 100% lagging out. That’s 135 separate browser stacks basically.
Microsoft are moving office to this stack as well. Ugh.
Of course I was there trying to work out why our simple old fashioned web app was running slowly in a chrome tab…
Our hospital system uses Citrix and the application patients have to sign in with runs on some web framework instead of being a native Windows app. Such a frustrating experience using the on-screen keyboard to enter your name to sign in.
It makes perfect sense for the user but developers will always argue for Electron so that they only have to test one browser engine.
I can’t even gets web devs to test on anything but Chrome and when something they code does break I have to listen to the Safari whine even though they all use iPhones so are part of the reason it’s relevant. Dread to think how an argument for supporting 3+ web engines for a “native” app would go.
A lot of developers are not fans of Electron. Generally, it's a quality vs quantity tradeoff. Are you willing to make a crappier thing if it means more people can use it?
For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.
> For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.
Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up. While I am sure the Windows org had lots of them, put out a job req and even internally not very many people are going to have native Windows development on their resume.
Nearly had to draw straws to see who had to get "stuck" learning Windows stuff.
I imagine native MacOS developers are similarly rare as a % of the overall developer pool.
Android and iPhone developers, easy peasy.
Likewise, Web developers, not a problem.
The other thing is, Electron has tons of momentum behind it, which means more and more people jump onboard to learn it, which makes hiring easy. Tutorials and learning resources get made, making developing for it even easier.
IIRC we ended up dropping the native C++ Windows app and just used C# and one of the UI toolkits, I forget which one.
> Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up.
Microsoft only has itself to blame for this. They charge an arm and a leg for their dev environment setting it up is a pain no matter what, the stuff you get “free” when you pay for the dev environment is not nearly enough to create anything worthwhile. So why should any CS department bother with win32 circa 2005. As much as Balmer liked to chant about the importance of developers he sure liked to milk them dry.
For decades MS had the best development environments, best training, and best documentation.
MS fucked it up with the wpf->silver light->winrt transitions.
Win32 is a horrible API but it was stable and there was a time Win32 developers were everywhere.
Visual Studio is still one of the best real IDEs out there. The tooling for modern languages is a sad joke compared to what we had in 2005. And modern documentation is so bad it is absurd. People don't realize how much $$$ MS used to spend on sample code (MSDN samples were large fleshed out sample products!) and on documentation teams.
Comparison point, last time I tried to use Google cloud, I had to use the way back machine to look at an old version of the docs because the embedded sample code had gotten broken during an update 2 years prior and no one ever fixed it.
You forgot another two major fuck ups, killing .NET Native and C++/CX, without a proper migration path to a GUI framewokr that is anyway WIP and will take a couple of years to even reach some kind of parity with WPF.
I still mostly use Microsoft technologies, but that was a big middle finger to everyone that was willing to go through all WinRT rewrites since Windows 8, advocating for the technology.
It may be more the myriad of technologies and the fact that they change them out almost as often as their underwear. Same problem we have with javascript frameworks.
What is it that we need 10 years experience in this week? Win32, OCX, DCOM, CORBA, OWL, ActiveX, WinForms, WPF, ASP, SliverLight, .Net, XNA (etc. etc.)?
Kind of amusing that so many people turned to web tech to escape that treadmill and then just totally recreated it in javascript.
When WinDev keeps pushing for stuff like COM, with tooling that already felt primitive when Visual C++ 6.0 was around, it is no wonder that they have such hard times.
Eventually even those of us that know Win32 quite well don't want to deal with it.
What seems even crazier is not even wanting to test against different builds of Chromium to help keep pace with Electron updates. At that point isn't one's code just too brittle?
> Dread to think how an argument for supporting 3+ web engines for a “native” app would go.
Well, on mobile, it's slightly different. If you use Capacitor, it uses the OS' native WebView, which is either Chrome (Android) or Safari (iOS). You gotta test for two web engines, but fortunately, they're relatively close.
I think a solution like this for desktop would make sense. Modern browser engines don't have that many differences and it would make the runtime a lot smaller (thin wrapper around the already installed browser engine).
Sure, it has its downsides, but mobile apps have been written like that forever (via PhoneGap before and now Capacitor) and have come a long way since.
I mean I wish I worked with people with that opinion but somehow the 60+ devs I've worked with over the past 5 years manage to code things that work in Chrome but with many parts broken in Safari and an attitude that it's Safari's fault.
I have little patience for this attitude because the period of time I worked as a dev I had to support IE5.5, IE6, IE7, Safari, Firefox and Chrome. But it is the prevailing attitude.
That won't meaningfully change performance at all. Browsers aren't slow because they have to make slow syscalls - they mostly don't. They are slow because web technologies themselves are slow, sometimes by design, sometimes because of security/abuse concerns, but often just because HTML & CSS are absolutely crap platform for interactive UIs, something they were never intended to be and retrofitting that doesn't result in a very efficiency stack.
> HTML & CSS are absolutely crap platform for interactive UIs
I mostly disagree. HTML is great for plain forms, that seamlessly work at different form-factors (from mobile to desktop) with very little work. Browsers are also good at graphical outputs.
Browsers can fall down when you need rich, complex, or custom inputs: because virtual keyboards are very different from real keyboards (iOS especially poor), and touch is very different from mouse, and game consoles are something else again!
But we go where the users are, which is usually a wide variety of devices which makes browser based deployment the default choice, so you work within the limitations of browsers.
I'm not sure I'd call that an "interactive UI" though as that's pretty much a static layout. Which yes HTML is fine at handling.
> Browsers are also good at graphical outputs.
They're okay graphical outputs, not good ones. The feature sets are good, but the performance is all over the place and pretty much always sub-par as they are very defensive against content. Meaning the difference between the fast path (so plain scrolling) and the "slow" path (nearly anything else) is absolutely massive. Even things that are all but free on native toolkits, like just animating a color, can tank browser performance.
> But we go where the users are
Of course, which is mobile apps ;)
No but the point is just browsers aren't slow because they are an OS inside an OS. The layering isn't the cause of really any problems other than the binary size of the browser itself.
I have seen this attitude on HN before, and it really confuses me.
You know what an OS is, right? You can't just say, "the browser window is the only window" and say that "is" the OS. At some point some native code is going to need to send bits back and forth between hardware. You will need to provide a filesystem, you will need to provide device drivers, you will need to provide a windowing system, etc etc.
By the time you get from NAND to usable browser, you will have build an OS. Sure, I guess you could throw in a JS runtime and insist all user level software is in node/HTML/CSS, but there is still an OS underneath all that! (And the OS isn't why it's slow anyway.) There is so, so much more to computers than running JS and rendering HTML and CSS.
better yet we should just outlaw personal computers and laptops, they are causing too much trouble. Better for everyone to just have iPads and iPhones, kill Android too.
I choose it for portability. I can ship to my users today, work on new features for all users, or I can spend 3-4-5-6 months dealing with differences in platforms, differences in tooling, build environments, deployment, etc....
I also it choose is because as a programmer it's far easier IMO to make a web tech app look good than a native app. CSS, Unicode text, emoji, images, video, canvas, webgl, it's all easy, portable, and batteries included, vs the various platform specific ways of providing those features.
I'm gradually starting to see X11/Xlib as a solution for cross platform desktop apps. It is the native GUI API for most UNIX operating systems. Ports exist for Windows(win11) and Mac which makes X11 technically portable to them as well.
Its not exactly an elegant solution I have to admit. But the licensing problems with QT make a lot of people nervous, GTK seems to be pretty polarizing, and for whatever reason WxWidgets and FLTK never really got much adoption/didn't progress very far.
I think wxWidgets was pretty big in the 2000's, with quite some programs using it. To name one example, the Code::Blocks IDE uses it.
FLTK has never seen adoption even to the level of wxWidgets I think, but to be honest it is also quite simply hideous. I have not found a proper looking theme for it either, since I was mildly interested in using it to add a simple GUI to a Rust tool.
I don't know why WxWidgets seems to be less popular now than it was back then. I remember it being somewhat popular. Now people hardly seem to know about it.
FLTK looks horrible next to most modern applications. But FLTK 2.0, which has been abandoned for 10 years, actually looks pretty modern and the API is actually pretty elegant. There was some kind of split in the community about FLTK 2.0 breaking backward compatibility and I guess the 1.0 people won in the end.
When you see decades of Windows version after Windows version, each billing itself as "the fastest Windows ever!" and each having higher minimum system requirements than its predecessor, two conclusions are inescapable:
1. The Redmond wizards have devised a method to make software run faster and all it requires is faster hardware.
2. Microsoft is in bed with hardware manufacturers.
The system requirements are something they put out on paper, parent isn't necessarily saying you need a better PC, just saying Microsoft themselves say that, which you can verify yourself.
Modern Windows PCs feel very noticeably snappier and more responsive than older ones. For all my complaints about Windows, that certainly isn't one. I've had to go back and work on old XP boxes, and that is not a pleasant experience.
Admittedly a good chunk of that is SSDs, and better hardware plays a role. But hardware was going to get better anyways regardless of Windows - at least they didn't use the better hardware to make the effects fancier/get sloppy and end up at square 1 like so much of other software.
Quick shout out to the Compiled HTML[0] (.chm) format for similar but unrelated reasons. The Help viewer application was one of the pinnacles of good UX, in my opinion.
A while back at $DAYJOB I tried to get a CI pipeline to bundle our docs as .chm, but the official tooling (hhc, with-or-without Sphinx as a frontend) is windows-only pre-unicode nonsense; the only Linux native chm compiler i found was Halibut (from the author of PuTTY) which has many of its own idiosyncrasies.
Is there any normal-looking way to make a chm from a directory full of html files?
It's kind of impressive that one can still run the same .hta app even on Windows 11 according to the wikipedia article:
> HTAs are dependent on the Trident (MSHTML) browser engine, used by Internet Explorer, but are not dependent on the Internet Explorer application itself. If a user removes Internet Explorer from Windows, via the Control Panel, the MSHTML engine remains and HTAs continue to work. HTAs continue to work in Windows 11 as well.
Now, don't get me wrong, I love the idea of progressive web apps, but the web is also easily the very least secure thing I do with my computer on a regular basis. The last thing I want is yet another way for a web page to pretend to look like a native app. Even with my decades of experience, I am liable to be fooled in a hasty, tired moment, and I suspect I'm not alone.
In other ways, web environment is the most secure part of your OS. Download and install an .exe and it's essentially completely unsandboxed and has free reign over your computer. These 'PWAs' are much more limited and scoped.
That's the first article that came to mind when I read the article: this is going to be a godsend to phishers. Granting random sites the ability to render a counterfeit toolbar, including an address-bar with the green padlock that reads "https://bank.com" or "https://sso.internal.corp.com" will be a security nightmare
Worth noting that this feature is limited to installed PWAs, so you'd either have to convince the user to install a PWA via the URL bar affordance (which already requires real HTTPS and respects the LOD), or to manually install a site-as-app through the browser's (relatively buried) UI, at which point you get the same site you're already on, but with a new titlebar. That seems like a pretty unrealistic vector and is much less complex then just getting users to install an .exe.
That said, even with the Window Controls Overlay, the minimal browser controls (close/restore/minimize) are mandatory, as is the browser-owned "..." menu which includes basic trust information for the site as well as app controls (uninstall, permissions, etc.).
> so you'd either have to convince the user to install a PWA via the URL bar affordance (which already requires real HTTPS and respects the LOD),
Getting a valid SSL certificate for getFakeSaas.com is free, and respecting LoD has no effect at this time. Once the PWA is installed, there is no LOD, amd my PWA can phish any domain I desire with faked affordances.
Separately from the issue of titlebars, I want Chrome's PWAs to open external links in my default browser (Firefox), not a new Chrome window.
Sadly I can't make Firefox install web apps as system icons because they removed experimental Firefox SSB support (they said to reduce maintenance overhead). Interestingly I found https://addons.mozilla.org/en-US/firefox/addon/pwas-for-fire... but have not tried it yet.
Yeah I hope Firefox could support desktop PWAs. I am moving towards Firefox from Edge due to the Manifest v3, but I cannot leave Edge due to its better PWA support, which my daily driver code-server relies on.
I think this is a sign that Microsoft sees the writing on the wall. There will be a day when Windows is left behind, and they want to make sure that they can continue to deliver the Microsoft experience, even on other platforms.
I don’t think Windows is ever going to be left behind, you still need a kernel to make use of all your hardware and an OS to give users something to do. I view this move as Microsoft recognizing that the future of most development is cross-platform web technologies and they need to give Windows users reasons not to migrate to macOS and ChromeOS (though it’s ok if they do as long as they’re paying for O365 and Azure).
> I don’t think Windows is ever going to be left behind
I do, but not for reasons most people think about.
The Windows 11 UI/UX is trying to emulate MacOS. Clearly, Microsoft is giving the finger to people that use Windows because it's not MacOS.
I can't wait for Windows 12 to happen and all the UX things I hate about MacOS get implemented in Windows. Might as well start training my muscle memory to hit the Windows key instead of CTRL now, so that when Microsoft decides that CTRL-X/C/V should be WIN-X/C/V, I'll be ready.
Few years back everyone was complaining Apple was copying Microsoft by going all in on flat UIs.
While at MS I did run into the ever present problem of many designers only using MacOS so their designs would basically say "do what MacOS does!"[1] which entailed a lot of work by developers to change the default Windows UI widget behaviors to look like MacOS. Thankfully when I got one of those requests across my desk I was able to point and shout at MS's design language rules and say no. :/
[1] I don't think it was on purpose, I just think many designers have never used anything else and they didn't even realize other UIs exist outside of MacOS and iPhones. These problems started popping up when MS loosened up on their rules about only using MS products for development, it was a needed change but ugh, UX designers and their MacBooks...
Not having buttons be obviously clickable/touchable is a bug, not a feature, as is having UI elements blend in with each other.
I personally use WindowBlinds to make my Windows 10 UI look like Windows 2000. I love having a taskbar that has 3D buttons. I like not having multiple windows from a single program getting grouped together.
Windows 2000 (or Windows XP with the Classic theme enabled) was the best UI Windows ever had. It's been downhill ever since.
I agree, but I’ve always wondered if flat UIs had a performance advantage. Like, if your GPU just rendered a bunch of rectangles of a single color instead of having to mask rounded corners or draw borders around things, could the UI run with less resources? Maybe it’s conspiratorial but it helps me sleep at night as a remember not finding buttons during the day…
Considering we had 3D controls in the Windows 3.1 era when some people were still running on 25 Mhz 80386 CPUs and 4 MB of RAM, I'm not too worried about the performance impact.
> so that when Microsoft decides that CTRL-X/C/V should be WIN-X/C/V, I'll be ready
Already starting to go this route. While you can still ctrl-x/ctrl-v, most of their newer features implement the windows key, including win-v for paste using clipboard history.
While printscreen works, you can use win-s to take a screenshot now too.
Well as long as printscreen key still works, adding another shortcut is fine. And win+s isn't really that bad compared to Mac's ctrl+shift+alt+spacebar+F4+right-click or whatever it is. Mac has the worst, most bizzare 'short'cuts anyone ever come up with.
I think you're right, but that also poses the possibility that Windows will get left behind, as a kernel. If the future of development happens on the web, the significance of Windows as a kernel is going to greatly diminish. We've already reverse-engineered a huge amount of Windows API calls, and you can run vast amounts of fairly complex Windows software without the NT kernel at all.
If our future does shift towards thin-clients and web-browsers, MacOS and Windows will make increasingly less sense. Both OSes have a pretty significant amount of cruft and unjustified overhead which already seems unnecessary to a generation of Google Docs and Soundcloud users.
>"If our future does shift towards thin-clients and web-browsers"
Please no. I like to control what I have. No way for me to be fed by thin client. Sure I do not mind web apps / services where it makes sense (banking for example). But the possibility to be suddenly cut off for whatever reason (maybe my app provider does not like my political views) - fuck that. Or when everything goes through some portal what will prohibit from them jacking up subscription fees sky high? I understand by many developers wanting to use webapp hummer for everything but I think they're digging their own grave
Those problems are also realistically an issue for native apps. The internet is your distribution platform regardless of if the web is your target.
I would hope that the industry could work together to provide a comfortable cross-platform app development experience, but none of the big players bought-in. So now the web is our only option, and they're the ones to blame.
For what it is worth I distribute my products from my company's website. However little reputation I have is all mine. It does not depend on some portal. The revenue is all mine as well. Besides those products are heavy apps that use features not accessible from non native apps.
My answer was in particular to: "If our future does shift towards thin-clients and web-browsers".
Thin client leaves processing to a server. It does not matter in this case if your "offline-first" UI is resident / cached on a client side. These are just glorified web bookmarks
I have to agree with this. Many Win32 things are disappearing, Azure is running on Linux and Microsoft is porting their major Win32 cash cow services to run on Linux as well.
Hopefully Apple keeps moving in the direction of better embracing PWAs. I am encouraged that iOS 16 includes support for web push notifications. This suggests to me Apple may be more willing to embrace PWA web standards.
I just really hope the onboarding experience is improved. Right now it's very convoluted and messaging is extremely difficult, in some places impossible.
For example, in SFSafariViewController there is no “add to home screen” button in the share menu, but in actual safari there is. Despite them both being web view experiences controlled entirely by Apple.
(And you can’t detect SFSafariViewController vs Safari as a web app, so good luck onboarding users for your PWA.)
> We’re excited to announce the availability of a new PWA feature that closes this gap and helps blur the line between apps and websites even more.
I don't see how they can use "blurred line" as a positive trait here. There are important differences between native apps and web apps, why hide this information from a regular user, especially when this information can be conveyed by 30 pixels.
We're talking about web apps that are specifically intended to be installed locally and look like native apps. What are those "important differences" in this context?
(and note that you can still use PWA in the browser if you want to, and thus deny it this ability)
What difference does the runtime make to the (average) end user? I love that I can create shortcuts of some web apps that have their own window, menu bar etc. (this is already possible in Chrome) and I don't really care they are "web" apps.
That has nothing to do with the runtime, rather with the implementation. Barrier to entry of web development is low so average quality is also low. On the opposite side of the spectrum you have products like Figma, Notion, Google apps etc.
because actual regular answers don't understand what any of this means, and this just means that the devs have more control over what experience they give them
They do explicitly discuss how the feature might work on other platforms (aka Mac OS and Linux), and have published a spec, which is also an interesting read: https://wicg.github.io/window-controls-overlay/
Sure. As well as certain other platforms like Kotlin multiplatform
The only issue is that these still have to compile to JavaScript, which in practice leads to slower performance and potential for improper semantics on the JS side. It would be better to have them executed in WASM and then have better WASM-browser integration
Flutter looked cool, until I realised it was a Google product. After being burned by Angular, Material, and all the things killedbygoogle, I'm not sure I can stomach even trying it out. Is that stupid?
Honestly, i have no idea. I've got amazing results with flutter so far; and therefore I'm obviously biased. Packaging it from source is pretty hard; but a bit of the industry has already adopted it. Even tho of course it could always have more features; i for one don't think it would be that big of an issue if google called quits on it today
This is a bit peripheral to the link but I had a thought. As PWA's get further integrated, I feel like this leads to eventually shifting people off of the Web Browser. In this case over into the Microsoft Browser... i mean the Microsoft Store. I guess, what is the difference to Microsoft between the windows engine, the web engine, or the java engine as long as it is able to serve user applications and they are still able to leverage out a cut from it? With the advent of internet payment processing and non-transferable purchase information the store is as good as the the OS was in terms of lock-in. The store over time becomes the target platform for dev's instead of the OS.
>We talk a lot about Progressive Web Apps (PWA) in the context of mobile devices, but they have an enormous potential on desktop operating systems that’s only beginning to materialize.
Do we? I think we talk about PWA's on mobile and desktop equally, if not more so in the Desktop (e.g. with Electron and regular browser-viewed PWAs).
Does this apply to Edge Mobile on iOS? To my knowledge, there's no way to hide the browser chrome on that app, which is ironic considering they open the article talking about PWAs on mobile devices.
Last time they weighed in on the topic, this was their response:
> ability to create their own title bar experiences
It was a sad day, IMHO, in UX-world when this became possible in desktop apps. The window system should own the chrome and the apps should not be able to touch it.
Now a single app bug can make it so you can't drag a window. Oops, we accept clicks everywhere and never fall back to whatever the web equivalent of DefWndProc is, I guess it's all app space and no actual title bar in that blue.
Win32 apps have always been able to break dragging, since ultimately the app process "owns" the window frame and can hang and block all interactions with it. (The system tries to catch simple cases of hanging where the app obviously isn't processing messages, but that doesn't cover all situations)
Actually, UWP sort of solved/solves this, by having a different process own the window frame.
Alternative title: now your web apps, just like your native apps, can have unpredictable drag/resize/snap/double click to maximize behavior!
Ugh. I wish apps would leave reusable consistent system UI elements alone. Has Adobe gotten around to making their title bars DPI-aware yet?
Every app that tries this gets at least something wrong. Let's take a look on a random sampling of native-ish Windows apps:
Discord (Electron): Supports right click for the system menu, but doesn't change the icon to show whether a window is maximized or restored. Doesn't change color based on active or inactive state. In fact, doesn't change anything at all, not even the subtle 1px window border Windows 10+ uses. Shame on them. For a long time, I believe they didn't support dragging a maximized window back to restored, but it works now.
Facebook Messenger: Not awful. Proper height, double clicks to maximize/restore work, right click for system menu works. Title bar doesn't change when inactive, but the left menu uses the glass effect to make it sufficiently obvious. Also no double-click to close, but this is one of the better attempts I've seen.
Chrome [bias: I work on Chrome]: Gets the important bits right. Chrome does it far better than most apps, since they use the Windows APIs to draw over the native title bar, which means they get my system colors and some other things included.
Microsoft Office (let's pick on Word): Ugh. Ugggggggh. Bright white as the burning sun and their only affordance towards showing if the window is active is changing the text to a light gray that has no contrast when inactive. What's a button? Where can you click to drag? Nobody knowwwwwws. Why is there a search box in the middle with a big empty space to the left? Why is the title off-center to the left of that search box? Has anyone in the last 12 years ever actually noticed the customizable set of buttons in the upper left and used them? (Answer: no). Office gets the most hate in my mind for initially popularizing it and in particular the "if Microsoft does it it's OK if we all do it" effect. Starting in Office 2010 or so the Office Apps have had some of the worst title bars I've ever seen, but everyone has copied them.
Firefox: Repeated the sins of legacy Microsoft Edge and leaves no space above the tab to drag, but to its credit does leave a small square in the left (and on the right if you fill it with tabs) so in theory you should never get stuck with a partially-offscreen window you can't drag without closing tabs. Overloads right click and doesn't include the system menu.
Steam: Almost no difference between active and inactive. Multiple tiers of menus at the top, all of which let you drag for some reason. DPI Issues.
....anyway, I could go on for years, but stop implementing custom title bars.
you need to "install" the PWA first.
So how's this different from regular desktop applications in regards to phishing specifically?
Do you mean an app presenting pre-"install" as something and then post-"install" as something else?
I'm having a hard time seeing a lot of difference. Most windows you want to "spoof" will look different in regards to the title bar either way.
In a regular browser window you'll have the browser title bar. In the PWA case you'll have the extra hamburger menu.
This announcement seems far more excitable than it needs to be. I think the way Macs solve it is better: left hand side of top bar is for app; right hand side is for OS.
Why are the window decoration buttons considered critical on Windows? People using Windows without a keyboard maybe? I always disabled those (or the whole bar) on any system I've used since I can remember.
#/media/File:HyperTIESAuthoring.jpg){kind=link}
I think we are having the opposite problem: native apps are really starting to look and feel like web apps, and in many cases, they are.
The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all. It was made for documents, not apps. If you want better than that, you have to rewrite it all by yourself, or more likely, import a framework that does it for you. Traditional Windows apps all use system provided common controls, because they are good, and therefore they have a consistent look and feel, even through OS updates. It is even user customizable. Now it is not uncommon to see 10 different styles in a single screen, Windows since 8 is not even consistent with itself, and it is becoming worse every version. And it is not just aesthetics, there are serious usability concerns here, and system-wide customization is gone.