Friday February 6th 2015

Things software development teams should know about design

I wrote a quick, unpolished list of things that development teams should know about design (and designers). It’s worth sharing with a larger audience, so here it is:

  1. programmers and managers need to fully embrace design — without “buy-in”, designing is futile (as it’ll never get implemented properly — or, often, implemented at all)
  2. design is an iterative process involving everyone — not just “the designer”
  3. in all stages of the project cycle, design must be present: before, during, and after
  4. design isn’t just eye-candy; functionality is even more important (text/content is part of design too)
  5. designers are full team members (and should be treated as such), not some add-on
  6. design issues should have high priority too (if something is unusable or even sometimes looks unusable, then people can’t use the software)
  7. designers are developers too (in fact, anyone who contributes to making software is a developer — not just programmers)
  8. good software requires design, documentation, project management, community engagement, marketing, etc. — in addition to programming
  9. “usability” != “design”; design is about creating something useful (and/or pretty), whereas usability is discovering how well something works — usability tests are useful to see if a design works, but usability test alone usually won’t point a way to fix issues… design helps fix problems after they’re discovered, and helps to prevent problems in the first place
  10. a lot of designers are quite tech-savvy (especially us designers already in the open source world), but many aren’t — regardless, it’s okay to not know everything (especially about programming corner-cases or project-related esoterica)
  11. think about the people using the software as people using the software, not as “users” (using the term “users” is degrading (similar to “drug ‘users'”) and sets up an “us-versus-them” mentality)
Wednesday July 23rd 2014

GUADEC 2014 Map

Want a custom map for GUADEC 2014?

Here’s a map I made that shows the venue, the suggested hotels, transit ports (airport/train station), vegetarian & veggie-friendly restaurants, and a few sights that look interesting.

I made this with Google Map Engine, exported to KML, and also changed to GeoJSON and GPX.

If you want an offline map on an Android phone, I suggest opening up the KML file with Maps.Me (proprietary OpenStreeMap-based app, but nice) or the GPX on OSMand (open source and powerful, but really clunky).

You can also use the Google Maps Engine version with Google Maps Engine on your Android phone, but it doesn’t really support offline mode all so well, so it’s frustratingly unreliable at best. (But it does have pretty icons!)

See you at GUADEC!

Tuesday April 2nd 2013

New photos: plants, animals, shadows, and sculptures

I’ve started snapping and posting photos again.

With the exception of the zoo photos from last year, most of these are from the recent months. A few are even from the past week or two.

future reflections green and pink the frog kings not quite human orange-eyed snowy owl cat with boxes signpost of the shadows windows and shadow the Happy King
Angel in Infrared

You can view larger versions by clicking on each photo
or by visiting my photo collection at Flickr.

Tux update: black and white vector line-art

Many months ago, I released a high-quality vector version of Tux that I made in Inkscape as SVG and PNG.

Tux - color PNG previewSomewhat recently, I needed to make a black and white version for a project.

You can get both the color and black and white versions in both SVG and high-res PNG at the Tux github repository.

These versions of Tux are licensed under the public domain, but if anyone asks, Larry Ewing made the Tux mascot in the Gimp and I made these versions in Inkscape.

Thursday March 14th 2013

“Patches accepted” is harmful: How to improve your volunteer introductions

“Patches accepted.” It’s one of the most offensive things you can say to people who genuinely want to help with your project.

Why you should reconsider using the phrase

Not everyone is a programmer. Even those of us who do know how to program might not meet your expectations, and we would likely waste hours (or sometimes even days) writing and formatting a patch exactly how you might like it. And even then, we might be rejected again and again.

Instead: You, an expert programmer, could spend a little bit of time to thoughtfully discuss an idea and possibly consider implementing it. All of us who are better at things other than programming could possibly help you out in other ways too.

The pain of perfect patches

Developers often assume everyone should write perfect code in their project’s language, to their coding style (tabs? spaces? how many spaces? K&R? KNF? how many comments? what types of comments?). Thinking that everyone will send you free code exactly how you like it is not only arrogant; it dismisses other contributions.

Software is much more than the code that goes into it

Contribution is more than just patches; design, documentation, marketing, translation, localization, security audits, testing, discussion, and advocacy all are crucial for software to be good software.

“Patches welcome” ends any kind of meaningful discussion for potential other contributors.

Simple solutions: words & phrases

The words we all use matter. There are often special meanings in phrases we choose.

“Contributions are appreciated” is much better phrase to say than “patches accepted”. It’s not only what you say, though — it’s also what you mean, and we all need to shift our mindsets too.

The differences can be summed up simply:

  1. Be inclusive — people can help out in many different ways.
  2. Be thankful — everyone’s time is valuable, and they could choose to spend theirs doing something else entirely. Instead, they decided to talk with you and spend a bit of their time on your project, to try to help.
  3. Community participation is not only about code.

Sometimes you simply can’t work on an idea or fix a bug in your project due to various constraints, such as lack of time, being sick, or even a lack of skill. That’s okay; everyone has moments like these. If you’re up-front with people, they will likely understand and may think of you and your project more highly with the explanation. (Every once in a while, someone else may even see that there’s help needed and jump in because of your pleasant conversation too.)

Conclusion

If initial conversations are handled correctly, it could be the start of a beautiful symbiotic relationship to make your software better.

Wednesday March 6th 2013

Giving feedback

Lucas Rocha shared Seth Godin‘s blog post “the worst feedback is indifferenceon Google+, and I posted a reply.

In the interest of openness and distribution (and actually posting content on my blog), here’s my response:

I was on a call the other day where someone told me that they wouldn’t ever give me negative feedback. I replied: “No! Please give me negative feedback, especially if it’s constructive. Tell me when what I do sucks. If you can, please tell me why it sucks too. If it’s good or great, tell me about that too. Please let me know what you think.”

After working in the FOSS community as a designer for a decade and a half, one must have a thick skin. Us designers often produce highly visible things, sometimes with controversial ideas (sometimes for bad, sometimes for awesome).

I hope all of us in the community can work together and be respectful of each other enough to say when things produced (designs of any sort, code, documentation, etc.) might be good or bad… and also have the courtesy to point out why we hold whatever opinion we may have.

It’s important to have some respect for people when doing this. Even the most awesome people produce the worst ideas sometimes, and that’s fine. It’s all on the path to working together to make things better. We need to foster open communication whenever we can and separate the design from the designer, the code from the coder, the writings from the writer, the managing from the management, etc.

In other words, attack stuff within reason (either with negative feedback or attacks of awesomeness) and elaborate, but be careful not to hurt each other.

Monday June 4th 2012

New job!

I have recently left Novell / SUSE, after working at the company for eight years.

Today is my first day at Red Hat!