Matt Farina - Technology

Conference Season

matt — Tue, 23 Mar 2010 15:59:37 +0000

Conference season is again upon us and this is the time of year I'm usually planning trips with brewing excitement. But, with the birth of my first child happening right in the middle of conference season I'm bowing out of all of them this spring. So, instead of writing about the conference I'll be attending here are some I would have attended if I wasn't already busy.

Drupalcon San Francisco

Drupal is in the process of drastically improving and on the verge of releasing Drupal 7. Drupalcon is the conference to learn from the best and network with the best. Since I build Drupal sites for a living this is a place to make some great friends, learn what's going on around the Drupal community, and have a lot of fun.

And, for those of us working on core Drupal it's a great time to sit down together, work out where we go next, and have most of the other core developers who we might want to pull into a quick conversation sitting near by.

Dynamic Church Conference

A lot if changing in the world of ChMS and a lot has been going on this year. APIs are part of the package for the first time this year. The Dynamic Church Conference is a place to dive into what's changed with the leading web based ChMS, Fellowship One.

Tek (PHP Conference)

It is so easy to become stagnant in my skills as a developer. Following the "Drupal Way" will often time leave me missing out on great patterns, ideas, and resources others are using. Staying in the Drupal community for my education in technology would leave me greatly lacking.

To keep learn from others I would have attended the Tek conference. It is fairly close to where I live and would provide a great opportunity to communicate with and learn from others who are not in the Drupal community.

Barriers To Entry To Contributing Themes

matt — Thu, 01 Oct 2009 16:30:15 +0000

It seems the issue of a lack of good available themes for Drupal has really come to the forefront this week. Not only have Todd Nienkerk, from Four Kitchens, posted about the problem and Morten posted a CVS Haiku but, we have lost countless hours in Design for Drupal meetings and IRC talking about this. One thing seems for sure. As Leisa Reichelt points out, the current drupal.org setup to contribute a theme has a high barrier to entry.

Commercial Themes vs Contributed Themes

Todd brought up an interesting point on the Drupal ecosystem and commercial themes. Joomla has a commercial ecosystem that has been able to sell themes and make money doing it. The Drupal ecosystem has seen this in limited fashion with companies like Top Notch Themes. But, this doesn't have anything to do with contributing themes to drupal.org as that is not the place for commercial themes.

Is the issue one of getting a paid reward so even decent free themes don't have a place? Wordpress and Joomla both have good, or at least decent, free themes. Shouldn't there me a place in Drupal for that? When I looked outside drupal.org for a theme for my blog I quickly found some options that were better than what I found on drupal.org. Why weren't these free themes on drupal.org? The barrier to entry was too high.

Barriers To Entry

Contributing a theme to drupal.org isn't an easy process. While the process could use some good UX study there are some things that are fairly obvious barriers to entry.

CVS - The current setup where you are required to use CVS and tag things in a certain drupal way is a barrier to entry to many themers. Most of them aren't the kind of people who love popping open the command line. They like nice and easy to install GUIs and, quite frankly, they don't exist for CVS. This raises a lot of questions to what would be a better way. What about the SF way where there are file downloads and VCS which are separate? I don't know the answer but I have worked around the front end drupalers enough to know this is a problem.
The GPL - Legally speaking images and CSS files don't have to be shared via the GPL. They are served by the web server and are not derivatives of drupal. Many great website themes (like the one this site is running) have parts of it licensed under Creative Commons, BSD, and other licenses. The drupal.org CVS policy is that only GPL stuff can go in there. This is a barrier to converting designs to drupal themes, using some great icon sets, and so much more. I'm sure what to do here (if there is anything). It is something we need to acknowledge.

I know there are other barriers to entry to contributing drupal themes. I'd really like to see this studied on a deeper level and maybe see some experiments setup to try and drive up the contributions. In any case, the setup on drupal.org has barriers to entry we can work on.

Design 4 Drupal: Building Their Own Home

