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.
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.
Mark Boulton and Leisa Reichelt have suggest drupal provide inline editing in the interface. This is a fantastic idea and one I would love to see in drupal. But, (I hate this part) inline editing in drupal is a difficult feature to add. So, before everyone wonders whey we don't offer it or why it's going to take some work let's look at why this is hard.
A new movement surfaced at drupalcon DC. It had been bubbling under the surface for some time and it came to a head when 1400 drupalers came together for a week. That movement is Design for Drupal or d4d.
Have you ever wondered where all the drupal designers are? It's easy to find a drupal coder. Drupal is full of coders doing some great things. But, designers are a lot harder to find and are a much rarer species. I would go so far as to call them an endangered species. So, what can we do get them off the endangered species list?
At Drupalcon DC we held a Birds of a Feather session to ask just this question. Just about everyone in the room was a designer. Below is most of the audio... but, be warned that is was recorded on the fly and my battery went dead with about a minute of conversation left.
This leaves me wondering where the designers go next? A first step is that there will be a room for them all day on Friday (Rm. 156) and Saturday at Drupalcon DC. Beyond that I hope those in the rooms can get a bright future started.
For nearly 4 years I've had the opportunity to be apart of the drupal community building sites, hacking together modules, and attempting to make core better. Being apart of the community has helped my skills grow, given me the opportunity to help others, and allowed me to work on some cool projects. This has been a lot of fun but, doing this on the side from my full time job as an engineer was no longer enough for me. Starting today, I'm a developer for Tree House Agency. Tree House is a web development company that builds most of their sites with drupal.
What this means:
When it comes to building sites and using tools there are loads of title and acronyms being thrown around. There's Rapid Application Development Tool, Web Application Framework, CMS, Content Management Platform, and more than a few others I'm missing. One of the names that stands out is framework or web application framework.
Have you ever submitted a url to a site just to have the site tell you it was invalid when you knew it wasn't. That happened to be recently and happened on one of my drupal sites. Drupal told me a flickr url containing an @ symbol was invalid. When I looked deeper into the issue I found the URL really was valid. When I looked to see what other software was doing I found many cases where there was no validation or what was present failed for many types of valid urls.
Most of the development to drupal core happens through a patch review process. Even bigger changes, like the new database system, where development happens elsewhere, eventually go through a patch review process. This process can be intimidating to anyone who hasn't done it before or doesn't feel like they have a high enough skill level to contribute anything to core. In reality, anyone can review patches. Even individuals who can't write software at all.
When we updated the Geeks and God podcast to drupal 6 we migrated away from using the audio module and are now using CCK and filefield to manage our audio. This has enabled us to use modules like filefield podcaster to generate our feeds and have views generate different feeds for our different file types.
The audio module has been good to us but we didn't need most of its added functionality and some things, like ID3 tag management, had turned into a little bit of a nuisance.
A number of other people have wanted to make the same conversion and I have been asking me how to do it more than a few times. So, I wrote up a tutorial called "Drupal: Converting From Audio Module To Filefield Module".
Hi, I'm Matt Farina. I am an electrical engineer/web developer and am blogging about tech, faith, life, science, and stuff like that. Read More
