Hacker News Reader

Comment by ckardaris | Hacker News Reader

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

View on HN

> The developer needs to know what to do.

No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed)

> What if the developer creates an unorthodox menu

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

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

These aren't arbitrary actions, but standard menu actions (open menu, close it, activate an item). Also not sure how forcing clicks entered the scene. These are possible via keyboards in many frameworks already today.

> in spite of what the developer has predicted

The dev has "predicted" the menu by creating it in the first place? The framework just made sure that this menu is addressable by the user

> tested in their interface.

That's not a big loss, it's not like we've come to expect any serious testing of UIs anyway

> The developer has broken the standards

Yes, so? I don't understand the point relevant to this discussion. Should standards not exist if they can be broken? Should frameworks not try to make following standards easier? Should frameworks not allow user customizations if devs can find a way to break them?

Reply on news.ycombinator.com