The issue is that many designers and engineers loathe Usability and Accessibility people (like Jakob Nielsen and Don Norman).
For me, it all started with Don Norman's excellent book The Design of Everyday Things[0] (nee The Psychology of Everyday Things).
Reading that book changed the way that I view the world. I can't walk through a door, anymore, without evaluating its affordances and usability.
The challenge (for me) is melding usability and aesthetics. In my experience, designing and implementing a truly usable software interface is hard. It's also highly iterative. A lot of "running things up the flagpole" stuff. I throw out a lot of code, and slaughter a lot of sacred cows.
It's true that there often exists a clash between designers and those who champion accessibility standards. IMO, this is normally because the designer in question hasn't enough experience working on software. Speaking for myself? I designed the accessibility features in Paint 3D while at Microsoft. I was in charge of accessibility of another Microsoft Studio that worked on Hololens software.
For MuseScore 4 (currently in development), I have made sure that every bit of UI passes web accessibility contrast standards and I have designed a new 'High Contrast Mode' which is being implemented right now. In addition, myself and another member of the UKAAF (Peter Jonas) have designed a far better focus state / keyboard navigation system into MS4 than MS3 had. This will enable much better screen reader support and will also help with ongoing efforts to introduce Braille support too.
I'm not one of those designers. But I do sympathise with the concern. I see it all the time!
You mention in the video that the next steps will involve interviewing users and developers to find out more about the software usability and potential issues / fixes. Could you make this whole process and the results public, such that other OSS can benefit from this kind of usability analysis?
There are indeed many resources out there about this sort of process, but I think it would be great to see an expert long-form explaining how they take the interview results and convert them into actionable goals in order to improve the user experience.
I'd add to this the thought of supporting a dumping-ground approach where people can throw suggestions, rants, complaints etc "over the wall" into a giant wiki/knowledgebase or bug tracker type environment that accepts OC submissions or just links to external discussions or sources of insight.
Hmm. Now I'm wondering whether such a thing should be run for a finite period, or left open to track improvement over time. Perhaps the system could be cyclic, with "calls for feedback" that would require re-submission into each cycle. This would have the advantage of effectively auto-closing all unfinished work after feedback invitations, but the disadvantage of frustrating repeat submitters of issues that generally don't get prioritized. ...You know what, there are probably good established ways of doing this, Microsoft probably knows this stuff backwards, and the Blender foundation seem to have a good feedback thing going so they probably know a thing or two as well.
Regardless of how it's done, spreading the fact that it is being done far and wide is IMO crucial (eg, getting this onto as many OSS/tech news sites as possible) - and I also think that the _worse_ the signal/noise ratio, the better, as I reckon this would be a good indicator that the long tail of the interesting really-edge cases are effectively being captured!
I just started using MuseScore 3.6 and I've gotta say it is surprisingly usable for an open source project. There are some annoyances, like drag-and-drop scrolling the page instead of selecting notes, but overall it becomes intuitive quite quickly. So, if that is your work, then congratulations so far! Looking forward to version 4.
In fact, accessibility is probably the last remaining hope of power users[0].
With general-audience software, the market doesn't care much about the minority that are the serious users, and it's hard to make a convincing argument to business people here. However, accessibility does have a strong enough ethical argument behind it, which is also increasingly being backed by regulations.
Allowing accessibility tools to work with an application involves annotating UI with machine-readable metadata about information displayed and operations available. That makes the interface comprehensible to any external software - including software that could use this information to provide an alternative, more ergonomic frontend, undoing various user-hostile decisions of the original design.
--
[0] - By which I don't mean just computer nerds, but also everyone who uses some bit of software on a regular basis - particularly in context of work.
In web apps, you can short-circuit this “there’s no business case” nonsense a bit by building your components using the accessibility attributes as the hooks between HTML, JS & CSS. E.G. rather than adding classes for everything you want JS and CSS to act on, instead hook onto the attributes role, aria-*, hidden and so on. If you do it as habit, it takes only a little bit longer to think about or type than attaching a class name, but helps you use the browser’s built-in accessibility support “for free”. If you work this way, you don’t even need to tell management what you’re doing.
I accept that this is easier on smaller, or new projects.
100% agree. I've noticed this as well. A lot of the time, the best objective-sounding argument for something I want is "it's necessary for accessibility", even though _I_ want it for reasons which would've been ignored. And a whole lot of the settings I rely on to make my computing devices comfortable are hidden under "accessibility" menus in settings screens.
There are even cases where the strongest argument for something to have a web version in addition to an Android/iOS app is accessibility. You can make some really interesting and specialized input hardware for Windows PCs which has no chance of working on an iPad, so there are people whose disabilities makes web apps way easier to use than any Android/iOS app. And if there exists a web app, power users can use the service from their comfortable desktop setup rather than from the tiny screen on their phone.
Accessibility is the most effective argument against the "one-size-fits-all" "it works for 90% of users" thinking that's otherwise so pervasive.
Accessibility is often understood to be for people with disabilities. For example, Wikipedia's first line on the topic[1] is:
> Accessibility in the sense considered here refers to the design of products, devices, services, or environments so as to be usable by people with disabilities.
And the W3C's intro to accessibility[2] says:
> When websites and web tools are properly designed and coded, people with disabilities can use them.
I don't have any disabilities which affect my use of technology. But I do like a fast key repeat rate, I like hot dim my screen at night further than the normal brightness setting allows, and I like to enable mono audio when watching a video where one of the audio channels is broken. I don't think most people would characterize these use cases as "accessibility", but they're all hidden under the accessibility settings in various systems.
You may consider this accessibility though, I don't know. There are definitions out there which don't put emphasis on disability.
One of the first things I do on a new Mac is to enable three finger drag. A couple of years ago this option moved fron trackpad settings to accessibility options.
yea when i was using windows a few years back i got some great mileage out of autohotkey + microsoft's accessibility access. (acc.ahk is the script someone make that interfaces with it if anyone is interested)
one good example was being able to control spotify. it doesn't work with the current redesign i don't think, but i used to be able to heart a song, show the current track name and artist in a tooltip, or list all the songs in your friends tab. lots of handy stuff like that and it all worked even when the spotify window was in the background
I would also recommend Emotional Design by the same author. It's a follow-up book that has been very useful for me to understand that great design isn't just usable and accessible, but should also be beautiful, and should respect that what people build using software are not just files on a storage system but often their most personally meaningful things.
For a long time nielsen groups webpage was one of the uglier websites on the web in the name of accessibility. That's part of where mistrust of them specifically comes from.
Also, like many pundits, there's a lot of "My way is THE ONE, TRUE WAY" stuff going on; which isn't a particularly good way to make friends.
They have the right idea (I have taken a number of NNG classes, over the years), but they are only one dimension, of a multi-dimensional space, and I have found it to my advantage to take a "hybrid" approach (which means that everyone is pissed at me).
I think it’s a culture change on the developer side. I was exposed to UI UX about fifteen years ago and worked with a number of terrific designers who put users first. The problem is as devs the job can feel overwhelming enough and then when you get to a point you feel is done, now you have someone telling you you need to redo it. It’s an egoless thing one has to develop and we don’t necessarily encourage that. I think the number of people who get to Beginners Mind as devs is as much Survivorship Bias as anything else.
Yeah, I think the definition of "done" is a great thing to focus on here. For me, the definition is generally, "works for the user". But waterfall-ish processes encourage developers to think that done means "finished the code". But that's really "finished the code for their first understanding of somebody's first guess at what might solve a user problem".
If something isn't "done" until it has at least survived a first user test, then we don't need to be quite as egoless, because we are a participant in the larger problem-solving process.
I also think your point on being overwhelmed matters a lot. Too many software processes are push-based, where an executive is cramming things in the hopper and insisting on a pace. I like pull-based processes. E.g., having a kanban board with WIP limits, so an individual unit of work takes as long as it takes.
The issue is that many designers and engineers loathe Usability and Accessibility people (like Jakob Nielsen and Don Norman).
For me, it all started with Don Norman's excellent book The Design of Everyday Things[0] (nee The Psychology of Everyday Things).
Reading that book changed the way that I view the world. I can't walk through a door, anymore, without evaluating its affordances and usability.
The challenge (for me) is melding usability and aesthetics. In my experience, designing and implementing a truly usable software interface is hard. It's also highly iterative. A lot of "running things up the flagpole" stuff. I throw out a lot of code, and slaughter a lot of sacred cows.
[0] https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things