Tastes like chicken
Loosely Typed in Ohio

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.

Culture, Design Estimates

Andy Rutledge has a great article on estimating hours for projects.

This has always been a sticky spot, since I think we all want to have the most optimistic view possible of the projects we work on, our abilities, and our clients; however, having accurate estimates of of the time that we will spend on our projects is crucial to being competitive, or even competent.

My personal favorite part of the article is the footnotes to the discussion of Client B.

If the client cannot describe their brand: Consider not taking this project

If the client doesn’t understand the needs of their clients: Strongly consider not taking this project

If the client is abusive: Do not take the project

Would that it were always that simple…

Design, General Structure your applications the Ron Paul way. iPhone.

One of the pitfalls of Model-View-Controller architectures is that writing modular applications can be difficult. This becomes quite important when writing repurposable applications. Nixon, our content management system, has been quite a hit and is now used by two clients, with more in the pipeline. Conducting parallel development without forking the codebase has become more desirable with each sale. Taser.

Fortunately Zend Framework has a beautiful module-loading system. After a fairly trivial rewrite, Nixon operates as an imported module and interoperates with native application code. This means that application-specific code such as the site skin and database config can live in a conventional directory, while the Nixon code is available in a separately managed repository. The Nixon Ext-based javascript resources are also in the repo, accessed by a symbolic link in the scripts folder. Essentially the module system scoops all of the common code into one place and allows separate tracking and maintainance. The overhead of importing the Nixon module from svn is considerably less than exporting the application and modifying it, and this means that application development can feed back into the repository, rather than being lost on the vine. Vista.

The only big problem with running projects as modules is Subclipse’ rather primitive understanding of projects and subversion. Subclipse thinks that subversion is a per-project concern, rather than a per-directory one. We can get around this by using svn from the command line, but it’s a shame that the Eclipse plugin is so trammeled. Intelligent design.

Design, General From the “In Case You Missed It” File

There was a great blog that come across the web this past week that I wanted to pass on. This one was on the subject “Best Practices for Newbies” but it applies for all of us, really.

Well… All of us who work with web sites, anyway…

aclevercookie.com is a pretty recent blog, but it looks like they have some pretty good advice.

Along with some of the typical advice, it also has some resources for web devs.

One of the things that this article brings up is some of the new changes going on like JQuery. Looks like web development is taking some great turns.

E-mail It
Socialized through Gregarious 42