3 ms·

Worth noting that it's not just the technical end of UI construction that's lacking. Many open-source web projects have crappy UIs, too. I'm a long-time full-ti

Worth noting that it's not just the technical end of UI construction that's lacking. Many open-source web projects have crappy UIs, too. I'm a long-time full-time developer, decades-long linux user, and also wrapping up a BFA in design, so I think my perspective is pretty balanced, here. With amateur developers, their code becomes less reliable the further you get from their development environment. The effect is similar the further you move from a developer's primary keyboard/mouse/big screen computing interface. The difference between interfaces intentionally designed by specialists and functionality exposed through a GUI by a developer becomes more consequential. Sadly, most open source projects not run by larger funded organizations are kind of allergic to usability contributions from domain specialists, so that knowledge just doesn't get rolled in like it does with commercial projects. Most of the other developer/designer types I know don't even bother submitting design and usability improvements to open source projects. It's just not worth fighting people to make their software less awful to people who aren't already experts in it. It's a lot of work to put into something that will just get bikeshedded into oblivion by people emotionally attached to a bad ui. I don't know any developer who'd submit code to a repo controlled by people hostile towards code improvements, either. The Nielsen Norman group has some good stuff on usability within hierarchical organizations— I'd love to see similar organization-level reasoning about this stuff for small dev groups. I'm positive these two adjacent and necessary roles can function together without a product manager saying so. In their original usability matrix, "developer-centric usage" was directly above "usability hostile" but they've combined those categories, and especially with non-desktop platforms, that's absolutely the right move.

DeathArrow 5y ago
>The Nielsen Norman group has some good stuff on usability within hierarchical organizations Can you give a link?
- chefandy 5y ago
  Way too many to enumerate, but this is a good start: https://www.nngroup.com/articles/ux-maturity-stage-1/ https://www.nngroup.com/articles/ux-maturity-stage-1/
dirkc 5y ago
> submitting design and usability improvements to open source projects What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well. Sorry if this sounds defensive, but > bikeshedded into oblivion by people emotionally attached to a bad ui doesn't sound fair to me.
- chefandy 5y ago
  > submitting design and usability improvements to open source projects What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well. UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. Someone posting wireframes is almost certainly looking for feedback to test/refine their approach before they start coding because fixing is a whole lot more work in code than on a wireframe even if they can code. If they can't code and nobody feels compelled to implement it, then that's that— just like any other feature on an open source project. As an aside, I get flack from other developers when I say designers and their contributions are usually considered less valuable. When I don't, "surely we couldn't suggest existing contributor's spend time on such tasks" is one of the first responses. Thoughtfully facilitating task completion for humans vs exposing software functions in a UI is like designing good, scalable, maintainable software vs. making functions valid in a programming language that generally work together to accomplish a task. Consider an architecturally unsound project coded by folks with the most rudimentary development skills. Would you try fixing it in bite-sized PRs vetted by the people who made it— none of whom see a problem with the way it is? Even starting such an undertaking would be pointless. Similarly, the chance of any significant usability improvement being miscible in the standard flow of bite-sized PRs isn't great. If a project is on year 7 of using their undesigned UI, most logical steps between A and Z, even if the code is functional, have broken interfaces. What are the chances of a project going with the flow, there? You'd need to love that software more than your spouse to take that on. Beyond that, good usability is fundamentally informed by user needs, not architecture, library features, the existence of other elements, or developer preference. Also, UI changes are often fussy, require a ton of testing, and result in a ton of work that doesn't show up in the final code. That's true for all code to some extent, but developer reviewers see it more easily in a clever little algorithm than organizing elements in an input box. That makes them less likely to get the weight they deserve when encountering conflicts, even if the conflict is an uninformed opinion that nobody else around is informed enough to counter. I can't imagine any developer submitting code to a repo where the tables were turned. > Sorry if this sounds defensive, but >> bikeshedded into oblivion by people emotionally attached to a bad ui > doesn't sound fair to me. Not really sure how to respond to that. People are worse at taking critique for skills they aren't confident in. Ever give a brand new developer a code review? Yeah. That’s about what it’s like critiquing an open source project’s beloved “quirky” interface. Even users become attached to bad interfaces because they put in the effort to learn how to use it and assume everybody else matches their use case. It's like bad UI Stockholm syndrome. I cite any discussion where people express frustration with the interfaces for git or Gimp. Even implying they aren't on par with the usability of commercial offerings, let alone insufficient for their basic tasks, will get you flamed. I've seen this hostility many places, but I can think of one moderately popular app in particular that many non-developers come across. It's function requires fast, smooth input, and to facilitate that, has native clients on most platforms (including mobile) and is modestly funded by their very affordable, optional cloud storage service. In their discord board and issues, even contributors complain about clunkiness, counter-intuitive flows and inconsistencies between clients. Responses range from "eh, it's in the docs" to "it's idiomatic in that OS and totally unavoidable," to "yeah, we should really figure that out. It's on the usability project board." Actual usability discussions are rudderless, shoulder-shruggy, and fizzle out with things like conversations about which font people find most readable. I thought it would be a great place to contribute my expertise. I did one more search searching the forum for 'wireframe,' and every. single. thread. started by a designer posting nicely documented proposals w/user flow diagrams or mockups specifically asking to __kick off a conversation__ about how a more thoughtful UI might look was unceremoniously buried with comments like "what do you expect anyone here to do with this information?" and "the X to close that window is unnecessarily large according to X guidelines and XYZ elements are too close together, etc." and "please don't ruin my app by making it pretty." If they were non-technical people talking about a technical proof of concept you posted, would you take the time to break it down into tiny bite-sized PRs and submit them? If most projects you wanted to contribute to acted like that, how soon would you stop trying? It's just not worth the hassle until design knowledge and labor are more valued, fundamentally.
