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

91–100 of 313 posts

Re: Closing a 30 pixel gap between native and web

#91

Post by [deleted] »

banana_giraffe wrote: post #53
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 don't disagree. 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)

[deleted]

Re: Closing a 30 pixel gap between native and web

#92

Post by com2kid »

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…

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

Re: Closing a 30 pixel gap between native and web

#93

Post by FpUser »

smoldesu wrote: post #48
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…

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.

Re: Closing a 30 pixel gap between native and web

#94

Post by kroltan »

airstrike wrote: post #79
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…

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): https://dpaste.org/pV1aQ 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 th…

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.

Re: Closing a 30 pixel gap between native and web

#96

Post by jb_s »

nicoburns wrote: post #13
jwcacces wrote: post #11

Looks like the perfect place to fake some browser chrome and trick people... https://www.theregister.com/2017/01/19/browser_line_of_death...

I think you'll only get access to this API if the user has explicitly installed your app as a PWA, not just when visiting it as a webpage.

XSS will mean that attackers control browser UI, that's kind of bad

Re: Closing a 30 pixel gap between native and web

#97

Post by robocat »

kllrnohj wrote: post #55
amadeuspagel wrote: post #24

Earlier quoted context omitted.

The obvious solution to this is to remove the bottom layer so that the browser is not a layer on top of the OS, but is the OS.

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

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

Re: Closing a 30 pixel gap between native and web

#98

Post by uptown »

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:

https://answers.microsoft.com/en-us/microsoftedge/forum/all/...

Re: Closing a 30 pixel gap between native and web

#100

Post by p1necone »

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 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.
Post reply on HN