ckardaris

For example, opting to not enable high-contrast mode is a question of aesthetics. Arguably reading text would become easier for the user, but they prefer to sacrifice a little of the readability in favor of looks.

Sometimes users may prefer to reduce the degree of accessibility of an application in favor of aesthetics.

> ..., so a user can configure F10 to open it if you, app developer, forgot to mark it as main

So, basically what you want you want, as a user, is to bind arbitrary application actions to shortcuts and force click events in spite of what the developer has predicted or tested in their interface. I do not think this is a trivial problem to solve. The application would need to have a way to expose these actions consistently.

> What is he draws a circle instead of using a letter O? What of it?

Well, then you cannot expect the screen reader to work, for example, and you also cannot expect to do anything with this weird "shape". The developer has broken the standards and the user is helpless in this scenario.

> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation.

The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut.

  <object class="GtkMenuButton">
    <property name="primary">true</property>

This is easy to omit and then you will never know about the automation.

Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?

But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc.

A good common framework helps here. Then, it's up to each user to set their settings properly.

This is where using a common framework pays dividends. For example, on the desktop I can disable animations for all GTK applications.

Maybe not complicated, but unorthodox. A developer who is not familiar with the correct design patterns may, for example, create a dialog using a FrameworkWindow instead of a FrameworkDialog. In that case the framework can not provide any automation, because the developer is not following the guidelines.

I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.

That's a good point. Accessibility is the next step that should also not be ignored. Navigating to the elements is one thing, but for the voice assistant to work properly it can be a little trickier.

> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?

If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "<N>G", but such a shortcut would seem absurd in another application.

Any text-centric action will have a great advantage when done inside a terminal. I would think the equivalent in GUIs would be first-class OCR support on the compositor level. I am not informed about any progress made in that region to be honest, so I cannot tell how close we are (or not) to this.

You are right. Maybe the wording is a little too absolute. If you gotta ship and later try to slowly address any shortcomings in different areas, this is also a step in the right direction in my opinion. Just don't completely forget about those areas just because you have already shipped by that point.

In some cases they do.

For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.

In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.

In that case, it is up to the developer as well to read and try to follow the published guidelines.

This can happen if the applications exposes single keys as shortcuts. If they are "hidden" behind the different modifiers (i.e. Ctrl, Cmd, Alt), then mis-clicks should not be possible or should be more tolerated.

The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.

You can always take it to the next level by using an extension like vimium[1].

[1]: https://github.com/philc/vimium/

I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).

This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.

You don't really need to remember everything though. Mouse navigation does not need to go away. The keyboard shortcuts should be available if you opt to use them, after which point you will be able to memorize them in short time.

The intuitive part of my argument also falls under this. By following known conventions as close as possible, we can eliminate the need to remember the most common actions.

Additionally, it is important to present your shortcuts in a shortcut window/dialog in a logical way for when the user needs to remember something.

In any case, an excesive number of keyboard shortcuts can have a negative effect on usability, so this is also important to keep in mind.

Ideally you should have both. Every action should be doable by mouse only and by keyboard only. That way you can cater to all kinds of users.

I am not on discord, so I don't have skin in the game. But it depends on the community I guess. If everyone stayed on discord then there would be no change. But any kind of change would probably have some kind of effect, even if all people migrated to a new platform.

I can try to think of a simple scenario. For whatever reason, a user may not be as active in the new platform as they were on discord. This could alter the community dynamics. On a bigger scale this could have visible effects in the actual community.

To be clear, I am not advocating in favor of staying on discord. I just find the concept of community building interesting.

This is a completely different topic though. And not relevant to point being discussed. Analyzing the effectiveness of community building by different groups is a separate issue.

I don't think the article proposes that a community should not accept new members. On the contrary, it critiques the breaking of communities.

Migrants or refugees have to find a new community because their old one was broken for whatever reason, be it war, financial troubles or something else. So in that case, that first breakage of community should have been prevented and the community preserved.

The author of the article claims that a mere migration to a new platform does not solve the problem. It just fragments the community. I agree with that. For one or another reason not all people will migrate.

>1. Accept comments via email

In case anyone is curious, I (very) recently implemented a similar comment system based on email. I posted a write-up about it[1].

[1]: https://ckardaris.github.io/blog/2026/01/22/my-comments-run-...

I am very satisfied with KISS launcher[1]. I have been using it for a while now. It's simple and gets out of the way.

[1] https://kisslauncher.com/