matt — Wed, 23 Sep 2009 14:19:05 +0000

It's time for the Drupal web designers and front end developers to have their own home. This is the message coming across loud and clear at the moment.

Drupal.org was built for back end developers, programmers, and the community at that time. Over the years it was architected around those users and their needs to build a great product. But, times have changed and we have users with different needs. One group looking for their own place and set of tool is the web designers and front end developers. It's time to build it.

Back at Drupalcon DC we started to talk about what the need would be. We started a group on groups.drupal.org to get the conversation going. But, the groups system wasn't really built around the needs of the design for drupalers. It grew quickly but became stagnant. What was really needed was 2 things. A project management tool to manage the tasks of the group and a home built specifically for front end drupalers.

Project Management Site Up

After months of talk at conferences (like Design 4 Drupal Boston), conversations in IRC (we converted some front end folks to use irc), and on twitter a project site was finially setup to start manageing what needs to be done. Eating our own dog food, this is an Open Atrium site at http://project.designfordrupal.org.

If you want to be in on building the next place for web designers and front end developers please come join us here.

A Home For Front Enders

One of the first tasks is to figure out what needs to be built into a site for front enders. My hope is that this starts with a bit of a discovery phase to figure out what's needed and then we can build it. Much of that work has been done at conferences, in back rooms, and in IRC. Now we just need to gather our notes and get feedback. This is the top priority for the group at the project management site.

So, if you're interested in building something better for web designer and front end developers please join us at http://project.designfordrupal.org.

Themer vs. Designer - Choosing A Name

matt — Wed, 16 Sep 2009 11:43:00 +0000

The Drupal ecosystem has created a new title and job you don't find elsewhere. That job is of a themer. The name is built out of the Drupal theme subsystem. When we have had discussions regarding who the theme system should be built for or when we have talked about who the design for drupal movement is for the discussion has often turned to a conversation discussing a themer vs. designer. The problem is, for the theme system there is a better target than either of these and one the web development community at large will understand.

Front End Developer

The title of Front End Developer is used all over the Interwebs and the web development community. That is, except in drupal front end conversations.

Front end developers is a group that has been well defined and hashed out over time. There are front end developers working for SAAS companies, web application companies, the other open source projects, and all over.

Bonus Material

As a bonus, if we start adopting the Front End Developer terminology other people who do that around the web will start to better understand what we are talking about. Their google searches will return Drupal goodness in the results. They'll better see that Drupal is for them.

So, let's drop the name themer and the debates about themer vs. designer. Instead let's use the common term Front End Developer.

Scaling The Core Development Process

matt — Tue, 15 Sep 2009 12:46:45 +0000

For many years the Drupal core development process has served us well. With Dries and a co-maintainer committing the changes of the community we have crafted a product we love and hate to use and a community we are involved with. But, the success of Drupal is stressing this 2-tiered development system. After talking to numerous leaders in the community here are a few suggestions as to how we can scale this system and relieve some of the stress for Drupal 8.

The Strain

The Drupal community has grown in size and the Drupal core package has grown in size and complexity. For anyone now sure what I mean just download Drupal 7 and compare it to Drupal 5 or 6. In many ways I think all this new stuff in Drupal 7 is good. But, we now have two big stresses.

First, the community has grown in size. Drupal core has hundreds and hundreds of contributors. Angie has done an incredible job being accessible to people who need to talk about core development. But, hundreds of developers is a lot of cats to herd. Even with Angie being online 24 hours in a day (is she really a robot) there are core developers who feel like they need more support from a core committer. In some cases their concern is very valid. There are a lot of areas to support, which bring me to my second strain.

Drupal has gotten a lot more complex. The subsystems in Drupal core (like the database layer, theme layer, etc.) are in many cases the same size and complexity of other open source projects. The core committers need to spend time working in all these subsystems and with so many of them that is a lot to cover (especially with day jobs and loved ones who need time). While they have worked really hard to do this and have tried their best there isn't enough core committer to go around.

