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

271–280 of 313 posts

Re: Closing a 30 pixel gap between native and web

#271

Post by marcosdumay »

Dalewyn wrote: post #158
marcosdumay wrote: post #78

Earlier quoted context omitted.

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…

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.

Re: Closing a 30 pixel gap between native and web

#272

Post by Dalewyn »

marcosdumay wrote: post #271
Dalewyn wrote: post #158

Earlier quoted context omitted.

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…

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.

Re: Closing a 30 pixel gap between native and web

#273

Post by Sohcahtoa82 »

guhidalg wrote: post #257
Sohcahtoa82 wrote: post #160

Earlier quoted context omitted.

I can't stand flat UIs. 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) w…

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.

Re: Closing a 30 pixel gap between native and web

#274

Post by bentcorner »

postalrat wrote: post #49
gildas wrote: post #23

Earlier quoted context omitted.

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.

Unlike the native app you probably won't have to worry about web page encrypted your files and asking a ransom.

For now

Re: Closing a 30 pixel gap between native and web

#275

Post by juki »

redbell wrote: post #195
n8cpdx wrote: 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…

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

The latest Windows 11 update just switched the task manager to the new UI style with support for dark theme.

Re: Closing a 30 pixel gap between native and web

#276

Post by ensignavenger »

JaggerJo wrote: post #268
tngranados wrote: post #262

Earlier quoted context omitted.

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

bold statement, as you claim that VS Code would fit the majority better than say $IDE from JetBrains. I don't know how you came to that conclusion but I'd guess that you mostly work on small projects? (where I'd say smallish is Stuff I'd miss in VS Code coming from JetBrains Rider: - Docking of panels to top, bottom, left, right - built-in database explorer (with table designer, script runner, ...) - built-in unit te…

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.

Re: Closing a 30 pixel gap between native and web

#277

Post by luvs2code »

ColonelPhantom wrote: post #177
luvs2code wrote: post #169

Earlier quoted context omitted.

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

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.

Re: Closing a 30 pixel gap between native and web

#278

Post by Semaphor »

jcelerier wrote: post #270
Kiro wrote: post #188

Earlier quoted context omitted.

It's great and the best desktop app I've ever used.

I'm sorry for you if it's the best that you have ever experienced. It is very subpar and slow.

It's the best electron app I've ever used. It's so much faster than anything else I've seen use electron.

Re: Closing a 30 pixel gap between native and web

#279

Post by somat »

Asmod4n wrote: post #199
bigyikes wrote: post #113

Earlier quoted context omitted.

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…

VS Code isn’t a web app. The first release was and since then most of it has been rewritten to be a native app.

Are you sure?

https://code.visualstudio.com/docs/editor/vscode-web

Re: Closing a 30 pixel gap between native and web

#280

Post by kylealden »

sangnoir wrote: post #185
zeta0134 wrote: post #162

I am reminded very strongly of the line of death: 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 fo…

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

Post reply on HN