wittjeff

> Most users would prefer to have adequately-sized text and controls regardless of whether they're using the smaller outside screen or the larger inside screen.

Yes they would, and neither of the existing scaling methods works robustly on regular phone sizes, so this is a particularly exciting opportunity.

Also there is an under-recognized problem with touch target sizes. For most touch targets, the common minimums are OK but not great for many people with large fingers and/or minor tremor. With a 1.31 zoom (I did more precise math) you get ~1.7x total increase in pixels in touch targets. Some may read their messages, etc on the outside screen, then flip to expanded for the tricky interactivity.

How about open and rotate for 1.4x zoom?

Yes, that's what I mean. I didn't see the desired mode in any of the marketing materials. This mode would be an effective 1.4x full-screen scaling. To be more specific: if the OS desktop has XxY virtual pixels in closed mode, if the user opens it and rotates 90 degrees, the desktop still has XxY virtual pixels. No new usable real estate. Everything previously seen just gets a bit bigger. I don't expect it to be the desired default for most people, but I have middle-aged eyes.

I want to be able to open the phone and get the original closed-state image, but stretched to fit the new total hardware viewport size.

I'm curious if you used a particular tool for this comparison or a LLM. I ask because (layered irony) I'm making a general tool for multi-dimensional item comparisons, using Claude to build the tool (but not the comparisons, not that I mind).

The existence of non-profits, and the possibility that they might be net-beneficial to society, is counter to the dominant religion of the day. Profit motive = good, other motive = bad. Welcome to UChicago.

I'm a big proponent of use of design systems for efficient remediation and maintenance, so I'm also aware of how a small oops bug can have wide repercussions.

Let me know if you'd like to chat about use of your system to help enforce proper use of semantics and ARIA in web UI. It looks good.

From your title my immediate thought was "cool, maybe this will move us a bit closer to making components (or the testing thereof) cover accessibility thoroughly by default".

See, the idea with the semantic web, and the ARIA markup equivalents, is that things should have names, roles, values, and states. Devs frequently mess up role/keyboard interaction agreement (example: role=menu means a list will drop on Enter keypress, and arrow keys will change the active element), and with ensuring that state info (aria-expanded, aria-invalid, etc.) is updated when it should be.

Then I checked the Antithesis website. They don't even have focus state styling on any of the interactive elements. sigh

Without negating your point I want to add that at some threshold of tediousness, usability issues become accessibility issues. The fact that this threshold varies from individual to individual makes heuristic guidelines difficult.

> as opposed to using AI as a total replacement for your thoughts or your writing and therefore removing the personal touch?

I'm really having trouble grasping the true breadth of this problem in the wild. How much of it am I not seeing because the mods filter it out first? How much is faulty signal detection from readers?

> Listen: every idea you've ever had, every single one, some cocaine-addled sales critter has had too. And they're better than you at SEO.

On most days I am resistant to stereotypes about "the welfare state" eroding incentives for entrepreneurism and innovation. But if you're going to wave it in my face like that, I might have to reconsider.