We have ended up with a lot of passionate, frustrated, hope filled developers.

Easing The Strain

To ease the strain here are 3 suggestions. In good open source spirit I hope others will build upon them and create something better.

1. More Core Committers

For the sake of my examples here I'm going to use the front end developer community. It's a nice functional block.

Add core committers for different functional areas. So, add a core committer for front end development. This person would do core committer work for the theme system, JavaScript and style handling, and other front end related aspects of Drupal core. The duties of this person wouldn't be to just work on these systems but to keep a birds on view on Drupal core to know how changes in one system are interfacing with others.

The person responsible for this functional area should, also, be an expert on that functional area and someone who isn't trying to implement their system and way of doing things. I am not looking for the role of core committer to really change.

2. Top Level Overviews

Drupal is known for not having a road map. In many ways this is great. It means that anyone new coming in with a great idea can chase it. We need to keep that open. But, road maps do have one nice thing. They provide a top level overview of what's happening. There is no nice place to find that in Drupal and trying to figure that out for yourself in the issue queues is daunting.

I'd like to see a top level overview of what's happening in Drupal. Ideally those in the Maintainers.txt file alongside the core committers would keep and eye on what's going on and update the overviews. We could even start this now by breathing new life into the Community Initiatives.

Making these top level pictures of what's going on more easily available will make it easier for people to find what's going on.

3. Create Pictures of Where We Are Going

Some recent initiatives, like d7ux and the new database layer, have shown that if we look at more far reaching changes and what they might look like we can come up with some great ideas. Lets do more of them. To do this well we need a place to virtually do this and share what people are doing with others.

For example, we could list the "ideas" for the Drupal theme system on the theme system overview page. These could link back to an idea incubator where they are hashed out in a constructive information gathering manner.

Time For A Change

These stresses are a good problem to have. They are the result of success and growth. Just like so many problems we've come up against in the past we can tackle these.

My Bazaar Core Development Workflow

matt — Fri, 28 Aug 2009 13:08:18 +0000

My old Drupal core development workflow revolved around CVS. Anytime I'd want to work on a new feature I'd do a CVS checkout of Drupal core and start working on the new feature. If I, or someone else, was working on 2 features that overlapped in code I would have to deal with massive conflict resolving or just have to wait until the other feature was committed or abandoned. Oh, and I had to be connected to the Internet to grab a new CVS checkout. That all changed when I switched to Bazaar for my core development work.

Some Of What I Can Do With Bazaar

Bazaar, a distributed version control system, let's me do a lot of things that simply can't be done with CVS or SVN. Here's a short and incomplete list:

I don't need to be connected to the Internet to create new feature branches.
Merges are much better making them useful. That makes branches cheap, easy, and useful.
I can make branches of other feature branches allowing me to layer patches and issues.
Did I mention merges are better. This means a lot less conflicts to deal with.

Setting Up Bazaar

Setting up Bazaar in fairly simple. You can do it with installers, through your favorite distribution os Linux, and with Macports. Once you have Bazaar installed there are two great places to look for how to setup Bazaar. First, there is the drupal handbook pages on the topic. Then, I would recommend reading David Strauss blog post about setting up a Bazaar repo of drupal head.

But, what about Git?

Yes, you can do the same things in Git and Mercurial. They are great distributed version control systems as well. I'd suggest Bazaar as a first choice because that's the direction the drupal community is currently leaning.

Leading In The Face of Criticism

matt — Fri, 28 Aug 2009 12:37:09 +0000

How do you react when your pet project is criticized? How about when a project you use and love is criticized? When it's the same criticism you've heard over and over you and are tired of hearing it? That's happened yesterday to the Drupal Views project when a tweet sent out of frustration turned into a swarm of tweets, IRC conversations, and back room talk. For the most part, the situation could have been handled better by everyone involved.

What happened?

