True, Blender really exploded when they re-designed the interface. I hope someday GIMP team understand that. The software is solid, but the interface isn't great. Some very simple workflow changes made Blender easier to use.
I think a redesign of the icons was necessary, because the old ones don't look amazing. But you can make tasteful icons which are also colorful and recognizable.
(And I know you can switch icon themes, but when we're talking about UX, we're largely talking about the out-of-the-box experience. 99.9% of users are going to stick with the default icon pack.)
> (And I know you can switch icon themes, but when we're talking about UX, we're largely talking about the out-of-the-box experience. 99.9% of users are going to stick with the default icon pack.)
That said, Photoshop also uses monochrome icons and it can help in some ways to avoid distracting from the image which you are working on. I am not sure what the best compromise would be.
I know Blender has a lot of corporate sponsorship, so I think the explanation is there’s a “commoditize your complements” effect going on. But does anyone have a more specific hypothesis? E.g., why does Blender have so many complements and the GIMP so few?
I was under the impression it had more to do with symbiotic relationships between products. E.g., people using Unreal need modeling software (Epic is a sponsor), people using modeling software need GPUs (Nvidia is a sponsor).
I still think you’ve chosen a bad example. Gimp’s UI is no worse than Photoshop’s, and that’s not open source.
So this must be what happened... over and over I've heard about people switching to Blender now, even many professionals. I tried it many many years ago and found it, quite honestly, awful.
I guess I should download it again and see how things have changed.
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
Which is silly because good UX that works for people with disabilities or impairments also benefits fully able users in the vast majority of cases
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.
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.
That IS accessibility.
> 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.
[1] https://en.wikipedia.org/wiki/Accessibility
[2] https://www.w3.org/WAI/fundamentals/accessibility-intro/
I agree that's how the word is used most often. But using it that way others disabled people. Othering allows decision-makers to ignore the out-group because "it's not economically viable to support them" or because "it's too difficult" or "we'll have to learn & refactor, which takes time away from features"... or whatever.
I consciously put forward the suggestion, somewhat masked by my flippant tone, that developers (in the sense of anyone involved in "making": CEOs, management, designers, engineers) could do a small shift in their thinking that would open up the idea of access for all. This would push back the othering of disabled people, would include them. It would allow developers to work more creatively with the idea that their fellow humans interact with with products and services in myriad ways.
Even if you want to take the tighter definition of accessibility put forward on Wikipedia, the topic can still be opened up to new perspectives. Consider the differences between the medical and social models of disability. The medical model says that disabled people have deviations from mean physiology or psychology that must be addressed symptomatically, under "medical" supervision. The social model[0] pushes the disability out to our social systems. Sure, some people have "incapacities" - challenges with movement or sensory processing etc - but the dis-able-ing is enacted by the social systems (design patterns, funding, font-sizing, stairs vs ramps, stigma, othering) that ignores the needs of anyone off the mean.
I struggle to see clearly at distance. The fact I don't know which train to board is more because the station designers built the timetabling system with a typeface that can only be read comfortably by those with mean/median vision. If they printed it larger, I could stand in the crowd and read the sign like everyone else. If they'd installed a PA system and announcements, I could use my hearing instead. (fortunately, most stations do work this way now. Hopefully you can see the systems thinking in my example).
[0] https://en.wikipedia.org/wiki/Social_model_of_disability
That’s when I understood that I had a disability.
I accept that this is easier on smaller, or new projects.
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
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!
https://www.youtube.com/watch?v=4hZxo96x48A
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.
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!
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).
Take three people who never used given software, ask them to do the most basic tasks. And fix the most common problems.
Your software is much harder to use than you expect.
You do not need UI/UX people, massive scale testing to fix low hanging fruit.
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.