Recent posts

  • Relative readability Why go so big on type? There’s a short answer and a long answer.
  • Excuses, excuses Some people might suggest it’s not worth redesigning a site I only post to twice a year. They’re missing the point.
  • The Optimizer Every designer is wired differently. Some people are idea people, some people are artists. I’m an optimizer.
  • Indistinguishable from magic I love video games. I’m terrible at most of them. But I’m a sucker for a game with a good story.
  • Airport express Recently I learned two things about interaction design and user experience from waiting in lines at the airport.
  • Shouts and echoes There have been some situations lately that have got me thinking a lot about the Internet as a megaphone for personal communication.

Archives

8 May 2006

Framework fanatics

There's been a fair amount of framework-backlash going around lately. Here's why this designer is excited about frameworks.

There’s been a fair amount of framework-backlash going around lately, or at least some real programmers wondering why designers are getting so excited about frameworks. It’s a fair question.

Specifically, Eric Meyer sounded particularly flustered (and a little disturbed) by the all the hoopla.

All these frameworks’ proponents say “Just write in this totally simple and obvious way and the messy details will be magically handled for you!” but that’s just not how it works. You have to write in a very specific and unintuitive way, and unless you know specific magic words and what roles they can take then nothing will happen except the return of an error message. This is no different than any computer language, of course. What I think bothers me is that the cheerleaders always seem to believe, or at least pretend, otherwise.

Setting aside the fact that I’ve never heard any (educated) proponent of any actual framework say that, I think he’s responding in aggregate to the general excitement, which is understandably overwhelming and off-putting from the outside.

In essence, I think there are two separate groups of people getting excited about frameworks right now.

One is actual programmers, who are thrilled to finally get past all the rote, repetetive parts of programming and get on to actually doing something interesting with their code sooner in their projects. In that way, frameworks are like scientific calculators—it’s best to use them after you know how to do calculus.

The second group is designers and non-programmers, who are excited about frameworks because they can use them to build their own simple apps without training for a new career or asking a programmer to do it for them.

These two groups are very different; they think about things in different ways and they have different priorities. They’re both excited about the same thing, but for very different reasons. No wonder programmers don’t “get” why the designers are so excited, and vice versa.

I posted a response on Eric’s site, but I’ll include it here as well, because I think it’s relevant.

I think part of the reason you get so much of this “cheerleading” from non-programmers about frameworks is because every designer secretly wants to be a programmer.

Web designers have been using these prepackaged tools for years and hacking some template code here or copying and pasting some PHP there and praying it works. Every now and then we start to think “I could do this”, but we dive in and try to “learn programming” and it just doesn’t work, because we’re going at it the wrong way and it doesn’t make sense to our brains.

Frameworks are like a programming erector set for designers. The barriers to entry and the cost of failure are both low. If you can build what you want to build with the pieces in the box, you’re golden.

The “oh shit” moment for designers with frameworks is realizing that we can actually build something that doesn’t fall apart AND doesn’t feel like matchsticks and airplane glue duct-taped to the top of a Hot Wheels car.

We open up the box, stick some pieces together and go “Wow this is AWESOME!” A construction engineer would look at what we made and think it was ridiculously childish and limited. “You’ll never build a skyscraper with that,” they’d say.

But that’s the point. We never wanted to build a skyscraper, and we never wanted to be engineers. We don’t know anything about laying foundations, or construction codes, or structural integrity, and we don’t want to. We love frameworks because we don’t have to.

Frameworks are nice for real programmers because they cut out a lot of the routine, boring or complicated parts of programming that they don’t want to deal with. As a side affect, they’re really appealing to designers because they cut out a lot of the parts of programming that they don’t know HOW to deal with.

So that’s why we get so damn excited. We’ve got a new toy to play with.

Surely Eric remembers the early days of the standards movement, when there was this huge surge of excitement about XHTML and CSS and valid markup and semantics. There was a core of validity to the excitement, and there were a lot of people (including Eric) who really understood the implications of it. But most of it was just excitement about excitement, over the top zealotry about the next cool thing. After a while, it was just annoying.

But look where it got us. It was that mass excitement—largely from people who didn’t understand what there really was to be excited about, to much head-shaking from people who did—that pushed standards into the mainstream. They’re not the next cool thing now, they’re an assumption, a starting point.

If you think about frameworks as collections of best practices (which the best aim to be) instead of a magic bullet (which none of them are), there’s a good argument to be made that we’ll say the same thing about frameworks in a few years.

More on this subject tomorrow.