Let's just say quick reactions, emotions, and defense mechanisms ruled the day. In the end I don't think anyone was satisfied and I have yet to see anything constructive come to light. There was name calling, anger, people trying to defend themselves and others, and a mess of unproductively.

What We Can Do Better Next Time

This situation could have been handled much better. Instead of acting the way many did with passion, frustration, and emotion the criticism should or could have been molded into actionable tasks and ideas.

Here are a handful of things we can do that can help these situations:

Don't respond to your emotions. It may be hard to do. Sometimes I will walk away from the situation for hours or even a day before responding to something so I can do so with a clear head.
Turn the criticism into something constructive. This could be as simple as pointing someone to a place (like the issue queues) and asking them to describe the problem and what they see would be better. If you have more time it could be good to engage the conversation to see what they see.
Be a diplomat. For some reason the role of attaching and defending soldier comes so naturally. Instead, play the role of diplomat.
Ignore Them. Sometimes it's better to ignore criticism and move on than let it get to you. If it eats you up that can make you unhappy and can even cause health problems.

Critics Not Going To Stop

One of the responses I heard numers times was that critics need to act different. If we create something with any popularity it will have critics. They will be there no matter what we desire. And, the only people we can change are ourselves. So, asking them to go away or asking them to act differently just isn't going to get them to do it.

People Smarter Than Me

A while back there was a Google Tech Talk called "How Open Source Projects Survive Poisonous People" which touched on this subject. It's done by a couple guys who have lived and learned how to deal with these situations successfully. You can see the video below.

Disclaimer: This post isn't directed at anyone. I've learned a lot of these lessons the hard way and just want to share them in the spirit of community growth.

The Horror of Views Markup

matt — Thu, 27 Aug 2009 12:35:17 +0000

Every so often someone points to the markup generated by the Drupal Views modules and calls it ugly. This seems come up every so often in the forums, issue queues, blog posts, and on twitter. Most of the time this is where the conversation turns a bit ugly. Since this conversation has been had many times the people who are involved are a bit tired of explaining what's going on to someone new and to many Views is their baby and it was just called ugly. So, let me take a shot at explaining why Views markup is the way it is, why that's good for some, and what you can do about it if you don't like it.

The Deal With Views Markup

The markup from Views has to be very flexible out of the box. It's going to be used by a lot of people to do a lot of different things. So, the markup provides spans, divs, and classes for almost every case you'd want to style. If you are someone who lives in CSS and loves classes and separation of everything it's there for you. There is a certain group of designers that want this and they have been vocal and are, for the most part, happy with the markup.

Can't Make Everyone Happy

As the saying goes, you can't make everyone happy all the time. Having lots of spans, divs, classes and other forms of markup is directly opposed to small concise markup others love. You can't have both out of the box and what Views picked is actually easier for new people to pick up.

In Drupal to alter the output you need to know how the theming system works and how to override the default markup. Since Views provides lots of markup many people can learn to style the output without needing to know how to alter the markup output of views. It saves them from a layer of complexity.

Having Markup Your Way

If you are a markup purist and want to change the markup output by Views it's there for you to change. Views uses the templating system provided by Drupal and has a display plugin system of it's own. With the templating system you can override all of the markup provided by Views and replace it with your own. It's almost as simple as copying the Views template files into your theme and altering or replacing them.

Drupalcon Paris

As Morten does at the Drupalcons he attends, in Paris, there will be a session about overriding the default markup in Drupal to replace it with what you want. If you're not going to make it to Paris you can wait for the video from his session to be published or check out the video of his session from Drupalcon DC.

Drupalcamp Boston Wrap-up

matt — Tue, 16 Jun 2009 14:09:15 +0000

The Drupal Design Camp in Boston this past weekend was fantastic. Having the event at the MIT Stata Center, a building that looks like it's right our of a Dr. Seuss book, was a perfect place for a design event. With well over 150 people, loads of fantastic sessions, and ideas for improving the tools and community designers and themers have the camp was a roaring success.

