Comment by jakelazaroff | Hacker News Reader

Comment by jakelazaroff | Hacker News Reader

Parent Full thread

A word of caution that Dear ImGui is specifically made for building internal tools quickly rather than production-grade UIs. Relevant quote from the docs:

> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal and lacks certain features commonly found in more high-level libraries.

Here's a quote from my comment [1] on an earlier discussion about Dear ImGui vs. "bloated" browser APIs:

> This is what I hear when I enable VoiceOver on macOS and open Discord (either the web app or the desktop app):

> 1. “Discord, friends - Discord window, direct messages, selected cell”

> 2. “You are currently on a cell inside of a table. To navigate the cells within a table, press…”

> 3. (when navigating with the keyboard) “1 mention, $SERVER_NAME, cell” “$SERVER_NAME, cell” etc

> And here’s when I do the same with a random Dear ImGui app I have installed:

> 1. “$APP_NAME, $APP_NAME window, $APP_NAME window”

> 2. “You are currently in a window”

> 3. (when navigating with the keyboard) [silence; no additional instructions]

[1] https://news.ycombinator.com/item?id=37302809

Supporting screen readers - e.g. accessibility, apart from the obvious benefit to the users, gives you almost for free testing/automation abilities too

Good Testing/Automation is never free lunch AFAIK but Dear ImGui has a testing/automation system: https://github.com/ocornut/imgui_test_engine

Yes, I'm super excited about this ^^^, but I was speaking in more general manner - e.g. accessing any kind of UI for basic functionality without need to know the internals, or use their own testing system (like QTest, or what Omar posted above with DearImGui, or something that exposes a white/gray box).

Inevitable, you have to reach out to the specifics of the UI end, but for most of the tests all you may need is - Run App, Accept Some License / Button, Press something else, then something else - and it elevates some confidence that at least it can run and go that far (sometimes changes can break even this).

So such tests can be coded by completely autonomous team, not having to deal with how you've build the software to begin with, or coordinate changes you've made later (apart from how the UI works).

Yet people do indeed make professional software with it, such as RemedyBG.

This comment-and-response pair has a really weird "shape".

You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.

Consider the following hypothetical:

Person A: Here's little advice: don't take up smoking. Smoking is bad for you.

Person B: Yet people smoke—my cousin, for example.

The point of the other comment wasn't that it isn't happening or that it's physically impossible to even try. Indeed, the fact that it's being done—or that people are attracted, at least, to trying to do it—was rather the entire premise of their "word of caution".

I see a different "shape". To me it looks like the same accessibility song and dance that happens every time a GUI library is the topic.

Is accessibility not a worthwhile concern?

I wouldn't go that far. But "this lacks accessibility" isn't sufficient reason to rule something out, imo. It's better for a piece of software to exist, without accessibility accommodations, than it is for it to not exist at all.

No, there's a tradeoff. If non-accessible software outcompetes and crowds out accessible software, that degrades the ability of people who need accessible software to use their computers. It is entirely reasonable for people who think that people with disabilities should have equal access to technology to advocate against the development of software without accessibility features.

It's a bit sad that something like an iMessage client for Android gets so many people here passionate about the ethics of access to platforms, but you get downvoted pointing out that certain tools/strategies for building software can leave whole classes of people out of computing due to factors entirely out of their control.

And you get downvoted for pointing out that here in Europe you're required by law to make software accessible. (At least in theory, don't know if it's enforced at all.)

Well, here in Europe you can get sued if you provide a non-accessible software. (Games are excluded and a photo editor can of course assume that the user can see etc.)

What answer are you expecting? This question is borderline flame bait.

It seemed like you were criticizing the "accessibility song and dance that happens every time a GUI library is the topic", as if you think accessibility concerns are over-blown. If that wasn't your intention, I suggest you clarify what you actually mean.

It seems this might not be the case for American English, but "song and dance" is only ever dismissive in British English. The implication is that the complaints are a needless distraction, due to the relative insignificance of the topic.

Yes, that’s the case for American English too.

This is for the creators to decide. Nobody else has a say, really.

Accepting this, for the sake of argument: sounds like warnings such as jakelazaroff's are a good thing then, to make sure creators are informed enough to decide.

Except the law in Europe.

Probably not for internal custom tools.

I agree, which ... is why jakelazaroff is warning that ImGui is meant for internal custom tools, not tools where things like accessibility is a concern.

Accessibility is only not a concern for internal custom tools if you're certain you're not going to hire anybody with a disability that requires those accessibility features. (You shouldn't be certain of this, because it means you're probably breaking the law.)

Accessibility is one (important) consideration but it's true that tools with a small, known subset of users can afford to ignore some constraints. For example, if you're a small American company, your internal tools might not need to support right-to-left languages.

This is kind of a kinda ridiculous argument. You're not gonna hire a blind level designer or blind character artist.

I don't see any reason you couldn't hire a blind level designer, but sure, there may be some subset of "internal tools" that you can make that assumption for. But the topic wasn't "internal tools for visual artists", and a lot of workplaces have internal tools that are inappropriately and unjustifiably inaccessible.

If the topic is a tool that's missing an important feature, then of course people will discuss why that tradeoff has been made.

Ship or don't. If the calculus boils down to this, then making suboptimal choices isn't necessary wrong.

Sure, if you put in a lot of effort you could probably make a professional app with it. You'd need to recreate a bunch of features that come for free in more "bloated" UI libraries. But you could do it! More likely, though, is that you won't and your "professional" app will just end up being bad for lack of those features.

Is RemedyBG actually accessible to blind users though?

No. Just bought it so I could check. Edit: I'd be happy to spend some time helping the developer with this if they're interested.

Tools that are popular with developers tend to evolve into tools that end up in use by everyone.

Your caution isn't wrong, but ultimately it may be futile.

Ultimately, I only really care about the outcomes. If people want to use Dear ImGui for their production apps and put in the work to make it, well, production-ready, I'm totally fine with that.

Why should internal tools not have these things? That kind of argument smells of, internal tools can be slow. No.

Seems we should lift up Dear ImGui -- contribute, donate, feedback (document, gather requirements, etc), etc -- as opposed to suggest we not use it.

Dear ImGui is lacking good and focused code contributors, I'm stretching myself quite thin already and unfortunately pragmatically it currently wouldn't be wise for me to attempt working on accessibility features :( Right now the state of things is that a majority of even the simplest PR are poor quality, so I'm not too hopeful that such a complex feature would magically start getting good contributions. I am personally just accepting that things are going to take years to move forward. I'd rather have them more slow and stay sane. Dear ImGui is intentionally gated and made fugly for those reasons as well.

But any effort to document, specs, clarify etc would be helpful and not just to Dear ImGui.

Accessibility is a whole world that is hard to grasp when you are not a end-user, API are large, confusing, poorly documented, and I presume that there are a large variety of tools and use cases and it's even hard to gauge what are the low-hanging fruits that would be the best to implement/bind.

Given how obfuscated Web stacks are nowadays (since they do try to prevent unauthorized scrapping and automation), I'm honestly also a little bit surprised that nowadays screen readers aren't relying on OCR more?

I appreciate the work you do and I think what you're saying is completely fair and understandable.

I don't think they shouldn’t on principle, but they might not need to have them. For example, if there's a limited number of people who are going to work with the tools, and you know that none of them need such features, it could be entirely reasonable not to worry about them.

That's making a bet that you'll have absolutely no need to hire someone for that team nor that any of the existing members of the team will develop the need for accessibility features.

Reply on news.ycombinator.com