jancsika 5y ago
> It's a lot of work to put into something that will just get bikeshedded into oblivion by people emotionally attached to a bad ui. How does a maintainer like me who isn't a domain expert tell the difference between: 1. A submission created by a domain specialist 2. A submission created by someone who became "emotionally attached to a bad ui" change/feature ?
- chefandy 5y ago
  Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you. Secondly, how would you, as a maintainer, vet a code change outside your best-known languages or paradigms? For that matter, how do you choose a mechanic if you're not a mechanic? How do you choose a caterer if you're not a chef? Solicit outside evaluation assistance by asking for experienced design input on your repo page, newsletter, or other community gathering place. Look at previous work. Ask for portfolio links if you wish. Ask well-thought-out questions about: paths to accomplish tasks in the new vs the current setup; why specific changes are beneficial, to whom, and if it's deleterious to others; larger user goals or user groups seemingly left behind; important assumptions you think they made, fundamental implementation concerns without getting bogged down in inertia, etc. Experienced designers are used to having their work challenged and critiqued— that's true even for fresh college grads if they came from a design school. Bikeshedding, overt dismissiveness, unnecessary defensiveness, tangentially-related gotcha questions to make the asker feel less insecure about not being the expert, and other defensive/ avoidant behaviors look the same without code involved. If you see your community engaging in them, politely ask them to change their tune or butt out. You'd do the same if a designer on your team started an ill-informed group dart-throwing session at someone sharing a technical proof-of-concept. If the person challenging the designer can't justify their assertion as well or better, you should consider if they're someone you should trust with that decision. Thirdly, if you have to ask then it's probably never been a concern. Design is a communication field. Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. If they submit a cold PR out of nowhere with a significant interface modification and little to no justification, I wouldn't consider them a domain specialist regardless of what their portfolio looked like. If you've got some detailed interface modification proposals you're just not sure about, a good

DeathArrow 5y ago

>The Nielsen Norman group has some good stuff on usability within hierarchical organizations Can you give a link?

chefandy 5y ago
Way too many to enumerate, but this is a good start: https://www.nngroup.com/articles/ux-maturity-stage-1/ https://www.nngroup.com/articles/ux-maturity-stage-1/

dirkc 5y ago

> submitting design and usability improvements to open source projects What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well. Sorry if this sounds defensive, but > bikeshedded into oblivion by people emotionally attached to a bad ui doesn't sound fair to me.