Comments

  1. 9 May 2006

    Ryan Thrash

    I think you’re dead on.

    There’s also a chance that frameworks that lock you into a single prescribed way of doing things are in the end going to be niche solutions; niche doesn’t necessarily mean bad either.

    IMO, frameworks should provide as much flexibility as possible while keeping the arcane and decidedly programmer-centric “build” process out of the loop for truly widespread adoption. A really flexible framework should adopt to the various workflow styles that developers/designers prefer. The artist shouldn’t be forced into molding himself or herself to fit the tool so to speak. With this type of flexibility, though, comes a very delicate balancing act…

    It also wouldn’t hurt if a framework could run on the majority of shared servers floating around out there. Unfortunately that means modest memory requirements and lots of PHP 4.x with which we still must cope.

    There is no magic bullet yet, and I suspect there never will be really. But I bet we see some pretty interesting sets of guns and ammo in the very near future. ;)

  2. 9 May 2006

    Andrew Dupont

    Well-put. I converted from PHP to Rails when I discovered (with great enthusiasm) that Rails wouldn’t make me reinvent the wheel with every new project.

    I first started playing around with PHP in college, and I owe it a lot: without PHP I might never have become comfortable with programming. But I also owe Rails a lot: without it I wouldn’t have absorbed higher-level concepts about computer science in general. Rails helped me “get” Ruby; “getting” Ruby has made me a better coder regardless of which language I use.

  3. 9 May 2006

    Wilson Miner

    Ryan: You’re absolutely right about the delicate balance between flexibility and simplicity. You need just enough magic to get people started on the first 80%, and not so much that it makes the last 20% impossible. It’s a fine line, but I think it’s going to be a critical one for framework adoption.

    Andrew: That’s another good point. With the right framework (one that follows the “collection of best practices” model), at some point along the line you start learning something about good programming, even if you just came for a quick fix. You get the motivating and empowering experience in the beginning of having things “just work”, and when you get to the point where you need to do more, you can take a closer look and learn a lot from figuring out how it works to begin with.

  4. 9 May 2006

    Jakob Heuser

    Frameworks are the “gateway drug” to programming. People feel like they can do things, and then eventually, they want to do something and the framework won’t let them (or will let them in a roundabout way). Then, they start opening up the framework to change things and it all grows from there.

    Andrew: I’d agree in what Rails gave me as far as understanding another language. As someone very heavy into PHP, Ruby (and the Rails framework) showed me another way to do things, just like Javascript showed me a different way to do things. As a programmer, the more ways you know how to solve problems, the stronger you become overall.

  5. 9 May 2006

    Ben Weiner

    Great article. Coming from the other side, I’d like to emphasize that most of the best frameworks are those that do some things really well and don’t try to do everything. Django and Rails both have many features, but it’s easy to get started. Programmers building a complicated web app would might turn to a framework that gives them more flexibility, like web.py.

    Over time when more and more designers start using these frameworks, there will be frameworks that emerge that have an even lower entry point and do those things that designers need the most and in the way that they expect them too.

    There’s no reason why we can’t build a framework using syntax that was intuitive to a designer built on top of a domain-specific language (which I might add are quite easy to build with Ruby). The more declarative they are the better; you want to say “what” to do, not “how” to do it.

  6. 9 May 2006

    Morgan Craft

    Nice article, I agree with the example that frameworks are like a scientific calculator. And that use them after you already know Calculus.

    Unfortunately, there are issues with frameworks. Such as performance and scalability that I think designers don’t necessarily recognize. But as the article mentions, maybe not everyone is trying to build sky scapers.

    As time goes on I think there will be different types of frameworks for different tasks. Some that appeal to programmers and others that appeal to designers.

    One thing frameworks will not solve is information architecture.

  7. 9 May 2006

    Wilson Miner

    Morgan:

    Unfortunately, there are issues with frameworks. Such as performance and scalability that I think designers don’t necessarily recognize.

    I think those are issues with particular frameworks, not frameworks in general. There’s nothing that inherently precludes a framework from achieving high performance and scalability. If it’s a priority at the framework level (as it is with Django), apps using the framework will benefit, whether they know it or not. Which sounds like an upside to me.

    One thing frameworks will not solve is information architecture.

    I’m confused by this. Of course frameworks don’t address IA, just like they don’t address design. Is there a programming framework out there that claims to? I guess Zope/Plone might encroach in this territory, but I think falls into an entirely different category.

  8. 9 May 2006

    Tim Case

    …and it also begs the question, What about us programmers that secretly want to be designers…

    Where’s our framework?

  9. 9 May 2006

    Ken Soliva

    Tim, I think the “framework” you are looking for is referred to as a WYSIWYG editor ;)

  10. 11 May 2006

    Faruk Ateş

    You’re pretty much spot on here, Wilson. I’ve become interested in Django because I was thinking about creating a PHP-based framework, but then I realized that I’d benefit a lot from learning a new language and someone else’s framework instead, as well as cut time on a lot of things (for instance, it’d have taken me many years to create a framework as powerful and flexible as Django—years I don’t have).

    They cut time, and that’s exactly what I’m looking for right now. Oh, and contrary to what you seem to think, I’m a programmer, not a designer. :-) I want to become a designer as well, but my true skillset right now is code, by far.

  11. 11 May 2006

    Wilson Miner

    It just goes to show the lines are getting blurred! And my brain, apparently!

  12. 12 May 2006

    Faruk Ateş

    Wilson, the primary reason for that is probably the fact that my public coding days (i.e. when I was doing public code and sharing it in communities) were all long ago in the time I was heavily into vBulletin.

    Ever since I started blogging, I’ve hardly wrote about coding, and certainly haven’t done any public coding (thanks to working on closed-source CMS’s)

  13. 30 June 2006

    Kevin Teague

    It is great to finally see designers getting excited about frameworks - and as a long time Zopista it is also nice to finally see frameworks finally come into fashion for programmers too.

    There is probably a backlash from some programmers because they are feeling like they’ve been pushed into the mud. Here they’ve being mightly hacking away for months (or years), and then a simple, photoshoping, fonts-n-colours designer who barely knows anything about programming comes along and builds something twice as functional in a fraction time … and it looks awesome too boot.