17

Roy — Mon, 15 Jan 2018 21:34:28 +0000

Sub title

years of Drupal

/sites/default/files/styles/large/public/20180115-17.png?itok=5WAijQuS

Drupal is 17 years old today. Quite an achievement for a web software to stay around, let alone stay relevant for such a long time.

I’ve been around for 12 years. Quite a stretch as well. Getting involved in this open source project as a designer has taught and brought me a lot. I put quite a bit into it as well.

I get a lot of benefits from things I learned in Drupal that I can apply in other contexts.

Provide rationale for design decisions. So much typing in issue queue comments!
Help people see the other’s point of view and then come to a shared decision.
Or agree to disagree, then still make a choice.
An appreciation and at least a “gist of things” knowledge of the complexity of software development. It helps with clarifying scope, finding a good place to start, and understanding what is difficult and what can be relatively straight forward.
Pragmaticism over purism
Edge cases are important
There’s a difference between patience and stubborness
Accessibility, multilingual, extensibility, modularity are hard but worth it
If you can’t imagine why somebody would want do do X, it’s always from a lack of imagination from your part
There’s always so much more to do
There’s only so much you can do
When you start taking things personal it’s probably time to take a break
It’s amazing what people can get done when driven by a passion for doing a good thing and doing it well.

… and many returns!

How to make design in open source happen

Roy — Mon, 26 Jan 2015 22:36:48 +0000

Sub title

Two rough draft lists.

Designers that want to get involved in open source projects:

Don’t burst through the door and start yelling that you’re all doing it wrong. That might be true, but things were not made to suck on purpose.
Instead, ease in. Find out where the daily conversation happens. Join and start asking questions. “Why is this working like this?”
Usability tests are an ideal way to show which things need improvement.
Write a review of the software. Highlight what you think works well and what could be improved.
Have a user centred process. Stick to it. Show the work, take people along on the journey towards a solution.
Small teams get things done. Take in all the feedback, pick out the useful bits but stay true to your vision.
Have a vision.
Make sure you care. But not too much.

Open source projects that want to involve designers:

Not only code is gold.
Design is not the surface layer over a bunch of code. Allow people to dig in, have some patience with what may seem like silly questions.
Do you know who the software is for? And what those people want to achieve with it? The answers to these two questions are required foundations or effective design can not happen.
Ask for reviews from your users (or: which support questions keep popping up in your bug tracker?)
If every feature is important then nothing is important. Design is about making trade-offs, so prioritise. Making this thing easier to do will make those other things less obvious.
Interaction designers create the different paths through the software. Information architects organise and structure the necessary words, sentences and other content objects. User interface designers make things look consistent and create the right visual hierarchies. Usability specialists will show you what your users experience. What kind of design expertise would your project benefit from most?
Be prepared to write the code that implements somebody else’s ideas.

Yup, plotting my FOSDEM talk in the open :)