Ecaterina Moraru

I will present some general UI/UX tips & tricks that will help you design better. Everyone should know the basic principles and patterns of design, and once you understand them you will naturally integrate them in your work.

UI/UX is a craft. The more you practice it, the better you are at it. Some people argue that you need to have 'good taste' in order to be a designer, to be the 'artsy type'. While this might be true for Graphic Design, Branding and Visual Arts in general, when it comes to Interface, Interaction and Product Design, the focus is more on practicality and 'common sense'.

Open discussion about getting more designers participating in Open Source projects and better understanding of the barriers that may be preventing them from contributing.

We will invite several designers into the panel, to share their experience with their open source communities and provide insight on the topic. Some questions will be interactive and the public can also vote and respond, representing their opinion.

Software platforms need to be highly extensible and customizable, since developers need to build on top of them and provide the best experience for users. Some users put more focus on the styling and visual aspect of their customization, others need it to be highly accessible or responsive, while others just like to have diversity in their choices.

Being able to provide multiple icon sets inside a platform is still a difficult task because of the variety of ways icons can be provided: as images, as font sets, as SVG, etc. I will present a solution for creating and using icon themes, also mentioning the limitations and the difficulties we had in implementing such a solution on our platform. Several icon libraries will be compared, showcasing the reasons, decisions and the compatibility and mapping issues we faced during the process.

Closing remarks for the Open Source Design devroom + Group photo.

Open discussion about the design feedback process, gathering expectations and guidelines from different open source communities.

Every Open Source project is different, every developer and designer is different so hoping that this session would provide a magic answer to our questions is not realistic. Its purpose is to open the discussion and try to gather examples from different communities in the search of drawing some guidelines.

In Open Source, the hardest part is to know when a design iteration should stop: after a certain amount of time, after a certain amount of votes, etc. Since there are no real/accountable stakeholders/decision-makers and the majority of decisions are done with voting, it can be hard for a designer to know which voices should be listened when iterating. Also, design is not really like code, so it can be harder to do partial work and just let another designer continue it. Sometimes things need to be redone from scratch (because of style differences, vision, approach, tools, etc.)

The purpose of giving and receiving feedback in open source should maximize the input all parties receive, having in mind their interests, availability, experience, commitment, etc.

Some questions we could ask: - What can be done when we feel there is no consensus between designer and community or even between community members? - What are the motives for proposing the design work and how much work does it involve? - Should something be accepted just because it's the only proposal? Do we have the luxury to refuse design work? - Should the same rules as in code review be applied? - How do we better match designers and communities in terms of style? - Should people from outside the community be involved in the feedback process? - Are community members the target or representatives for their users?

Meeting everyone's expectations needs a better communication and understanding of the topic and that's what this session tries to achieve.

Community stats for the past year and a short summary of the success stories from Open Source projects that posted design jobs inside our community and got a designer involved. Talk held by @evalica and @eppfel.

We might need a designer to provide a clear vision and solve everything we couldn't agree upon. Also the designer might expect to be warmly welcomed inside Open Source projects, but the reality can be a bit different. We always have expectations on how the designer - community interaction should be, but in order to have a successful collaboration we need compromises, sometimes from the designer's part, other times from the community members.

If we were to ask someone if Open Source communities need designers, the answer would be 'YES'. But do we know what it means to have a designer among us? What will he do? For how long? How true can he stay to his predefined design process? Are all the design stages relevant in Open Source? How open the artefacts he creates need to be? With what type of tools?

We all have an image in our head about the type of designer we need for our community, but how much of that image corresponds to our real needs and with the designer's reality and expectations?

In order to integrate in an Open Source community, a designer might need to revoke his design 'purity' and make some compromises, like doing a bit of development for example. Does working in a free or open environment mean that the work needs to follow the same rules? What is preferred: creativity or consistency? Does the designer have the final decision?

Working in an utopian environment doesn't mean that we don't do compromises. So, how much do we compromise?