I was going to submit the same link. Like Benn Jordan, I was an AutoPilot enthusiast. Was going to buy a Model Y with FSD, until a drive from CA to AZ nearly drove me off the road.
ALS is a configuration. Blindness is a configuration. Conventional UIs are built for a different configuration. Accesible UI usually overloads the conventional. If you start from scatch, sometimes you find something new. If you're lucky, the new thing scales to other configurations.
For example, I wrote a NLP parser for a calendar app, at Tempo.AI. It was much more efficient than the visual interface. And thus, it was accessible. But, it didn't use the accessible idiom. Instead, it was universally more efficient, whether you are blind or not.
A good example is a wheelchair accessible doorway. One method is to have a button at wheelchair height. The other method is to have the door open with an electronic eye. The first is Accessible. The second is Universal. Doesn't matter if you are in a wheelchair or not. It's a throughput multiplier.
I've been working on the menuing side [1] based on crossing Fitt's Law with Huffman trees. But, don't know the constraints for ALS.
Hopefully, whomever takes this on doesn't take the standard Accessibility approach, which is adding an extra layer of complexity on an existing UI.
A good friend, Gordon Fuller, found out he was going blind. So, he co-founded one of the first VR startups in the 90's. Why? For wayfinding.
What we came up with is a concept of Universal design. Start over from first principles. Seeing Gordon use an Accessible UI is painful to watch, it takes three times as many steps to navigate and confirm. So, what is the factor? 0.3 X?
Imagine if we could refactor all apps with a LLM, and then couple it with an auto compete menu. Within that menu is personal history of all your past transversals.
What would be the result? A 10X? Would my sister in a wheelchair be able to use it? Would love to find out!
well, I used to have super hearing. Had a hard time being around CRT displays because the flyback transformers were really really loud. Now, with age, I get a phantom limb tone of 16KHz. [1]
Coincidentally, the peak notch in the OP was the 1st subharmonic of that.
This is very common though, isn't it? Every child can hear a tube TV running when muted. Dog whistles too and all. And that's not even at the top of kids hearing range.
Does not being able to be around CRT displays because of the noise make qualify one as having super hearing? Pretty sure a good percentage of the population have that problem
Was tested while attending an electronic music class. Professor displayed everyone's result, so we could compare. His chart was the worst, as a cautionary tale. Too many live performance in front of the PA.
My old boss invested in Kiteship. The Oracle Americas Cup team deployed one for a day -- but, not during competition. I suspect it messed with the competition's head for a brief moment. He did mention container ships. Feel free to reach out and I'll introduce.
I was able to get Bing to produce those, but only pretty simplistic ones. And as mentioned, the results were better in the fbp language than in JSON (most JSON wasn't even fully valid).
I wonder if it makes sense to produce some sort of neo-COBAL that produces a bridge between flow and declarative syntax that better aligns with expressing intent that maps from human input. That is harder to do with lower-level languages, but if we are optimizing for gluing together components it seems like it is very common for systems to build their own "DSLs" to solve a task. Is there a more generalizable DSL (which would no longer be domain-specific, I suppose) but still maintains the properties of such a system without generalizing to any kind of programming task?
Seems like a tradeoff between fixed assets versus variable assets. Writing code that doesn't change for years is a fixed asset. UX is a fixed asset. Somewhat like the construction cost of putting up a building. Maintaining the code and data is a variable asset. Somewhat like maintaining the building. Variable costs scale with the number of users.
With OSS, fixed assets are often overvalued. All of the R&D to get the UX and algorithms working well is easily copied. So, monetization relies on variable costs. Frequent updates. Data hosting. Ironically, buggy and obscure code helps monetization.
I almost became a developer of a successful database product. I attended one of their conferences. That's when I learned that the company made half of its money from consulting. It rammed home a joke I heard from an employee at Lotus Development: job security through obscurity. I left the conference dissuaded.
I recall a game developer had a deferred software release. You could download last year's game engine. But, to have access to the current engine (and thus influence its direction), you had to pay.
https://news.ycombinator.com/item?id=31706955#31708672