His twitter (https://twitter.com/Tantacrul) and youtube (https://www.youtube.com/user/martinthekearykid) are full of interesting tidbits, an you can tell he's passionate about things.
Even if you don't do music/notation his video on Sibelius, https://www.youtube.com/watch?v=dKx1wnXClcI , is ridiculously funny, but also on point.
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).
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.
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.
Unless the devs get UX improvement backwards (cough GNOME cough), there's nothing to worry IMHO. OTOH, for a CLI application, backwards compatibility and/or graceful depreciation is key.
And also the attitude of "works for me" really pushes usability people out.
So there is much smaller motivation to improve it.
And avoiding change for the sake of change is something that I actually like. One of reasons why I switched to LibreOffice and later to Linux is because I am not fan of relearning interface without a good reason.
-------------
But nearly every software would benefit from running small scale UX test. Take three people, ask them to do the most basic tasks - and fix the most common problems.
Your software is much harder to use than you expect.
It does help when software users that happen to have good UI chops suggest redesign because then it often improves things, as I've seen happen with KDE and Budgie, at least. But pulling in UX "designers" who have no skin in the game and letting them play around is how you get ridiculous unusable crap like Google Pay, Apple Music, Windows 8, whatever Google is calling their Android UI now, and more.
And there's also a widespread belief among developers that making a task easier in the UI means "dumbing down" the UI. Or that making software easier to use means it could never satisfy "power users".
Developers love to revel in arcane interface minutiae (especially for command-line tools). They think it's equal to acquiring a skill or knowledge. But it's not really. Instead, it is the perpetration of a clumsy method to completing a task. But now that the developer has mastered that method (and that feeling of "knowledge" gained as a consequence), they won't easily let go. Or be easily persuaded of a different method.
Not in every case. For experienced/professional/power users of any software, what matters is maximizing the information density in time of both input and output. Sometimes the best way to do that appears arcane.
I want to be able to accomplish much in as little time as possible, so I want a high temporal input information density. So that might mean using a mouse instead of a trackpad for precise aiming and scrolling, or using keyboard shortcuts instead of on-screen icons. It might mean there are different mouse behaviors for ctrl-drag, middle-click-drag, etc.
I also want to be able to receive as much information about the state of the application as possible in as little time as possible. Too little density and I have to keep more state in my head and spend time jumping around. Too much density and the senses are overwhelmed. This might mean, for a CLI tool, that zero output is the best output in case of success. But for long-running processes that might be a progress bar under a list of log entries. For GUIs, the optimum might mean that there is a lot of information and a lot of actions on screen with reduced whitespace, which seems intimidating at first but is necessary to communicate the state of the system to the user.
So convincing any power user to "let go" is like asking someone to give up their legs for a scooter. Sure, it's simpler to go places in mostly straight lines with a scooter, but linear motion is only one of the many things people do with their legs that justify the arcane UI of unstable bipedal locomotion. We walk along streets, run along trails, jump over obstacles, dance, spar, climb, swim, etc.
This is not to say that scooters have no place, or that every tool is at a global optimum. But any "different method" that someone wants to propose will very deservedly receive pushback if it does not fulfill the full purpose of the old method.
This should in theory allow for a complete redesign of the gui though, as the core audience uses shortkeys anyway.
"Old style" interfaces are universally better than tabletized crap, and had as much and higher quality research into the choices behind them. It's not limited to OSS. Apple is a glaring example of that right now. The Mac Human Interface Guidelines and the thought that went into the Mac OS were phenomenal. Contemporary style changes driven by users' familiarity with tabletized (or dare I say "Fischer-Price") UIs are regressions. Visible things become hidden to look "cleaner," keyboard control is ignored, oversized buttons are favored.
The thing is (unmentioned in Tantacrul's Audacity video) is that Audacity's UI has always - from day one - been a terrible copy of the much beloved SoundEdit16, afaict. I just want something as easy to use as SoundEdit was, if Tantacrul is reading.
I think a lot more OSS projects should reach out for contributions in improving usability — it's almost always what separates OSS projects from paid alternatives.