Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

111–120 of 313 posts

Re: Closing a 30 pixel gap between native and web

#112
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.

Re: Closing a 30 pixel gap between native and web

#113
post #90

Earlier quoted context omitted.

> 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 th…

> 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 wor…

The word “cheaper” here is doing a lot of work.

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.

Re: Closing a 30 pixel gap between native and web

#114

> 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.

They still do. https://blogs.windows.com/wp-content/uploads/prod/sites/33/2... Didn't that picture make it obvious?

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.

Re: Closing a 30 pixel gap between native and web

#115
post #44

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…

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.

Wow, TIL.

This is such a great little nugget. Thanks.

Re: Closing a 30 pixel gap between native and web

#116
post #12

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 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.

Re: Closing a 30 pixel gap between native and web

#117

Earlier quoted context omitted.

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 k…

> 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.

Re: Closing a 30 pixel gap between native and web

#118
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.

Re: Closing a 30 pixel gap between native and web

#119

Earlier quoted context omitted.

> 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 wor…

The word “cheaper” here is doing a lot of work. 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…

Innovation? More like W95 (or even ME) compared to NT, and don't even start to compare ME against BSD/Solaris/Linux or Mac OS X.

Re: Closing a 30 pixel gap between native and web

#120
post #68
post #6

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 w…

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.

What are you talking about?

I'm running Windows 10 on a 2009 computer - one which was low-mid end back then. Only upgrade is an SSD.

Post reply on HN