Articles | Open Source Design

Beginners Guide to OPEN SOURCE Design via Victory Brown's Hashnode.dev page

Victory Brown — Mon, 02 Nov 2020 00:00:00 +0000

Repost from Victory Brown’s Hashnode blog page. Victory Brown is an Open Source Design Community member Victory Brown about what it’s like to begin contributing to Open Source as a designer for the first time with advice, tips and tricks on how to make that experience successful.

An inspirational quote from the article at the end is one that most, if not all open source designer can share:

“For someone who had never heard of open source until recently, I’ve found it to be quite addictive, it’s my desire to have more designers join the community, improve and develop the open source space.

The open source community is waiting for what design initiatives can impact the entire software industry. The open source community is waiting for design minds like you. The future is not just Open, the future is Design.”

View the article on Victory Brown’s hashnode.dev here

Read more on opensourcedesign.net →

COVID-19 ILLUSTRATIONS

Thu, 20 Aug 2020 00:00:00 +0000

Based on recommendations from The World Health Organization and others, you’ll find symbols to communicate good hygiene and social distancing. While we can’t be like front line brave medical professionals across the globe, we hope these icons/illustrations aid in communicating some of the most important things people can do to protect themselves and their communities.

Free COVID-19 Awareness Icons

All solid COVID-19 illustrations are available Open Source. A trial for some period to incorporate these can be availed at bioRENDER. Use them however you can in your signage, reports, sites, apps and projects. And please share any of your efforts – we’d love to see them and help boost awareness and helpful information.

About BioRender

BioRender envision a world where science is universally communicated and understood through visuals. Represent science with intuitive visuals that can be understood by everyone. ACCESSIBLE. Anyone can use the platform - no drawing or design skills required.

WHO guidelines against COVID-19 :)

To protect yourself and others against COVID-19, clean your hands frequently and thoroughly.
Use alcohol-based hand sanitizer or wash your hands with soap and water.
If you use an alcohol-based hand sanitizer, make sure you use and store it carefully.
Remember that washing your hands with soap and water is also effective against COVID-19.

Stay healthy, safe, and awesome to each other, folks. Do keep washing your hands!!

Eriol guided and motivated me to write this article :))

Read more on opensourcedesign.net →

Use your artistic skills to help open source via opensource.com

Jeff Macharyas — Thu, 13 Aug 2020 00:00:00 +0000

Repost from OpenSource.com for an article from Jeff Macharyas about Open Source Software projects and how Open Source Design connects projects that need design help with the designers who can help them.

View the article on Opensource.com here

Read more on opensourcedesign.net →

Open source design needs better collaboration tools

Mon, 27 Mar 2017 00:00:00 +0000

Despite the rising awareness and acceptance of UX design, in particular on the web, it has failed to gain much traction in open source software. If for argument’s sake, we take UX design to have started in 1995 when Don Norman started work for Apple as a “user experience architect”, even though it has a longer history, then the fact that design has failed to make much impact in the open source world for over 20 years suggests that there are structural and systemic barriers that make design and open source development as compatible to each other as oil and water.

In this post, I will argue the need for better communication and collaboration platforms by looking at some of the fundamental characteristics of open source design and development and propose some starting points.

The goal of OSD is to improve the user experience of open source software. Because open source software development is distributed, certain critical infrastructure is necessary. I am talking about a way for designers to share and build upon ideas, interact, reach consensus and collaborate with other designers and all the other stakeholders involved in the creation of software.

You may think that we already have such tools. Just look at GitHub! But when we consider the target user and use case of such tools, it becomes clear that there are no complementary equivalents for designers. Even worse, there is no tool to bridge the gap between designers and developers. GitHub and the like cater exclusively to developers’ unique needs and abilities. In doing so, it excludes other stakeholders and becomes a developer silo. Design is not like this. It cannot exist in isolation. Design is about understanding, facilitation and collaboration between all the relevant stakeholders. This is why I consider collaboration tools to be so important to design. Surprisingly, the closed source world is not a great deal better off. The Atlassian and Google ecosystems are the best that I can think of, and these were not built as a platform for design.

A true collaboration platform for designers must, in some sense, bring in all stakeholders. This is where the very immature and untested idea for a collaborative design and development environment comes in. More details about this vision can be found on this slide deck.

Because of the nature of open source software, collaboration tools are even more critical and have different needs from commercial or closed source development:

