Where the design community meets.
Berlin Joined almost 2 years ago
I can’t see the image, but going by your description, “pannable canvas” or “endless canvas” perhaps?
Consider that your users may use nightshift/f.lux because they don’t want to look at blue light in the evening. I also found that especially dark blues tend to look very different with those modes enabled. It really becomes greenish, even when you’re used to the white balance shift.
To me they’re all confusing! Perhaps something like ‘12h ago?’
Hi Alex, what do you want to actieve with your writing? If it’s content marketing, if makes sense to write to the interests of your target group. I write mainly for myself and to just share whatever I’ve learned recently. The for myself part works best when I publish it in some form, because it makes me more careful to check sources, see the other side of things and it forces me to be precise in my writing and thus thinking.
As for topics I’d like designers to write about: less about tools and outcomes, more about ethics, collaboration, future visions, inclusiveness, design as a profession, aesthetics and applied behavior psychology.
For my own writing I use my notes app to collect ideas. I let them sit there for a while and whenever I have time, I go through them and pick one that I believe I can write something about from a perspective I haven’t seen before.
I think the usefulness of the concept depends on the application and users, so I’d try to do a bunch of tests with actual people.
My impression: 1. If the tabs look like tabs I guess they’re familiar enough. Right now they look like actions, the plus button in the center adds to that. 2. I find it counterintuitive to scroll up to get the bottom nav.
I like the creativity in the solution to work around that awful iOS Safari behavior. I don’t think it solves the problem you’re stating though. In the initial solution with the standard bottom nav, they’re a clear indication for users where to tap. In your new solution there isn’t. Another problem you had with the initial solution was that there are two actions necessary that aren’t 100% intuitive, because the buttons jump. With the new solutions you haven’t really solved that: it still requires 2 actions and the behavior of the nav appearing and disappearing is likely less predictable as it’s not standard iOS Safari behavior.
But that’s just me.
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.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.