Yesterday we got a brief overview of the new generation of web development frameworks and a general idea of why people are so excited about them; today let’s dive in and see what frameworks can do for the designers in the audience.
This is probably the biggest factor I’ve seen drawing design-oriented people to frameworks. There are plenty of people out there who’ve mastered HTML and CSS, but couldn’t program their way out of a paper bag. And a significant number of designers also have some skill with JavaScript — which is a programming language, no matter what some people may tell you — and may even have dabbled with a PHP tutorial or two, or fiddled with a Wordpress plugin. These folks can do a little bit of programming, but not much.
For people in this situation a framework can be a great thing, because it offers the power of doing custom web development without requiring a ton of programming knowledge; while you can certainly get more out of a framework if you’re familiar with the language your framework’s written in and have some prior programming experience, frameworks generally don’t impose a very steep learning curve for a non-programmer and — for plenty of common use cases — don’t require you to write much code. Most of the learning curve is going to be reading the framework’s documentation to learn which components you actually need and how to work with them, and then you’re off to the races.
Back when I was freelancing, there were a lot of times when I ran into a wall; there’d be a project where I could find a product off the shelf that would get me 80% or 90% of the way to what I needed, but that last little bit would require shoehorning new functionality into places where it was never meant to be. While this isn’t a criticism of any particular product on the market, it does seem to be a common dilemma in our industry: do you torture yourself trying to fit those last couple of features into something that already exists, or do you just sit down and write the whole thing from scratch? And of course, plenty of designers lack the requisite programming skill to take either of those options. They’re up the proverbial creek.
But frameworks give them a paddle. Because a framework is a tool for building applications, rather than being an application in itself, it gives you a huge head start and is designed from the ground up to let you get the functionality you need. Tired of trying to fit those extra bits of metadata into something that started out as a blogging engine? Pick up a framework and tell it exactly what you want your data to look like. Need to add some brochureware to your client’s online store? Grab a framework and get a simple CMS up and running fast.
This one applies to programmers as well, but for a designer-turned-developer who doesn’t have much experience doing back-end work the new frameworks are an especially good way to encourage good programming practice. People who start to pick up programming on the side often run into a lot of hurdles and pass through a number of learning phases which will be recognized by experienced developers everywhere, but learning web development through a framework usually gives novices some nudges in the right direction.
For example, most of the new frameworks that make headlines today follow the MVC paradigm to some extent. Besides making a lot of sense for web application development, this gives designers a gentle introduction to an important best practice in programming: break your application up into discrete chunks which serve specific purposes.
Nearly every successful web designer, at some point or another, gets into a situation where he or she would find it awfully handy to be able to do a little back-end development. Because it tends to encourage good programming practice, whether you realize it at first or not, doing that development with a framework helps to ensure that it gets done right.
And learning by doing, which is what will happen as a designer tries out a framework for the first time, is far and away the best way to learn this sort of thing; knowledge that’s picked up from experience is knowledge that will stick.
Of all the advantages frameworks can offer to a designer, I think this one’s the biggest. All too often we run into a disconnect between designers and developers, because they typically work in very different worlds; sometimes this can be worked around by good management, but sometimes it poses a real threat to a development team.
But because a good framework typically has a gentle learning curve and doesn’t require much in the way of prior knowledge, using one can get designers and developers a whole lot closer to speaking the same language. Designers will still deal with some things programmers don’t quite understand, and programmers will still deal with some things designers don’t understand, but the two sides will be a lot more mutually intelligible than they were before, projects will run a lot more smoothly and everyone on your team will be a whole lot happier.
This one I know from direct personal experience; while we’re blessed at World Online to have frighteningly brilliant people on both ends of the development process, and that goes a long way, working with Django helps us work together much more effectively — the concepts introduced by framework-driven development have become a shared vocabulary that helps our designers and developers talk about projects without tragic “I hear the words coming out of your mouth but have no idea what they mean” moments.
That’s huge.
Since I’m not actually a designer — I just play one on the Web — it’s probably best to wrap up with some first-person accounts of what frameworks can offer to a designer; highly recommended are my colleagues Jeff Croft and Wilson Miner who’ve both written at length about their experiences with Django.
And while you’re reading up on that I’ll be working on the next installment of this series: frameworks from the programmer’s perspective.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
I’m not a designer or a developer (I guess you could say I’m a content person), but this is the big draw of frameworks for me.
Even as a web developer, I’d say these are all big advantages for using a framework. I also don’t want to do much programming if I don’t have to. I want flexibility, I want the “right way” (MVC) to be easy and encouraged.
Okay, I don’t need to “see how the other half lives”, but being able to talk to work with designers within the framework can be a big advantage as well.
It’s been hard breaking out of my old designer habits: no-framework programming that’s not very pretty, well-structured and honestly, would be a nightmare to comprehend should anybody look at it besides myself.
I’m a long way into Agile Web Development with Rails and while some of it’s confusing, I’m in a much safer place than with PHP.
It’s just too bad that I’ve invested so much personal time in RoR, because from what you and Wilson are stating, Django may have been a better fit…but was late to the party.
Geof, I wouldn’t worry too much about it; I’ve done a little work with Rails and I’ve read the Agile book, and I can vouch for it being a solid, friendly platform even though I personally prefer Django. And from personal experience I can attest that the Rails community is great at helping people get into Rails and fill the gaps in their knowledge.
In the end, you should use the tool that’s best suited to what you need and how you work; the current proliferation of frameworks is a great help to that because it means you’ve got plenty of choices (of course, trying to evaluate them all on a typical project timeline is another matter…).