All the stakeholders are distributed. Not just users, but designers and developers. No one stakeholder may ever be in the same room as any other stakeholder! Online communication suddenly becomes far more complex and important.
Anyone can contribute. This raises issues of quality and decision-making.

Let’s have a look at some other characteristics of open source software:

Users are often developers or have high tech empathy.
The maintainer (often a “non-designer”, to put it delicately), is the decision-maker, gate keeper and arbiter of good design.

This raises thought-provoking questions often overlooked in discussions about open source design: is design even needed in open source software? If the end user and creator are the same kind of person, then the design is already user-centric. And should design follow the same model as open source development, in which anyone can make a pull request? As we all know, on the internet, nobody knows that you are a dog! This can be a problem because design is harder to judge than code.

Photo credits: Derivative of photo by Karen Arnold. Creative Commons Public Domain.

In writing about the right tools for OSD, I am putting the cart before the horse. The systemic problems are too large a topic for this post, but they must be identified and addressed first. However, open source design is at such an embryonic stage that even something as fundamental as a dedicated area for discussion and idea exchange to bootstrap the movement does not exist. This is why I have tried to identify our immediate needs, so that a more suitable tool than GitHub Issues or StackExchange can be found.

The diagram below shows characteristics of different collaboration platforms used to develop open source software, depending on the user (developer or designer) and whether it is project specific or agnostic. There is currently no dedicated platform for designers to discuss open source design in general (box number 3), so I have merely exercised my imagination to describe its characteristics. Reddit has a forum for open source, and StackExchange has a UX forum, but I would argue the tone and nature of discussion is different from what we have and need here. Finally, the last box (5) is a totally different platform, which I described earlier as a collaborative design and development environment. This would be a platform that takes in to account the unique characteristics of open source software and ideally would be built from the ground up as a platform for design, for all stakeholders.

The next steps are to:

decide what kinds of discussion and collaboration OSD actually wants to support.
determine the requirements for those types of collaboration.
find the tools that best meet the above requirements.

A platform for people to discuss open source design and development is admittedly a very niche area and the fact that no such platform exists may speak volumes. But it is better to fail in the attempt, than fail for lack of trying, and the fact that we have, in my opinion, outgrown GitHub Issues, is a promising sign. I hope this post makes our situation clearer and will stimulate further discussion and action.

Read more on opensourcedesign.net →

5 Steps to Design a UX that People Love

Sat, 21 Nov 2015 00:00:00 +0000

Research, prototyping, and testing. The easy way.

Presented to you by the co-founder of Loomio.

My brother Matthew Bartlett and I have been contributing design to the open source project Loomio for a while now.

In the past couple of weeks we’ve stumbled on a design process that is working really well for us.

1. Find a problem worth solving.

Thinking in terms of problems people have or jobs people want to do is a great way to stay focussed on creating a useful user experience, rather than a whizz-bang cool feature that nobody wants.

For this example, we’re looking at redesigning the search experience for Loomio. The first step is to talk to people and ask what are you searching for?

2. Research how other people solve it.

In some respects, all UX design is ‘open source’, even if the underlying code is hidden: if you can play with the software, you can learn how it works.

Here’s the result of a couple hours of research into how other popular apps handle search:

In this case, Matt created a little video to distill what he learnt from the research, and share it with the rest of the team.

3. Make an interactive prototype based on what you’ve learnt.

Looking at a single screen won’t tell you much - you need to consider the whole workflow in context: all the steps that the user goes through to complete the task. It’s called a workflow because it should flow.

We use Sketch for drawing mockups and InVision to stitch them together into interactive prototypes. (You can learn about how we use these tools in this talk I gave recently.)

So for the Loomio Search example, Matt made this video demonstrating how the parts fit together.

Video is a good a way of sharing a workflow, but quick animated gifs are even better! With a tool like RecordIt you can record an interaction, and upload and share it in a few seconds, which makes it effortless to get feedback:

This gif took me about 20 seconds to record and share. Gifs are also awesome for help documentation, developer QA, and marketing, but that’s a whole other blog post :P

4. Test, learn, iterate, deploy, repeat.

The next step is to test these prototypes with real humans. Testing can be super lightweight: you will learn a lot just by watching a friend or colleague try to interact with your prototype for a few seconds.