chefandy 5y ago
> submitting design and usability improvements to open source projects What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well. UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. Someone posting wireframes is almost certainly looking for feedback to test/refine their approach before they start coding because fixing is a whole lot more work in code than on a wireframe even if they can code. If they can't code and nobody feels compelled to implement it, then that's that— just like any other feature on an open source project. As an aside, I get flack from other developers when I say designers and their contributions are usually considered less valuable. When I don't, "surely we couldn't suggest existing contributor's spend time on such tasks" is one of the first responses. Thoughtfully facilitating task completion for humans vs exposing software functions in a UI is like designing good, scalable, maintainable software vs. making functions valid in a programming language that generally work together to accomplish a task. Consider an architecturally unsound project coded by folks with the most rudimentary development skills. Would you try fixing it in bite-sized PRs vetted by the people who made it— none of whom see a problem with the way it is? Even starting such an undertaking would be pointless. Similarly, the chance of any significant usability improvement being miscible in the standard flow of bite-sized PRs isn't great. If a project is on year 7 of using their undesigned UI, most logical steps between A and Z, even if the code is functional, have broken interfaces. What are the chances of a project going with the flow, there? You'd need to love that software more than your spouse to take that on. Beyond that, good usability is fundamentally informed by user needs, not architecture, library features, the existence of other elements, or developer preference. Also, UI changes are often fussy, require a ton of testing, and result in a ton of work that doesn't show up in the final code. That's true for all code to some extent, but developer reviewers see it more easily in a clever little algorithm than organizing elements in an input box. That makes them less likely to get the weight they deserve when encountering conflicts, even if the conflict is an uninformed opinion that nobody else around is informed enough to counter. I can't imagine any developer submitting code to a repo where the tables were turned. > Sorry if this sounds defensive, but >> bikeshedded into oblivion by people emotionally attached to a bad ui > doesn't sound fair to me. Not really sure how to respond to that. People are worse at taking critique for skills they aren't confident in. Ever give a brand new developer a code review? Yeah. That’s about what it’s like critiquing an open source project’s beloved “quirky” interface. Even users become attached to bad interfaces because they put in the effort to learn how to use it and assume everybody else matches their use case. It's like bad UI Stockholm syndrome. I cite any discussion where people express frustration with the interfaces for git or Gimp. Even implying they aren't on par with the usability of commercial offerings, let alone insufficient for their basic tasks, will get you flamed. I've seen this hostility many places, but I can think of one moderately popular app in particular that many non-developers come across. It's function requires fast, smooth input, and to facilitate that, has native clients on most platforms (including mobile) and is modestly funded by their very affordable, optional cloud storage service. In their discord board and issues, even contributors complain about clunkiness, counter-intuitive flows and inconsistencies between clients. Responses range from "eh, it's in the docs" to "it's idiomatic in that OS and totally unavoidable," to "yeah, we should really figure that out. It's on the usability project board." Actual usability discussions are rudderless, shoulder-shruggy, and fizzle out with things like conversations about which font people find most readable. I thought it would be a great place to contribute my expertise. I did one more search searching the forum for 'wireframe,' and every. single. thread. started by a designer posting nicely documented proposals w/user flow diagrams or mockups specifically asking to __kick off a conversation__ about how a more thoughtful UI might look was unceremoniously buried with comments like "what do you expect anyone here to do with this information?" and "the X to close that window is unnecessarily large according to X guidelines and XYZ elements are too close together, etc." and "please don't ruin my app by making it pretty." If they were non-technical people talking about a technical proof of concept you posted, would you take the time to break it down into tiny bite-sized PRs and submit them? If most projects you wanted to contribute to acted like that, how soon would you stop trying? It's just not worth the hassle until design knowledge and labor are more valued, fundamentally.

jancsika 5y ago

> It's a lot of work to put into something that will just get bikeshedded into oblivion by people emotionally attached to a bad ui. How does a maintainer like me who isn't a domain expert tell the difference between: 1. A submission created by a domain specialist 2. A submission created by someone who became "emotionally attached to a bad ui" change/feature ?

chefandy 5y ago
Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you. Secondly, how would you, as a maintainer, vet a code change outside your best-known languages or paradigms? For that matter, how do you choose a mechanic if you're not a mechanic? How do you choose a caterer if you're not a chef? Solicit outside evaluation assistance by asking for experienced design input on your repo page, newsletter, or other community gathering place. Look at previous work. Ask for portfolio links if you wish. Ask well-thought-out questions about: paths to accomplish tasks in the new vs the current setup; why specific changes are beneficial, to whom, and if it's deleterious to others; larger user goals or user groups seemingly left behind; important assumptions you think they made, fundamental implementation concerns without getting bogged down in inertia, etc. Experienced designers are used to having their work challenged and critiqued— that's true even for fresh college grads if they came from a design school. Bikeshedding, overt dismissiveness, unnecessary defensiveness, tangentially-related gotcha questions to make the asker feel less insecure about not being the expert, and other defensive/ avoidant behaviors look the same without code involved. If you see your community engaging in them, politely ask them to change their tune or butt out. You'd do the same if a designer on your team started an ill-informed group dart-throwing session at someone sharing a technical proof-of-concept. If the person challenging the designer can't justify their assertion as well or better, you should consider if they're someone you should trust with that decision. Thirdly, if you have to ask then it's probably never been a concern. Design is a communication field. Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. If they submit a cold PR out of nowhere with a significant interface modification and little to no justification, I wouldn't consider them a domain specialist regardless of what their portfolio looked like. If you've got some detailed interface modification proposals you're just not sure about, a good