Breaking the Language Barriers Between Designers and Developers in Open Source Software
Before I got into the world of software development and programming, I was a Graphic Designer. In fact, I still semi-maintain [Purephotoshop.com] [pps] (which is long overdue for an update–one day). I find myself in a position today where I get much more enjoyment from programming. Along the way, I’ve had to deal with the fact that the software development process and the tools used are very much designer-unfriendly.
You won’t find a lot of Designers who consider Terminal or MS DOS an essential part of their workflow, but if a Designer plans on getting into Software Development they’ll need to get acquainted with one of them or find alternative tools that will allow them to work more efficiently with Developers.
Say what?
I believe one of the main reasons why Designers aren’t involved in more Open Source projects is due to the fact the language isn’t something we encounter in our day to day lives as Designers. I’m going to pick on the Typo project because I was once involed with it and I know Scott and crew are good sports ;-). Here is an extraction from this page describing how you can begin to contribute to Typo:
The Subversion repository resides at svn://leetsoft.com/typo, so checking out the current trunk can happen with a command like: svn co svn://leetsoft.com/typo/trunk
Already we’ve been told to hop on the command line. Is this the only way we can begin to contribute to Typo? Now let’s take a look at something developers will likely never hear:
Open the .psd file, create a new selection from the midtones, copy this selection to a new layer and give it a slight Gaussian blur.
Typo is only one of many open source projects or projects in general that suffer from not having active designer(s) on the team. Craig Fitzpatrick published a great article in late October entitled: “If you get 1 thing right in your application, make it the User Interface” and 37signals continuously talk about the importance of design, but yet so many open source projects have a hard time getting contributions from Designers and the UI and interaction of the application end up suffering as a result of this.
Some of these projects are fortunate enough to have a designer in the loop, but this designer will probably never achieve the level of outside help in bug fixing and enhancements that the development team will. When you have 5 developers and 1 designer on a team of 6 and then pair that with the contributions through patches to the code, the design of an application can quickly lag behind because the designer simply can’t maintain the pace of the development.
Reaching out to Designers
Although it may be a given to you that anyone can contribute to an open source project, it wouldn’t hurt to let Designers know how they can contribute and how to get started. There are plenty of tools available for OS X, Windows and Linux that allow Designers to steer clear of the command line when working with Subversion or other SCM systems.
Also, there are simple installers for an applications underlying technology that can allow Designers to get up and moving quickly. Here are just a few:
Ruby/Rails environments
- Locomotive (OS X)
- Instant Rails (Windows)
- One Click Ruby Installer (Windows)
Php
While we can’t fully render the command line useless for Designers, we can lower the threshold of getting started and offer alternatives that get Designers initially interested and involved. Once Designers take an active role in a project then it’s a safe bet to start introducing them to some of the command line knowledge they should have.
What’s your take on the situation?
Sorry, comments are closed for this article.
Justin is the Design Director for entp, the company behind Lighthouse, Warehouse, and Mephisto. You can check out his dated portfolio for a peek of what he's done.
-
Beautifully simple issue tracking and project management. With a beautiful Mac-like interface, email and subversion integration, Lighthouse is the perfect project management tool. We took the suck out of issue tracking.
-
Oct10
Best Practices For Cocoa and CocoaTouch—Invaluable tips from Cocoa developers.
permalink -
Sep25
Track House And Senate Votes On Twitter. I’ve put together a small script that parses vote data collected by Govtrack.us and posts to twitter.
permalink -
Jul28permalink
Protip: Color grep searches in terminal
alias grep='GREP_COLOR="1;37;41" LANG=C grep --color=auto'Stash this away in your Z Shell (~/.zshenv) or Bash environment (~/.bashrc) and set your preferred ANSI code.
-
Jun08
ActiveRecord Ported To Objective-C brought to us by Ninja Kitten
permalink -
May06
With the release of Opera’s DragonFly, IE 8’s Developer tools, Safari’s/Webkit’s Web Inspector and Drosera; and the Grand Daddy of them all, Firebug – we’ve now come full circle.
permalink -
Feb08permalink
DoubleClick and Define using Apple Dictionary
var selection; if(window.getSelection) selection = window.getSelection(); else if(document.selection) selection = document.selection.createRange(); document.observe("dblclick", function() { if(navigator.userAgent.include("Macintosh")) { location.href = "dict://" + selection; } });A quick (and probably dirty) Prototype-based hack allowing Mac users to get the definition of any word by double clicking it.
-
Feb08permalink
Object.extend(Date.prototype, { strftime: function(format) { var day = this.getUTCDay(), month = this.getUTCMonth(); var hours = this.getUTCHours(), minutes = this.getUTCMinutes(); function pad(num) { return num.toPaddedString(2); }; return format.gsub(/\%([aAbBcdDHiImMpSwyY])/, function(part) { switch(part[1]) { case 'a': return $w("Sun Mon Tue Wed Thu Fri Sat")[day]; break; case 'A': return $w("Sunday Monday Tuesday Wednesday Thursday Friday Saturday")[day]; break; case 'b': return $w("Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec")[month]; break; case 'B': return $w("January February March April May June July August September October November December")[month]; break; case 'c': return this.toString(); break; case 'd': return this.getUTCDate(); break; case 'D': return pad(this.getUTCDate()); break; case 'H': return pad(hours); break; case 'i': return (hours === 12 || hours === 0) ? 12 : (hours + 12) % 12; break; case 'I': return pad((hours === 12 || hours === 0) ? 12 : (hours + 12) % 12); break; case 'm': return pad(month + 1); break; case 'M': return pad(minutes); break; case 'p': return hours > 11 ? 'PM' : 'AM'; break; case 'S': return pad(this.getUTCSeconds()); break; case 'w': return day; break; case 'y': return pad(this.getUTCFullYear() % 100); break; case 'Y': return this.getUTCFullYear().toString(); break; } }.bind(this)); } });UPDATE: Bugs fixed. Thanks Andrew and Stephen
Also, some of my old and new code has been posted on GitHub. You might find something useful.
-
Feb04
A beautiful, organic animation by Flight404 created using Processing.
-
Jan08
Aaron Patterson shows us how to define ruby methods which can be called from JavaScript using RKelly.
permalink -
Jan07
Dustin might not surprise you at your house with a book in hand, but he’ll damn sure send you his innermost fu in the form of a shiny yellow and black book. It’s an excellent read if you’re looking to put more funk in your functions and class in your classes. Check out “Pro JavaScript Design Patterns” by Dustin and Ross Harmes.
—I’m Justin Palmer and I approve this message.
permalink -
Dec23
IE 8 PAsses the Acid 2 Test for those not keeping tabs on things.
permalink -
Oct24
Mislav has written up an excellent overview on upgrading Radiant (which used 1.5) to Prototype 1.6. The article does a great job of showing how 1.6 is superior to 1.5.
permalink -
Oct19
According to the New York Times, the Daily Show Archives, with over 7,000 videos are online—free and searchable.
permalink -
Oct11
-
Oct10
—Erik Kastner shows us how it’s done.
Ninja Certified Copyright © 2005-2008 Justin Palmer | Powered by Mephisto
Discussion
I’m not clear on what part of the project you are saying designers should contribute to.
If you’re saying the entry barrier for them to contribute code is high then I agree. Though I’m not sure having a designer contribute code into subversion is what you want anyways.
If you look at the code for many open source apps written by average programmers it is pretty ugly already. And they are /supposed/ to know how to code. I don’t think having a semi-programmer submit code is a good idea.
If you’re saying it’s hard for them to contribute design details, layouts, interface improvements, color schemes, etc… using subversion then I also agree. But source code control wasn’t meant for something like that.
Maybe a good interface for designer contributed items is a good idea. Something that isn’t source control, though it would be similar in concept.
All I’m thinking is that it’s best for the programmer to implement the design. And the designer to design. They shouldn’t be stepping on each others toes.
I think a lot of programmers devalue designers and what they bring to the table, however I do see some of that changing. In my opinion, you should always develop your interface and user experience and then develop a codebase that supports that, but the problem lies in that the people starting the open source projects are usually programmers. They are mainly concerned with getting something funcitonal.
I think open source developers should first want to seek the help of designers and then provide an easy and understandable means for them to contribute.
John, the thing is that designers must be part of the team that contributes to the code-base. When I say ‘Designer’ I’m talking about more than just shiny buttons and graphics. CSS, HTML, Interaction, Usabililty; All are vitally important. Design is an ongoing effort, not a 1 stop solution that will work throughout the entirety of a project.
I use the term Designer here loosely because in small teams, labels can be deceiving.
Designers should be just as much a part of the project as developers, they should also contribute in that manner to and not through some filtered system.
If I had to clarify every design change with the rest of the crew at JadedPixel and have my changes submitted through them it would probably cut back on our productivity significantly and maybe even have some of the changes put on the back burner.
I’m positive Tobias wouldn’t want me giving the o.k. on his database schema just as much as I wouldn’t want him giving me the final o.k. on something with the U.I. Of course I’m not getting at the fact that you shouldn’t collaborate and compromise, but there need not be any baby sitting.
It’s definitely not best for a programmer to implement design, programmers with no design experience should probably never come close to touching the design. Thats why there are so many bad interfaces in open source now, programmers having to play the role of the designer.
Designers are just as competent as developers and it would be insulting to think that our decisions and implementations have to be submitted through a filtered system, but developers can walk right through. When I talk about programs like terminal and the command line, I’m not getting at the fact we just would never “get it”, I’m stating that we are just not familiar with it in most cases, just as any developer would be if they’ve never had to deal with it.
Hey, thanks for kicking off the conversation!
On a side note: I enjoy reading your site.
I didn’t mean to assert that designers are not vitally important or a one time deal.
I also didn’t mean to sound like designers should have to be watched over and have a programmer OK their output.
I completely agree that designers should be involved throughout the project and should have full reign over the useability , design, etc.. of an application.
I do think that a programmer should take the design and implement it though. If that person is also a designer, the so be it.
I really think that there should be a better way to introduce, share, and collaborate on design rather than using subvesion or code.
Stephen, you hit the nail on the head. “People starting open source projects are usually developers and want to get something functional.”
I’ve never really noticed an Open Source project (web related) that was started by a pair of designers, I’m sure one exists some where but it’s rare. I remember this got a lot of buzz: Designer CMS on Rails, but I’m not sure what came of it.
Programmers/Developers will almost always win out over designers in an Open Source project and design takes a back seat to functions and new features.
Getting back to the Typo project, you can see how the design has gone south in the fact there are numerous tabs across the top that have no reason being there. Typo is about publishing content, but iTunes meta-data took precedence over correcting the design flaws that make it a better application for publishing content.
I don’t blame Scott and crew though, they just don’t have an active designer who can raise these points and help correct them. It’s hard to fix something that you never see as broken.
Hey John, great to hear you enjoy the blog. Don’t take me to seriously, I enjoy a good debate ;-).
In regards to your statement the programmer should take and implement the design, you have to keep in mind that design isn’t just the icing on the cake that you can apply in a sheet fashion, it’s continuous integration; It’s just as much part of the cake itself as the application code.
If you put yourself in the role of the user, when you first login to an application are you thinking about how cool the recursive array tag cloud sorting code is or are you thinking about “why is this button here and not there”, “Why does this page redirect me here”, etc.
My point is that design is much more important to a user than application code, but both are equally important when it comes to the application itself. On that note, I have to stress reading “Craig’s article”: http://uncommonsenseforsoftware.blogspot.com/2005/10/if-you-get-1-thing-right-in-your.html.
very insightful posting. thank you for that. it certainly had to be said! (sorry my comment is not really useful but i can’t contribute that much as i think you stated exactly my opinion on that topic.
there is need to make the entry step for designers as easy or at least almost as easy as the entry step for coders to contribute to a (open source) project after all the interface is what the user sees first.
I’m on the programming end of my company and I get the luxury of working with really good designers. In the past I have had to teach them how to do some of the more technical things, but they enjoy jumping right into the project and making changes to the design.
This past Friday, I introduced a designer to Rails. I gave them a whole overview of how everything works, and turned him loose on the views. He quickly adapted to it.
And it sure is nice to have them working with the views while I can focus on the real guts.
Justin – I know the designer-oriented CMS RailFrog made the rounds for a while after being metioned on Stylegala. Currently their site is down – maybe the project is as well…
I had signed up to be part of the UI team on RailFrog but after months of no action in their forums (they use the free version of Basecamp to manage the project) I gave up. There was a lot of arguing and debate about structure, check-ins and process – with little to no commentary on the interface, which is arguably where they should have started. Finally, the Project Manager appeared to be overly sensitive to negative feedback. Not good.
Perhaps it was doomed from the start…
My old company disolved this past year before I started a new one that focused soley on web applications. The old company designed a CMS that was to be implemented by designers and used by normal users.
We started with the design first and the project was never 100% completed. I’m thinking of starting a open source project with the branding and design that we have already done.
This would basically be a CMS with heavy emphasis on user experience. I think there is currently a real need in this area.
http://sevenlight.com
I think in the past it has always been a struggle to have a good balance of form and function with a website. The developers want to get something that works and is functional, and the designers want to make it all look pretty. There seems to be a great chasm between the two in regards to communication.
I am currently in the process of building a new site where I work. I am responsible for the framework, and marketing will control the content. Thankfully, the design was done by the guys at Clear Function (see Stephen above), and they did a tremendous job of giving us a new image. It was great working with them on the project because they understood both ends – this is rare with many designers. Many (not all) want to make something flashy (which in the end isnt standards compliant, breaks things, and doesnt work well for integration or upgrades).
I think it takes work on BOTH sides. The developer needs to understand the message being sent by the designer, and the designer needs to understand the logic/development of the programmer. When you can understand each other it helps to build a successful website.
Also, I think a big part of all of this is EDUCATING. Some of the designers I have spoken with (That previously did print design) don’t understand the medium (web/browser). They get over-excited by the possibilities without thinking through all of the implications for the end user.
We (designers/developers) need to constantly be learning and seeking to be true professionals with what we do.
I love the shoe-on-the-other-foot thingy about designers telling techies to do the gaussian blur thing hehe.. I’m not a hard core developer or anything, but that kind of a comment from a designer would definitely enrage me (and quite a few techies like me) beyond all propriety ;)
But it does put things in perspective. Excellent article!
By this time on the computing progress timeline, we should have been in a world where the designers could sort of “draw” the app, and the code-artisans could put it together. Kind of what happens in the Architect – Builder relationship in the bricks/concrete world.
I wonder how it would be if one were to build an “open source building” lol :)
At some points, open source endeavours will have to start looking for UI/designers, project managers, operations people as part of the initial team, not as an afterthought. But until then the scratch-yer-itch type approach will get these projects started. The mindset will have to change before designers, project managers, even philosophers are given their proper place at the open-source table.
Think Tim the Toolman Taylor without Al!..hehe
Stephen – I also have a side project going for a CMS. Currently I work on it in my free time to both remedy the issues I had with the Purephotoshop.com CMS and it also gives me the opportunity to dig even deeper into solving problems with Rails. It’s still very much in the initial stages, but it gives me something to do instead of watching the History channel all day ;-).
Nate – Good points, it is indeed good for both sides to have a working knowledge of what each other has to deal with. When I’m thinking about design decisions, I’m also thinking about how they will affect the developers as well. Designers should also have a working knowledge of the constructs that are used in templates that tie the frontend to the backend. I wrote a similar article discussing these points further back in May.
Give me a break. Stop with the generalizations. All a good UI/UX designer is interested in is building an interface that’s usable, simple and elegant. It’s not about looking pretty.
That’s like me saying that all developers care about is how many lines of code they can write. Quality doesn’t matter, as long as there is lots to plow through.
Justin – very observant post.
I also started life as a designer, and I think the lack of attention given to design issues is one of the biggest problems with many OSS projects.
This goes beyond just eye candy as well; many open source projects are afflicted by poor usability, suboptimal documentation, and other artifacts which betray the lack of non-programmer input.
Side note: good designers can also frequently offer good alternate points of view on things apart from pure visual design; UI design and overall program layout are some of the more obvious cases, but not the only ones.
And the problem you’ve written about extends beyond designers to all non-developers who could make a contribution: UI gurus, technical writers, information architects, and many other flavours of potential contributors are likely to be scared off by the idea of learning subversion or a host of other things mandated by many OSS projects.
I’m frequently shocked that many (most?) mature sourceforge / equivalent projects neglect to even include a single screenshot for their project.
I also think part of the success of Rails is attributable to the Rails team avoiding many of these pitfalls. Part of this was giving the project a compelling look, complete with tidy site designs, intro movies, and the like, helping the outside world form an immediately favourable impression.
Many open source projects/developers are actively user-hostile/designer-hostile. I’ve tried to help a few web applications (most notably Drupal) out with usability and design in the past, and with the exception of one or two friendly voices, I’ve gotten mostly silence or actively hostile reactions to my “stupid” questions about the project. (Even though their code lacks documentation, no less.)
That’s one of the nicest things about the RoR community. Everybody seems to value design in some capacity.