Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

Post reply on HN
Print view View original

81–90 of 313 posts

Re: Closing a 30 pixel gap between native and web

#81

Post by [deleted] »

Sohcahtoa82 wrote: post #76
guhidalg wrote: post #18

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…

[deleted]

Re: Closing a 30 pixel gap between native and web

#82

Post by Analemma_ »

wolpoli wrote: 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…

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.

Re: Closing a 30 pixel gap between native and web

#83

Post by com2kid »

smegsicle wrote: post #66
wolpoli wrote: 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…

> The title bar area is meant for users to move the Window around i thought that's what alt-drag was for? maybe microsoft didn't get that memo either...

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.

Re: Closing a 30 pixel gap between native and web

#84

Post by david2ndaccount »

wolpoli wrote: 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 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.

Re: Closing a 30 pixel gap between native and web

#85

Post by airstrike »

david2ndaccount wrote: post #84
wolpoli wrote: 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 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.

As a fallback, you could always use Alt+Space to open the menu, Ctrl+W to close a window and good ole Alt+F4 to close the app

Re: Closing a 30 pixel gap between native and web

#86

Post by GuB-42 »

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

Re: Closing a 30 pixel gap between native and web

#87

Post by FpUser »

amadeuspagel wrote: post #56
FpUser wrote: post #45

Earlier quoted context omitted.

>"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 pr…

I don't see how an offline-first browser app is worse then a native app in terms of control.

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

Re: Closing a 30 pixel gap between native and web

#88

Post by com2kid »

criddell wrote: post #74
whywhywhywhy wrote: post #7

Earlier quoted context omitted.

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” ap…

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.

Re: Closing a 30 pixel gap between native and web

#89

Post by madeofpalk »

loudmax wrote: post #21
MaXtreeM wrote: 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…

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.

This feature itself has nothing to do with Electron. Electron has long had similar capabilities.

Re: Closing a 30 pixel gap between native and web

#90

Post by n8cpdx »

GuB-42 wrote: post #86

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

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

Post reply on HN