Closing a 30 pixel gap between native and web
blogs.windows.com
blogs.windows.com
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.
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'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.
Cheapness leads to abundance leads to innovation.
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
[1] Code refactoring alone is dozens of pages in IDEA docs https://www.jetbrains.com/help/idea/refactoring-source-code....
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 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)
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.
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.
[1] https://www.researchgate.net/publication/220183526_Model_and...
https://superguigui.github.io/simple-color-picker/
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.
Compare to color dialog in WinForms: https://github.com/Kinnara/ModernWpf/issues/72
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).
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!
To "gratifies one's intellectual curiosity", check https://youtu.be/hn5QjtpjW_U
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.
Which is kind of tragic, given how Office was the testing ground for many Windows UI components.
So unless you're on the Office team and want to tell us anything, please do lmao.
I stop here in order to not throw profanity at MS engineers.
Any more details on what web technologies are being used in Visual Studio and what parts of the UI are done with web?
Node.js processes are invisible backend stuff.
Mostly related to Web stuff, Blazor or VSCode plugins that they are "porting" into VS.
I think you're not giving credit to the best part about the web: CSS.
I've been programming GUIs with Java AWT, Swing, and Qt for years. Nothing comes close to CSS when it comes to defining layouts.
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.
(Edit: fixed a typo)
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.
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).
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.
Looking at this list: https://learn.microsoft.com/en-us/windows/win32/controls/ind...
Animation -> video tag
Button -> button tag
Combobox -> select tag
Date picker -> input type=date
Time picker -> input type=time
Edit -> input type=text or textarea
Scroll bar -> Not needed, automatic
Hot Key -> WAT?
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
I'd see the one control missing most is menus
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.
My favourite: A window with 1 (only one) input field which is not focused by default. Why ? Why do i have to click and type instead of only typing ?
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.
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 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.
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.
As long as you, you know, do no complex layouts or interactivity.
It's still a system for displaying static text documents, and no amount of lipstick can change that without re-doing the entire thing.
If you think it's not the case, animate adding a height:auto element to a list without the browser needing to re-layout and redraw the entire page
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 use AltDrag on Windows (requires a quick tweak for HiDPI): https://stefansundin.github.io/altdrag/
And Easy Move + Resize on MacOS: https://github.com/dmarcotte/easy-move-resize
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. :)
> defaults write -g NSWindowShouldDragOnGesture -bool true
> reboot
Put me in the camp that hates window snap/tiling.
I have a certain workflow that needs this window there, and this one here ... don't snap to a location or go full screen.
This is such a great little nugget. Thanks.
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.
https://en.wikipedia.org/wiki/Tab_(interface)
Example:
https://en.wikipedia.org/wiki/Tab_(interface)#/media/File:Hy...
>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.
https://www.youtube.com/watch?v=tMcmQk-q0k4
>NeWS Tab Window Demo (1990)
Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0. Developed and demonstrated by Don Hopkins.
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:
#include C:\path\to\winmove.ahkThis 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).
i thought that's what alt-drag was for? maybe microsoft didn't get that memo either...
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.
To get it on Windows search for AltDrag.
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)
> alt-space -> m -> any arrow
Are those keybindings default on a particular OS/DE/WM/WC or are they just your personal config?
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.
https://docs.oracle.com/cd/E19683-01/806-4743/6jdq6q20i/inde...
Which windows still doesn't have, for some reason.
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?
I'm pretty sure there's an option to emulate the windows key somewhere too
Instead you should be complaining about the trend of apps spacing everything out with excessive amounts of padding.
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.)
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.
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.
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.
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.
But if you want to put words on my mouth, go ahead.
I also have 15 layers of tabs in one of my Pale Moon windows, but that's beside the point.
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.
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.
Winamp did exactly that, on Windows 95. The capability is there.
https://www.theregister.com/2017/01/19/browser_line_of_death...
I am the reason Signal desktop now has a preference to opt out of autoupdate.
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.
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.
Most of the immediate pain with native to native ports is shift between UI frameworks. This always requires a huge investment to do correctly.
Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.
Simply changing your compiler target is easy. This is not what people are complaining about obviously.
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.
Also, here's a big list of C++ GUI libraries if QT doesn't float your boat https://www.reddit.com/r/cpp/comments/babfl5/a_pretty_big_li...
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.
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.
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.
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…
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.
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.
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.
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.
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.
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.
I didn't even know these existed.
Which is a shame, because as bad as Xcode is, developing native apps on the Mac is almost pleasurable compared to Windows or Linux
Eventually even those of us that know Win32 quite well don't want to deal with it.
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.
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.
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.
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.
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.
[0] https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-...
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.
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.
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.
I'm running Windows 10 on a 2009 computer - one which was low-mid end back then. Only upgrade is an SSD.
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.
If you run the same version of windows on both PCs, yes.
Is this not ChromeOS? A little OS, a lot of browser and little else?
But this ship has sailed a long time ago.
[0]: https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help
Is there any normal-looking way to make a chm from a directory full of html files?
The only working bookmark I have now that standalone MSDN is basically defunct (RIP, legend) is:
https://learn.microsoft.com/en-us/previous-versions/windows/...
(might wanna archive before MS redirects it to welcome.microsoft.com or something)
Not sure if that helps but it's all I got!
> 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.
https://textslashplain.com/2017/01/14/the-line-of-death/
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.
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.).
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.
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.
A little tedious to setup, especially as the PWAs all get new profiles with their own extensions, themes, etc. But other than that, it works fine.
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.
Or maybe I'll just switch to Linux.
In either case, I'll leave Windows behind.
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.
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.
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.
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
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.
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
Microsoft is trying to land on the PWA beachhead in an attempt to make mobile devices irrelevant and app agnostic.
Furthermore, they want to provide the tooling to develop and deploy into this ecosystem. Github, Github CI, VSCode, Azure, ...
Check Active Desktop, HTA, WinJS,...
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.)
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.
(and note that you can still use PWA in the browser if you want to, and thus deny it this ability)
"Incredibly slow and draining the battery 3x as fast" vs "regular"
Beyond rhe security concerns, this seems like a proprietarization of the web for Win11, a la Internet Explorer.
I want an app which can be compiled into Desktop/mobile builds and also interpreted in browsers. An alternate HTML/CSS/JS with no JavaScript.
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
Can be compiled for desktop, mobile and used in a browser with WASM
Edit: related, from the same author: Regressive Web Apps (2016): https://adactio.com/journal/10708
Only place where I find it useful is web-browser, to render tabs.
P.S. I do not prefer ultra wide monitors, so most of a time I have vertical real estate.
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).
Last time they weighed in on the topic, this was their response:
https://answers.microsoft.com/en-us/microsoftedge/forum/all/...
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.
https://blogs.windows.com/wp-content/uploads/prod/sites/33/2...
Didn't that picture make it obvious?
Actually, UWP sort of solved/solves this, by having a different process own the window frame.
Remember round windows? They’re back, in Electron form.
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.
Sigh. Titlebar highjacked, no menubar, small scrollbars, gray on gray (this is a "modern UI" pandemic).
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.
My concern is only security. Sounds like we are granting web (potentially malicious javascript) access to window overlay.
The PWA future is looking bright!