embrace and crush much ?
Closing a 30 pixel gap between native and web
201–210 of 313 posts
Re: Closing a 30 pixel gap between native and web
#202Earlier quoted context omitted.
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.
I love this feature and it's since become indispensable to me. I find it pretty funny that my #1 favorite desktop UI feature is from Linux. One of the first things I'll put on a fresh install of Windows or MacOS is a utility that re-creates this behavior. 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/e…
This behavior is natively supported on macOS, although it is turned off by default. Click and drag anywhere on a window while holding CTRL+CMD
> defaults write -g NSWindowShouldDragOnGesture -bool true
> reboot
Re: Closing a 30 pixel gap between native and web
#203Earlier 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…
Absolutely! 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. Nowad…
> 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.
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.
Re: Closing a 30 pixel gap between native and web
#204Earlier quoted context omitted.
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.
In Firefox holding down alt lets you select text in links without navigating to the link target. How do you do that without moving the window?
For this very reason (alt-click in applications), I have the window move modifier set to Meta instead of Alt.
Re: Closing a 30 pixel gap between native and web
#205> 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…
> The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all 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.
Before flex and grid CSS had most complex, least friendly and (probably) least powerful layout definition system compared to everything I knew. Creating unecessary elements just to trigger primitive CSS mechanisms was commonplace as was having >3 methods to do some primitive layout task (like centering) depending on where that task was needed. Tables were popular so long because you could do 80% of what CSS could do while knowing 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).
Re: Closing a 30 pixel gap between native and web
#206Earlier 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…
VSCode is adequate, not great. The bar for responsive and minimal application is so bad these days thanks to web apps.
You can make fast web apps and you can make slow native apps. Check out VSCode's older brother and be amazed by how unresponsive and glitchy is.
Re: Closing a 30 pixel gap between native and web
#207Earlier quoted context omitted.
I also spent quite some time building desktop and mobile apps (5, maybe 6 years) and also more than 10 years of building web apps and don’t really share this sentiment. 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)
When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.
> When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.
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.
Re: Closing a 30 pixel gap between native and web
#208> 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…
> The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all 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.
You can use CSS with JavaFX.
Re: Closing a 30 pixel gap between native and web
#209I 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…
Random sorta related complain: at work when I'm using two different-sized screens, sometime when doing a click and drag to move a fullscreen window from one screen to the other, it's not the top one that's going to get dragged, but instead one 'below' it. Really annoying
I've only ever gotten this on my Macbook
Re: Closing a 30 pixel gap between native and web
#210With 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…
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…
> Dread to think how an argument for supporting 3+ web engines for a “native” app would go.
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.