Jan DSomething that I have said in the past and hear from others, too, that developers can easily get started with contributions to open source projects, while it is difficult for designers. I am more and more wondering if that simple claim makes sense. (1/4)
But any change more complex needs reading existing code, often of soso quality with compromizes only explained by the project's history. And reading that code takes a looooot of time. Understanding the history, context and technology of a project is hard for devs and designers alike.
The advantage of devs is that understanding the code structures this archeology and that they can get help from other devs for it.
Still, devs usually can't do substancial changes quicky, either. (3/4)
The advantage of devs is that understanding the code structures this archeology and that they can get help from other devs for it.
Still, devs usually can't do substancial changes quicky, either. (3/4)
While good documentation, "good first issue"s and an friendly community help both devs and designers, they can't relieve the burden of needing to understand the context before doing non-trivial changes.
Now, external people (e.g. design agencies) are sometimes hired to do work and they do not understand the projects all so well, right? Yes, but they, too, get onboarding (also cause they are expensive) and their problems are often carefully pre-packaged and standardized. (4/4)
Jan Eckhoff 💉⁸ 🐘@simulo maybe one of the main differences is that while as a dev, you can learn a lot about a project by looking at the codebase, which is published on GitHub/Codeberg/…, we UXers would need the documents that serve as a foundation for the design, i.e. personas/scenarios, requirements, wireframes etc. — and I suspect that many OSS projects start as a purely technical project, so design is something that just „emerges“ during development, without ever doing „proper“ design work.
@janeckhoff Is learning about a project by reading the code as a dev not like looking at the UI as a designer?
The ideosyncracies of the code won't be explained by the code – most projects do not even have a page that explains the broad architecture of the code
(Code being the central artifacts still has a lot of advantages for developers like tools and community around it etc.)
The ideosyncracies of the code won't be explained by the code – most projects do not even have a page that explains the broad architecture of the code
(Code being the central artifacts still has a lot of advantages for developers like tools and community around it etc.)
Toke@simulo As a UX designer, I have considered contributing to FOSS projects now and then, but for me, the hurdle has always been what the "good first issue" should be. If I think of projects like QGIS or InkScape, I can find things to improve, but it would often have to be consistently changed across the UI. And maybe the changes would get lost in discussions about taste or mental models that a small fix to a code module would not. But I have never given it an honest shot.
> consistently changed across the UI.
That is true, code can be compartimentalized in ways UI can't
(See also: Duguid, P., 2006. Limits of self-organization: Peer production and “laws of quality.” First Monday 11. https://doi.org/10.5210/fm.v11i10.1405 )