I think this article is misleading, you can use any framework to make slow bloated software. A great thing about Electron and similar projects is that you get one codebase which is useable on many different platforms. An Electron application can easily be a website and PWA, then the user can choose what they prefer.
A good example fast / "performant" software which uses Electron is Obsidian.
Yes Electron isn't perfect, but I think it's a good choice for many situations. Same for Tauri, CapacitorJS, etc. Regardless of which is chosen, there should be an effort to make software performant and non-bloated.
It's broken in the exact same way in the last version of Vivaldi that works on Windows <10.
From a quick look at the second horizontal strip that starts "what is this?", and without wasting time doing too much digging, it appears to be ultimately caused by using a grid layout for a heading followed by a few paragraphs, all of which fill the available (constrained) width, which amounts to one of the absolute simplest layouts possible in CSS - block. Last time I saw something similar, albeit with flexbox not grid, it was from a junior developer who appeared to have only learned flexbox and nothing else.
As a quick semi-fix, just disabling grid-template-columns on .base-layout is enough to fix almost everything except the constrained width.
Sounds like that older Vivaldi version does not support CSS nesting. I looked into it. I'm assuming you are using Vivaldi 5.6 which uses Chromium 108, native CSS nesting became supported in Chromium 112.
It uses CSS Grid to create a centered, width-constrained content area while allowing individual elements to break out of it or span the full viewport width. This provides a flexible, consistent layout without the need for additional wrapper elements in the HTML.
CSS nesting has had full browser support for more than 3 years now, I recommend updating. I'll also add fallback for older browsers, but the Grid layout itself isn't the issue.
Yes, that's right. I thought I'd try it in that older browser that I still happen to have installed, as the user above didn't immediately let us know what that mobile browser was. It may or may not help by at least giving you a browser version you can use to test. As I mentioned somewhere else, it makes sense to use some sort of older browser as a proxy for older browsers in general, when testing.
Developers are always looking for new ways to do what we've always done, often using more technically complicated ways to recreate the simplest things. It's fun from the puzzle-solving point of view, but your choice of earliest browsers you want to support depends on your user base.
This is a very important and good change. Currently Discord communities are black holes of information.
Especially for communities that have valuable discussions and support going on in Discord, Obsidian or Astro come to my mind, this is super helpful.
I do wonder about their motivations behind this, making the web a more open and user friendly place is obviously good for the users, how does Discord profit from this? Forcing users into creating an account to view valuable information seemed like a profitable thing for Discord.
As most sites will have horrible CSS for printing, as it's not a big priority usually, I can recommend getting the page as a markdown file through something like the Obsidian Web Clipper and using that instead.
I've run into this a lot, and my solution has been a bit intricate. I built Heck Yes Markdown years ago, then perfected a html2text/readability Swift library a while back. All of it came together in Marked 3, which has a built-in clipper and extensions for Firefox, Safari, and Chrome, and can clip any web page to Markdown and then do whatever you want with it, including Print/PDF output with your own styles. Having dealt with this frustration for years, I think it's a good solution.
I think I read somewhere (and in any case it matches my experience) that the first user will catch 50% of the problems and that with 5 users you can catch close to 90%. So human testing is not just invaluable, it's pretty cheap for the benefits it brings.
At every UX job I've had we generally ran usability tests with 6 participants. This was before the online usability testing tools proliferated and we had a lab in our office (one way mirror with observation room and everything). Every UX researcher I worked with said based on the available research and personal experience it is as you said: more than 5-6 participants would hit diminishing returns pretty hard and wasn't really worth it.
You want to hire your target audience, which may be vastly different from yourself, and suddenly you discover that the language is throwing them off, the color scheme brings different meanings, and they just don't understand the flow which felt completely natural for you.
It's more like the first user catches all of the critical bugs and a handful of users catch all of the high impact bugs. Cause that's kinda the definition of the impact of critical and high impact bugs.
I was also going to post "this sounds like usability/user research".
But I guess we all re-discover things when we need to.
The biggest issue I've seen with tech docs is often expert users of a given tool or product are enlisted to write the docs, because of their expertise.
But then ironically they end up writing those docs for an audience that shares their level of expertise, rather than for the intended audience.
So you end up with lots of assumptions or leaps of logic in the docs that the intended audience can't follow.
I'd wager this is interesting, seems there are a lot of users here building things on the side (or main projects) that need clear UX if they're anything like me, they don't have that UX background to know the best practices. I know I just clicked your link anyway...
There are thousands of great games which are not hand holding. Many studios are putting out amazing work that does not deserve to be lumped together with modern trash.
A good example fast / "performant" software which uses Electron is Obsidian.
Yes Electron isn't perfect, but I think it's a good choice for many situations. Same for Tauri, CapacitorJS, etc. Regardless of which is chosen, there should be an effort to make software performant and non-bloated.
reply