Design, General, Open Source Goin’ ’bout things tha wrong way ’round?
I was trolling the internet tonight (I want a nice ajax-y image gallery for Drupal — thumbnails on one side, nice big picture on the other), and I came across this interesting article:
Project outline and UI Design for an AJAX-powered Image Gallery Module
Okay, let’s leave the fact that he’s using ’scribd’ aside… This presents a rather novel approach to problem solving:
Step 1: Acknowledge the existence of a problem and quantify it.
Step 2: Define the UI to solve the problem.
Step 3: Hammer out the technical side of everything, keeping the problem (step 1) and the UI (step 2) in mind throughout.
Step 4: Profit!
Okay… I just threw Step 4 in for giggles.
This is a huge issue in Open Source (I love my Debian box, but I gotta admit my Mac does things more elegantly…) and for Drupal specifically. Anyone who has used Drupal for more than about a month knows that it can do pretty much anything. (Make some toast? You bet. Just install toaster.module) The problem with Drupal is finding which particular switch, in which arcane location, is going to fix whatever problem it is that you have.
And let’s face it: Being nerds usually means that we fixate on Step 3 a lot more than we fixate on Step 2.
And yes, I prefer the term ‘nerd’ to ‘geek’. Ask me why some day.
Which brings me to the second bit of light reading for the evening, courtesy of the kind folks over at Smashing Magazine:
7 Essential Guidelines For Functional Design
Yeah, a lot of it is stuff we all know already, but it still stands as a decent reminder of how to get things done, and how to evaluate if we’ve succeeded in our goals.
Oh… and I eventually had to punt on the ajax-y gallery, and went with this one. Jury’s still out. I welcome suggestions.
Design, Open Source, Productivity Writing Drupal Themes
One of the many things that I do here is create custom themes for Drupal. It’s kind of an artsy thing, and since I’m the resident designer (or so it says on my card), I tend to be a bit artsy about it. One of the things that being artsy means to me is being off-site. The Innova office is a very cool space, but I like to have a change of pace every once in a while. A change of lighting or a change of atmosphere does a world of good.
But one thing that becomes a problem is remote access. Sometimes, I really like to get off the beaten path, and away from it all. I have a laptop, but I’m not going to be able to connect to anything when I’m sitting in the middle of a park. And even if I could, I certainly don’t want the lag time in connection, especially if I’m tweaking css. “Okay… just one more pixel to the left. Right. Save. Okay… Now I’ll go make a sandwich while that goes through the VPN.”
In be beginning stages, I like to do everything remotely. Most of the time, the client has only sent a spec, maybe some rough ideas about what they want the design to look like, and maybe some color ideas and or photos. Usually, I don’t have any content at all, besides a tentative site name, and I can’t sit around waiting for content.
To develop locally, and rapidly, I use MAMP (what do you want? I’m on a Mac). You can do the same thing with a windows machine, with a stack called XAMPP. It’s a full Apache-Mysql-php stack that you can kickstart whenever you need to, and can shut it down when you don’t. In short, I love the thing. I didn’t at first, but I didn’t like Drupal at first either.
Until I get content here’s what I do:
- I have two different setups: one for Drupal 5.x and one for Drupal 6.x.
- I keep two seperate databases: called drupal5 and drupal6. These databases contain only the most generic of content. It’s basically all lorem ipsum but it has the content that I expect clients to want (stories, pages, blog entries, etc.)
- Copy one of the stock themes in /themes to /sites/all/themes/projectnamehere. This keeps all of my new themes separate from the stock ones, and if this directory gets clogged (which it will after a few projects) it’s easy to offload the directory to somewhere else.
- I’m not usually trying out modules at this phase, but if I do need to, I try to keep them sequestered out from the stock modules and keep them in /sites/all/modules. That way, I remember that there are modules that I need to upload to the production environment.
And away I go. I can take my laptop anywhere I want, and I can sit down pretty much anywhere and get things knocked out pretty quickly.
Getting out of the office is often a great way to get things done. If I can work without a network connection (as I generally do when working as outlined above), it’s a great way to shut down a lot of the distractions. I can’t check the news. I’m not going to be pinged with IMs. I’m not going to be sidetracked with new mail. It’s a lovely world out there, so go out and get to work in it.
Open Source New Zend Framework is Out
The latest version of the Zend Framework is version 1.5 — their first major update since going 1.0.
We use the Zend Framework for almost of our applications here, and we recommend it to all php users who want to create applications that will scale well, follow an MVC architecture, and will be maintainable in the long run… So… For all applications that are actually worth anything.
You can get it via http at their site or even via svn:
http://framework.zend.com/svn/framework/tag/release-1.5.0
If you are interested in getting started with the Zend Framework, good resources exist, for example:
And their own online Docs are strong too:
General, Open Source Trying the New Drupal Out
Here at Innova, we’re not too particular about what tools we use to get things done. We use our own content management system, and our own development language (phpSprockets, which, by the way is still under development), but we also use some off the shelf solutions, like WordPress or Drupal, based on our clients’ needs and expectations.
So when a new major release of one of these tools that we use comes out, we get pretty excited. Hence, a post on Drupal…
Drupal 6 just came out earlier this year, released with much anticipation and trepidation. I’m kind of a late adopter (usually), but I welcomed the new with open arms.
I’d been following the development, as I’ve been maintaining a couple of Drupal sites, and trying to keep up with patches and upgrades (not that bad, really, averaging a new version about every two months.) Everything is running pretty smoothly, although the stream of modules is lagging a bit behind where I’d like to see it.
If you’re new to Drupal, here are a few pointers –
Start small. It’s tempting with as many modules and themes that Drupal has to just start grabbing modules everywhere and installing them to see what they do. This is a really bad idea. Not only will it slow down your learning process, it will also become a maintenece nightmare — you have to keep up with the patches and new versions (and no, you can’t just svn up or switch them…). It becomes a real hassle, not to mention a drain on server resources.
Get a couple of core modules that you really like and stick with them (Here’s one of my favorites: Markdown with SmartyPants. If your users don’t know Markdown, they are missing out… ). Drupal is extremely extensible (most blocks when you are an administrator will accept php code in the body… once you learn the internals of the database, this becomes very powerful…)
Have some regular housekeeping protocols — not using that theme/module anymore, get rid of it. Keep up to date with the ones you’re keeping. I have had several instances where a client complained about something not working properly, and just updating the module fixed the issue. Lots of things happen between Drupal versions (and minor versions). Keep up to date the best you can.
Keep telling yourself, “There has to be an easier way.” There usually is. Most of the things that people need a CMS to do have been done. If you are really so cutting edge that it hasn’t been done… Write a Drupal module for it, release it, become famous, and impress your friends. You need an AJAX tea timer? I’m sure there is already one out there somewhere…
Open Source .NOT
One of Innova’s stock monologues to deliver to clients is “PHP is an excellent development language.” It’s true: PHP with the Zend Framework is the most flexible and reliable way of creating sites that I’ve ever seen. It’s a win. The reason we have to keep delivering the monologue is because clients - or people who advise clients, such as corporate IT drones - often have an unhealthy respect for Microsoft-based solutions, specifically .NET. At some point in the last ten years Microsoft replaced IBM in the lexicon of corporate uniformity, with obvious consequences for anyone not toeing the line.
For developers, .NET comes with some pretty heavy strings attached. It involves committing to a Microsoft stack, using IIS instead of Apache, Windows Server instead of Linux, a whole bunch of odd Microsoftian applications, wizards, talking paperclips, brown shoes with a black suit, all things that good developers hate. The upside is C#, good library support and excellent performance.
On balance, if we were forced to use .NET we would probably give up and move to New Mexico and raise organic chickens or something; it just wouldn’t be fun.
Enter Mono, stage left.