Photo by Jeff Eaton. Everyone is pointing at Morten.

The People

There weren't just people attending from the east coast or midwest and Morten wasn't the person who traveled the furthest. There were people from Texas, the Bay Area, and Europe. From the looks of things the event was 1/4 women. Has there ever been a drupal event with this high percentage of women? There were new people and people with 2 digit drupal.org user ids. There were developers and there were a whole lot of people with the creative art gene.

The Sessions

More than one attendee said they thought the sessions here were better than at drupalcon. With keynotes by Jeff Robbins and Jay Batson and huge sessions like the one on the 960 grid by Nathan Smith, the creator of 960, and Todd Nienkerk it's hard not to feel this way.

The 40 session covered topics ranging from the basics of drupal to themeing techniques to radical new ideas in how to theme like skinr.

The New Ideas

In Jay Batson's keynote many of the back room chatter started to turn into things we can act on as a community. Some ideas that came out were to start a site for designers and themers, to have a way to deal with snippets (something themers seem to do well), to have a showcase of hot drupal sites (giving credit where due). These are just the tip of the ice berg.

The Stata Center

The Stata Center was the perfect place for an event like this. Every direction you look there's something inspiring and artistic about the building.

Photo by Michael Verdi

I want to give a special thanks to Susan MacPhee for organizing the event and MIT for hosting the event. It was fantastic.

An Overlooked Drupal Design Problem

matt — Thu, 21 May 2009 11:05:45 +0000

Most of the shared Drupal themes aren't very good and there aren't very many commercial ones. That's what a study shared by Jay Batson pointed out. Jay went on to propose some steps we could take to court better design in the Drupal community. While he made some important points, there is one important point that was overlooked. The issue of crediting designers for their work.

Hostile Land For Designers

Let's be honest. The Drupal community is a hostile land for designers. Drupal.org is nothing to look at (yes, I know that's changing). The drupal web tools, like api.drupal.org, are centered on developers. To contribute a theme you have to know and use CVS. At drupalcon dc designers and themers had to take over BoF rooms to get the space they need.

The Drupal community is anything but warm and inviting to designers. We tend to treat designers like we do fellow developers. We can't do that. They are different. It would be like buying my wife a vacuum for her birthday. Just a bad idea.

Crediting Developers

Right now drupal developers are credited in a variety of ways. If they contribute code there are commit messages. We even keep stats on that. Their contributed modules are tracked on their user pages and you can see how many sites are using their modules. If they contribute to core their usernames are in the commit messages and can get up on the big screen at drupalcon.

If you are lucky enough (is lucky the right word) you can get your name in the MAINTAINERS.txt file for Drupal so everyone can see your name on the project.

As you contribute you build up community cred with the other developers. You make friends. You gain influence.

Difference Between Design and Development

When a developer writes a sweet module, like Views, for a site they can share it back with the community for fame, reputation, and more. The case is quite different for a designer.

If a themer contributes back a base theme like zen, blueprint, or moshpit it's a reusable piece of code like a module. A full design is something you can't share back from a project. If I share a design from a site I've done and people use it my branding status is lowered. It hurts the effectiveness of a site.

So, designs typically can't be contributed back in the same way modules or base themes can be.

Difference between Designers and Drupal Developers

Drupal developers usually want to move up the Drupal Developer food chain. When they contribute back there is an ecosystem of Drupal developers for them to interact with.

This is not the case for designers. There is no flourishing design community. When they go to interact within the design world they do it with the design world at large. Designers aren't interested in having their name in a drupal commit message about a change in the code. They are interested in receiving credit for the design they worked on. Note, a design is different than a theme in this case.

One of the things the Drupal community needs to figure out is how to credit designers for their designs in a way that showcases it the larger design community. This is especially important for drupal core where the drupal 7 version has just 2 designs.

So, this is a call for ideas. How can we do this and do it in an effective way for the design community?

I want to give a special thanks to Leisa Reichelt and Morten for helping me understand this.