As soon as we’re confident we’ve got a design that is an incremental improvement on the existing UX, we get it built and into people’s hands as soon as possible: You learn so much more from use than you do from opinions!

5. It’s all about love!

“Product design” is a process, it’s not a job that comes with a start and an end. It’s an ongoing relationship between the people building the thing, and the people using the thing. Like any other relationship, you need to pay attention to the details and communicate abundantly. Your job as a designer is to learn what makes your users happy, and what makes your devs happy.

It also helps if you can occasionally blow their minds with something they never asked for! ♥

Originally written by Richard D. Barlett on Medium

I write about working together. Loomio cofounder (https://www.loomio.com/). Enspiral member (http://enspiral.com).

Read more on opensourcedesign.net →

Why open source designers need tools beyond text and code

Sat, 23 May 2015 00:00:00 +0000

Text is the predominant means of creating and collaborating on software. Design is a visual and spacial activity. For those who design software and websites there is a non-visual world that needs to be navigated and taken into account: text in the form of program code and comments.

This has historical and technical reasons, beyond that computer programs are essentially created in code. But the text based tools and culture of creation and collaboration have severe drawbacks for designers who are part, or are striving to be part, of the creation of software. This is particulary relevant in the open source community, where many collaborators (among them potentially designers) work jointly to create and improve software.

The case against designing in code

There is no shortage of pleas and instructions for designers to learn to code. I argue that for the sake of better design, it makes little sense to do this work in code (at least for most designers).

To use code as a tool for design, ideation, communication, and adjustments is a process that creates a lot of friction. It demands constant switching between the definition space – the code – and the outcome – the resulting appearance and structure.

Empirical research shows that feedback loops play a crucial role in creative tasks.¹ For designers this involves evaluating how a preliminary design looks, is structured, or behaves and then apply changes and see if the result is satisfying.² Look at sketching: You can quickly draw what a product or a website may look like. You evaluate what is good or bad about the drawing, think it through and iteratively make changes The feedback is instant: if you slip and the crooked line messes up the design you see it right away. If the slip actually adds something good, you see it too.

This instant feedback is what’s to lose if we always design in code.

But should designer ditch the resolution to learn to code? Not always. There are things that are best expressed in code: maybe a gesture or a new kind of menu. It will enable communicating your ideas to programmers and estimate the technical difficulties involved in implementation. But while design-in-code is touted to be the skill-to-learn for (web) designers it shouldn’t come with the loss of core thinking models and processes for many designers.

So rather than learning to code for designing, you may be better off keeping design a visual process and learn to program for communication and realization of the design.

Collaboration: Text based tools are not silver bullets

There are many well established means to communicate in (Open Source) Software projects: Mailinglists, IRC, Bugtracker and Git, an immensely popular version control system. For all of these tools, but particularly with git, you will find many pleas online that designers use it for version control and collaboration. In addition, they argue, there is little choice anyway if one wants to contribute to an open source project.

But while tools like Git and IRC are well established, they pose some problems for in design. These tools are primarily text based and visual assets need to be somehow linked or embedded. They are not first class citizens.

Communicating about layouts, icons or workflows is possible, but tedious. Images often need to be uploaded and linked. When talking about them, images need to be referenced by some ad-hoc-system, parts of the image need to be described to refer to them. The text-space is a weak substitute for the visual space the design happens in. A long winded, cumbersome communication is the result and ambiguities arise (with often participants in the conversation scrolling up and down long threads to reference designs). This contributes to the lack of participation and acceptance of designers in open source projects and contributes to the view that designing together is hard and possibly done best by a lone genius.

To enable designers to contribute to open projects it is not enough that they learn about code and technology: they need tools that match their workflow and enable them to collaborate with programmers. Just telling them to adapt is not a viable, design-thinking, solution.

If you like to support the creation of libre tools for (open source) designers, have a look at some of our ideas.

Donald Schön: Designing as reflective conversation with the materials of a design situation, 1992. ↩︎
»sketching provides a temporary, external store for tentative ideas, and supports the ‘dialogue’ that the designer has between problem and solution.« (Chapter 1, ›Design Ability‹) »…Drawing…gives the flexibility to shift levels of detail instantaneously; allows partial, different views at different levels of detail to be developed side by side« (Chapter 4, ›How Designers Think‹) in Nigel Cross: Design Thinking – Understanding how designers think and work, 2011. ↩︎

Read more on opensourcedesign.net →