Matt Farina

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.

The Church, A Place Missing The Mission

matt — Wed, 23 Sep 2009 13:10:25 +0000

Churches aren't like other organizations. I regularly hear about them being compared to non-profits, aid organizations, or other volunteer organizations. This misses the mark in a big way and I'm not talking about the God factor. Let me illustrate what I mean.

Take a homeless shelter. There are 2 groups of people at them. There are those who are there running the place, feeding people, and working for the mission of the homeless shelter. Then there are the homeless people that are served. This is pretty straight forward.

The mission of the church (Matthew 28:19-20) is to go and make disciples of all nations. But, if you look at the church staff they are typically interacting with Christians around activities centered on Christians (like worship). Of the non-staff members only a small percentage volunteer and most of the volunteer time is spent on activities like worship, bible studies, and other things that are targeted at members of the congregation. The rest of the non-staff members attend Sunday morning worship on a semi-regular basis. This is a majority of the church.

Notice the difference? The members of the church and what they do doesn't revolve around the mission of the church.

As a problem solver I've started to ask the question, how do we refocus on the mission and what that means to the lives of the members of the congregation? (Suggestions are welcome)

Talk The Talk

The first thing that came to mind was to talk about the mission. The old saying, "out of sight, out of mind" rings true in many of the churches I've attended or looked at. You don't see the mission when you see the church. The mission seems to be tucked away in a dark corner. Maybe the active members of the church see it as a no-brainer. In any case, we need to talk about it more. Bring it up in conversation. Talk about how we do this. Ask tough questions.

It Got Complicated

Where this gets more complicated is with the nature of people. If people hear something they don't like they will just go to the church down the street that tells them what they want to hear. Or, avoids the uncomfortable topics. If a church changes tone too strongly how will that affect the membership in the congregation? Many have the option of going down the street just a couple blocks to a place that has a self centered tone.

This is where I am at the moment. Wondering how to get the mission of the church in front of the church and getting people to listen and talk. It's something I'd like to see more churches try and do. How is your church doing it? Do you hear conversations about this often?

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.

Building Church Communities

matt — Thu, 03 Sep 2009 16:29:28 +0000

Have you noticed that many churches aren't really communities? Some claim to be communities and a handful actually are. But, many churches are actually organizations that look more like a business with a congregation consuming services and products put out by the church staff and a handful of active volunteers. This is a problem happening at my church and something many of the churches leaders would like to change.

But, It's Not A Problem At My Church!

97% of church growth in America is someone moving from one church to another. This is usually happening because the church they switch to has a cooler worship service, is more fun, or there are more activities for their kids. Doesn't this sound like products and services being consumed. This feels like computer users switching from a PC to Mac because it's cooler and slicker.

When you live in community you don't want to switch. If you are in a community of friends do you just get rid of them and take on new friends because someone else is cooler? I sure hope not. If you do you are likely labeled as someone whose using others. This kind of thing is not a trait people like to see for good reason.

So, when it shows up in our churches it's really a sign that the church isn't a community. When it's not talked about it even shows that community isn't all that important.

No, Really. It's Not Happening In My Church

When I was recently talking to someone active in my church she said there wasn't a problem in our church. That she didn't see it. The problem is, she is one of the active people producing the products and services others consume.

If you are one of the top 10% of active church volunteers or a leader in the church you don't have the same perspective as someone in the congregation at large. You might not even notice this trend and you might be living in genuine community with the other people doing the same thing as you. But, that doesn't mean your church is a community. A church congregation is all of it's members, not a handful.

Community Is Dead. Long Live Community!

In the United States (I can't speak for everywhere) community is a dying thing. We yearn for it and online social communities are popping up in batches. Yet, studies show that people have less real friends than people used to have. More studies show people (in general) are more depressed and disconnected. In a time when our communication tools continue to improve our ability to live in community is diminishing.

That means building a church community is going to be counter cultural.

Does It Actually Matter

This is a loaded question. Some might answer that is doesn't actually matter to them. I think of this question in a different way. Does it actually matter to God? The answer to this is a definite yes. Reading through scripture this is very clear. Look at 1 Corinthians and how God made us the body of Christ. Different people with different skills and gifts working together for the missing of the church. This is a community with a mission.

The Path Ahead

I'm not sure what the path ahead holds for the local church I belong to. This is really just the starting point as we discover our identity and what it means to be a community or not. Just like so many other things, we could fail.

As I continue to work in the churches community I'll blog some of the things I see, things that work and don't, and ideas we have.

Any Ideas

Since the church at large isn't very good at living in community there aren't a lot of good resources at doing this. Some of what's out there is trying to manage (in the business sense) community. This just doesn't work. Some other things talk about radical change. That usually kills a community. So, I'm looking for ideas. Ways to convince people to change. Ways to change the culture. Ideas on what the culture should look like. And, anything else constructive for that matter. So, if you have any ideas I'd love to see them.

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.