3 ms·

> submitting design and usability improvements to open source projects What format does this take. My experience is that more often than not, design and usabil

by dirkc 5y ago

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.
- dirkc 5y ago
  It sounds like you've had some bad experiences, sorry for the bad ones :( I've had my own experiences and perspective, some good some less so. It's important to remember that making anything concrete requires tradeoffs to be made - ie less clean code to address edge cases, more complicated UX to accommodate important features, less functionality to increase UX, etc. It's always on a spectrum of completely ideal vs really crappy. For code and UX. I've been on different parts of that spectrum, but I think I caused the more harm than good when I went close to the edges. I don't really know where I'm going with this, but do know that your expertise and labor carries value! And finding the right place to contribute can take some time.
  - chefandy 5y ago
    Not many bad experiences— I looked before I leapt. It's not a hard resource constraint in many cases— the resources just opt out of contributing. Despite the unicorn moniker, many designers know how to code! I've worked as a full-time developer for 12 years, and did comparatively simple but non-trivial systems-focused scripting in sys admin/support roles prior to that. Especially among more UX-oriented designers, most started in other careers, and many of those careers were related to software in some way. A developer I worked with until recently had a BFA in New Media from a top-tier art school. Most designers/developers I know just don't contribute design to FOSS because interfacing with FOSS projects for anything other than bug fixes and feature implementations is often a giant PITA. Facing critique about work we aren't confident in sucks. Most people reflexively respond with defensiveness, dismissiveness, or just shut down and ignore it. Since most FOSS UIs were created by people without subject matter expertise, most who make decisions about them have the expected response. It's like giving a brand new developer a code review. Calmly explaining how to practically reason about algorithmic complexity won't stop many from insisting a thrice-embedded loop with database calls that gets called every time an event loop runs is the best possible solution— at least for a while. Sometimes you can argue them out of it. Sometimes you just have to say "trust me— it might not matter in your dev environment, but this is fundamentally broken and needs to change." That doesn't work with FOSS projects, and even getting to that point in the design phase takes a significant amount of work! Even at work where a project leader is assigning tasks based on quantifiable business needs, dev teams often see design as superfluous. Most FOSS projects don't have that level of oversight. Fighting glib, dismissive, patronizing arguments born from assumptions and egos of people who believe the topic is somewhere from back-burner importance to superfluous just isn't worth it. I'm certainly not going to spend a bunch of time logically analyzing user goals and figuring out the most logical paths and visual cues to help them achieve those goals when I have to fight through that to even start coding. Sometimes a polished user flow really is superfluous— anyone who sets up procmail enough to care about its usability will soon learn their way past its inscrutable configuration. But most applications aren't like procmail, and most FOSS interfaces aren't sufficient for their purposes. It's sad to see commercial software consistently trounce functionally identical or superior FOSS because of usability. Word of mouth + free could trump damn near any marketing/advertising campaign if people actually liked using it.

by dirkc 5y ago

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.

dirkc 5y ago
It sounds like you've had some bad experiences, sorry for the bad ones :( I've had my own experiences and perspective, some good some less so. It's important to remember that making anything concrete requires tradeoffs to be made - ie less clean code to address edge cases, more complicated UX to accommodate important features, less functionality to increase UX, etc. It's always on a spectrum of completely ideal vs really crappy. For code and UX. I've been on different parts of that spectrum, but I think I caused the more harm than good when I went close to the edges. I don't really know where I'm going with this, but do know that your expertise and labor carries value! And finding the right place to contribute can take some time.
- chefandy 5y ago
  Not many bad experiences— I looked before I leapt. It's not a hard resource constraint in many cases— the resources just opt out of contributing. Despite the unicorn moniker, many designers know how to code! I've worked as a full-time developer for 12 years, and did comparatively simple but non-trivial systems-focused scripting in sys admin/support roles prior to that. Especially among more UX-oriented designers, most started in other careers, and many of those careers were related to software in some way. A developer I worked with until recently had a BFA in New Media from a top-tier art school. Most designers/developers I know just don't contribute design to FOSS because interfacing with FOSS projects for anything other than bug fixes and feature implementations is often a giant PITA. Facing critique about work we aren't confident in sucks. Most people reflexively respond with defensiveness, dismissiveness, or just shut down and ignore it. Since most FOSS UIs were created by people without subject matter expertise, most who make decisions about them have the expected response. It's like giving a brand new developer a code review. Calmly explaining how to practically reason about algorithmic complexity won't stop many from insisting a thrice-embedded loop with database calls that gets called every time an event loop runs is the best possible solution— at least for a while. Sometimes you can argue them out of it. Sometimes you just have to say "trust me— it might not matter in your dev environment, but this is fundamentally broken and needs to change." That doesn't work with FOSS projects, and even getting to that point in the design phase takes a significant amount of work! Even at work where a project leader is assigning tasks based on quantifiable business needs, dev teams often see design as superfluous. Most FOSS projects don't have that level of oversight. Fighting glib, dismissive, patronizing arguments born from assumptions and egos of people who believe the topic is somewhere from back-burner importance to superfluous just isn't worth it. I'm certainly not going to spend a bunch of time logically analyzing user goals and figuring out the most logical paths and visual cues to help them achieve those goals when I have to fight through that to even start coding. Sometimes a polished user flow really is superfluous— anyone who sets up procmail enough to care about its usability will soon learn their way past its inscrutable configuration. But most applications aren't like procmail, and most FOSS interfaces aren't sufficient for their purposes. It's sad to see commercial software consistently trounce functionally identical or superior FOSS because of usability. Word of mouth + free could trump damn near any marketing/advertising campaign if people actually liked using it.