Where the design community meets.
Berlin Joined over 1 year ago
Yes, keep that optimism; I love the idea!
Are you saying we are missing the point here and that what we need to do instead is educate open-source design leaders about the value and techniques of design and product leadership?
Not really, I think your original idea can work out really well. It's just that I think to make the designs successful, the project's scope should go beyond having designers design things.
Keep us posted, alright!
You're right, I should have written "there are no FOSS screen design applications". Sure, there are graphics applications, but those require that old school workflow. I think for many projects Figma can be a great solution though!
I'd expect that to be at Menu Sketch> View> Show Fonts > Gear Icon > Typography
Edit: nah can't find it either.
Hi Varun, I very much agree there is a problem. Free, open source software can have many benefits over commercial software (like no vendor lock-in, resilience, no commercial interests opposing user interests, customizability). It seems like such a waste that all that engineering effort is currently not finding its way to others than programmers. I haven't found free, open source software (FOSS) that:
The few successful FOSS projects targeting end users are Firefox, Thunderbird and VLC (and arguably Atom Text and Ubuntu), but these have strong professional teams leading them. I'm sure I missed a few more examples, but you get the point.
A while ago, I wanted to contribute to the software I thought could be useful to me. I felt rather discouraged after joining several bug trackers and forums though. Back then I made some notes that I just quickly put together, because they seem relevant. Feel free to skip to the conclusion!
FOSS projects are often organised version control and bug trackers. People who don't program software typically aren't capable of using version control. Git seems to be the default nowadays and I think that's a good thing. But without some serious effort to learn and practice, Git is just horrible.
I've encountered several bug tracking applications and I found non of them inviting. I understand it's useful to put up a barrier and not have a project flood with tickets from users. But this selects for tech-savvy users only submitting bugs. None of the bug trackers showed me what the process of submitting a ticket would be like and what would happen to it.
There are no FOSS design applications. This is a problem, because for many projects it's important that there's no vendor lock in, specs are accessible beyond the duration of someone's paid software subscription for something like Sketch Cloud and that the tools work on Mac, Windows and Linux. Figma and Abstract offerings are a step into the right direction though!
For some applications, I would have liked to spend some time on redesigning features, but it was totally unclear who was running the project. Especially unclear was who could look after my design getting implemented (or who I should get in touch with about that). Even in well-organized product teams designers sometimes struggle to convince others their designs should be implemented, so I think this is a big problem.
Community-driven FOSS projects typically have a development process that is optimized for engineers. That means that other users are rarely heard. Prioritization of tickets is based on the engineers interest in an issue. As a result, big projects lack focus and consistency in design.
Even when submitting a usability issue in itself isn't hard (not a given), the process that follows can be ineffective. It was expected that I came with clearly specified solutions. Fair enough, you can expect that from a product professional, but not from a any user. My tickets that didn’t include solutions (I didn’t redesign all the apps I submitted issues for) were usually closed. The same happened to issues for which I provided clear solutions, as they were considered not engineering problems.
Knowing the UX of better tools and designers being especially susceptible to good UI, most FOSS just looks repulsive. So designers may be even less likely to use FOSS than the general public, as Sacha pointed out.
FOSS looking as bad as it does could be a nice challenge to make a difference, but software that is developed far enough to be useful requires such an amount of redesign work, that it would require a huge design investment. Just polishing up the visual design or making the interactions of a certain flow work well won't make it a good application.
A designer being interested in doing that nonetheless, must wonder: "Why is the application so badly designed? Surely because the makers don't value design?" Again a reason not to even contact the team.
Bug fixes and the engineering of new features show immediate results and (possibly) measurable, objective improvements. Engineers can create their own forks and use those enhancements even if they're not accepted by the community.
Management, design and marketing on the other hand, require collaboration, vision and often need several months of work to be of any use at all. When at the start of, say, a redesign project there is complete uncertainty about the commitment of engineers to implement the new design, it's not attractive to spend several months of work on it. This is more than a hypothetical problem. I know someone who, after several years of doing design work, left the Gimp project because of that.
To be successful beyond a group of scratch-your-own-itch software makers, community-driven FOSS projects need more than open tools and a transparent, user-centered design process. From the an early stage, designers, PMs, marketing and business people should be part of the leadership team, not just engineers.
So as for your 'Summer of Design' idea, Varun, I think it can work under a few conditions. I think the developer community of a project must be motivated to implement the design work. When that community has been volunteers in the past, that probably means your 'Summer of Design' should be integrated with a Summer of Code-like event. An existing community may not like the sudden changes in the design (imagine having spent years contributing to an image editor to make it work for your arcane editing flow and then some design students saying it's not user-friendly).
Alternatively, there may be projects that are not of the scratch-your-own-itch kind that still have passionate engineers. I can imagine applications with social impact as a main driver, solving problems of medical professionals, undereducated users or an otherwise disadvantaged target group. For such a product designers and others are all the more relevant to engineers, as there won't be the kind of direct user feedback they'd see in other FOSS projects.
As you mentioned, there needs to be coordination, which, I think, means it takes the power of decision making (about product vision, feature prioritization, etc.) away from an existing community. Forking existing projects or starting completely new projects may be a way to avoid the community getting upset. Finally, as I mentioned above, that coordination (management) needs to be permanent for the work not to get derailed by featuritis. All in all that would mean you'd be putting a professional product team together to lead such a FOSS project. That requires a lot of resources beyond the event itself.
I agree with everything Kemie said (although I don't care too much about the exportability of palettes, but hey, nice to have!).
Added to that, please consider the hue/saturation/brightness model that is, at least in my experience, used most by designers is … not great. I don't think that when it was developed in the 1970s, its creators thought it would still be in use, this much, in professional design software. Sure it's easier to use than RGB and CMYK (or LAB, I never really got a grip on LAB colors). But it's quite useless when trying to find colors with matching saturation and brightness. One would think that two colors with the same brightness value would be equally bright, but perceived brightness depends on hue. That's just one issue of many (here's some more info on that). A color model (or a mode on top of HSB) that takes perception into account would be soooo nice.
Buying stuff you don’t need won’t make you happy. If you want to spend the money anyway, consider giving it away—that will give you probably more satisfaction, studies show. Check https://www.effectivealtruism.org/ if you’re worried about where it would be best spent.
I don’t think one will replace the other. But web apps become ever more useful. Even on iOS offline use is now possible. Not sure if push notifications are there already, but if not, I don’t think it should take long.
There still are performance issues with web apps, but for some applications these aren’t relevant except maybe to some purists.
— Edit: Arguably, web apps existed before native mobile apps, depending on your definitions. As product makers I think it’s important to focus on the particular application we’re creating solutions for and the context and phase of the venture. Early 2010s there was a whole movement trying to do single codebase cross platform web apps and those were often rather mediocre. Some were good too, some really bad. Point is that there is and won’t be a single solution to all design and engineering problems.
Abstract is amazing. It can take a bit of getting used to if the team is not familiar with things like branches and merging. But you can use it for many steps in the design process, like approval, QA and separating current and future implementations.
Interesting, you’re saying you’re using breadcrumbs as a combination of history and taxonomy, right?
My point was not that the category shouldn’t be shown btw, just that I’m not sure you’d call it breadcrumbs if there’s only one crumb.
It’s quite common to not include home and the page itself in bread crumbs. After removing those you wouldn’t have much left of a bread crumb trail I guess :)
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.