when you all work on a Future of Cod ing flavored tool, do you think about ways to bake in certain sorts of interactions.
As example:
React lets ya build accessible, localized experiences, but it also lets ya make something that is wholly inaccessible, too. It is sort of agnostic on that front. Could a tool “force” an accessible experience, or be more strongly biased towards something like that?
This line of thinking isn’t restricted to accessibility, it just seemed like an easy fruit to reach for when writing an example. Is this the kinda thing other folks think about when designing stuff? Do you have examples of it?
using the accesibility "vocabulary" to also specify the semantics of the ui elements seems to be a trick used here: react-spectrum.adobe.com/react-aria/index.html
A library of React Hooks that provides accessible UI primitives for your design system.
I do that all of the time in FOAM (foamdev.com). I like to try and encourage the developers to do "the right thing" by making that easier (or even free). We have a reusable CRUD controller which provides things like search, sorting, import, export, scrolling, paging, authentication, i18n, etc. Developers can use the the individual components, like table view, detail view, query parser, DAO, etc., to make their own controller, but by just doing nothing they get a more standard interaction. Same for generated APIs. Often when you make some standard interaction very easy though, you'll find that users complain that other things are hard, even if they aren't any harder than without your tool, just relative to the things you make easier.
getting the user to "fall into the pit of success" is something a colleague of mine says a lot
please tell your colleague an internet stranger in the North East US loves it. I have a big beard and am middling at many things
credit: twitter.com/SomeHats
I'm not sure where the phrase originally comes from though!
she's currently using it in the context of: We want developers to write "validators" for the custom shapes they build (for tldraw). But validators can feel boring and pointless! How do we get them to write validators without thinking about it much? Current answer: "No no, you're not writing a validator , you're... defining your shape"
I’ve seen the “falling into the pit of success” in the context of api design attributed to Rico Mariani: blog.codinghorror.com/falling-into-the-pit-of-success . It might be a pun on “pit of despair”, which is both a psych experiment and a meme from the 1987 movie “the princess bride”
📝 Falling Into The Pit of Success
Eric Lippert notes the perils of programming in C++:
I often think of C++ as my own personal Pit of Despair Programming Language. Unmanaged C++ makes it so easy to fall into traps. Think buffer overruns, memory leaks, double frees, mismatch between allocator and deallocator, using freed memory, umpteen dozen
To the OP question, I think of this as design goal for a tool to encourage “good behavior” by making those paths pleasant, rather than forbidding bad behavior. So doing the “right thing” becomes the pragmatic choice, and not just principled.
There are many examples of this in data visualization tools and libraries, like vega-lite. For example, you could use a single hue or multi hue color encoding depending on whether color represents a discrete category (like country), or a binned quantitative variable (like temp in range 10-20 degrees). Psych and design heuristics suggest that one of these is more effective, so if you don’t specify a palette, a reasonable selection is made for you. You can override it if someone has a strong visual preference, but it’ll be more work, so most don’t bother.
For the React a11y example - admittedly there’s more to an accessible user experience, than aria tags, but keyboard nav support, reasonable contrast, and basic screen reader usability is selling point for many frontend component libraries.
I think this is a special case of the balance between safety and expressivity across all programming tools. Much like you can't let a language both be able to generate arbitrary assembly and also be safe, if you try too hard to make your UI framework generate accessible UIs, it will rule out tons of possible UIs, some of which even might have been fine a11y-wise. I tend to lean more towards power, but we'll need a spectrum of different tools forever. Best case the more restrictive ones are built on the more powerful ones in a principled way so it's not too awful if you need to break out.
More specific to a11y, the architecture I'd like to see is that we support completely reskinning our apps, so basically our data models and operations, with UIs designed from the ground up for vision impairment, mobility issues, etc, with their own idioms not tied down to standard GUI stuff. Retrofitting accessibility on a fundamentally visual medium is always going to be kinda meh at best. But you need that common model before this becomes, frankly, commercially feasible.
I think traditional MVC helps with with this. If the View isn't the app, just the View, and the underlying data and operations are in the Model, then you can have multiple kinds of views, possibility at the same time. Just like the classic MVC example where data (from the Model) appears in both a grid and a pie chart (2 Views) at the same time. A model can have a standard GUI View but also a separate text-to-speech UI. We did this with the ChromeOS system calculator by having a separate CalcSpeechView which was invisible from the traditional GUI point of view, but worked with screen readers to provide speech output: github.com/foam-framework/foam/blob/2966cde661ccadbb8b1548fede78f6d67cc53ed5/js/foam/apps/calc/CalcSpeechView.js
Separate UI or UX layers to address accessibility requirements is something I hear proposed a lot in my line of work. I think it is a novel idea, but I caution against it as much more than a curiosity.
It sort of forces a collapsing of what it means to be “disabled” into a set of predetermined categories, which is probably the opposite direction we want to be moving in, for the most part, when creating accessible experiences.
Well, there are some predetermined categories, aren't there? Someone who is red/green colorblind, is a mild form, then someone with poor eyesight, then low-visibility, then blind. Someone who is completely blind is not going to be helped at all by solutions which increase font-sizes, specify tab ordering, change colours and improve contrast.
yes, but those categories ignore the fact that disability isn't necessarily permanent, and that it doesn't always only happen by category -- some folks are blind and have mobility issues, too, for instance.
