In my work with wevouchfor.org, I’ve been learning Rails. Rails is increasingly leaning toward REST. In REST, you’re encouraged to think of your site as containing piles of different kinds of resources. (Your database backend encourages the same thinking.) Rails makes implementing standard operations on those resources the path of least resistance. For example, tell Rails that one of your resources is an article, and—boom!—you immediately get these methods (from p. 410 of Agile Web Development with Rails):
articles_controller.rb, and you’ll find a skeleton for the
index method (produce a list of all the articles), the
create method (to add a new article to the database), and so on.
Ah… working with ease. But is it the right work? In my case, this ease of work was one of the things that led me away from what I should have been concentrating on: who’s the most important user of the website, and what’s the most important thing she wants to do? As it turns out, it’s none of the REST operations. As I merrily filled in the blanks Rails gave me, I was not doing the most important thing first, and I think it likely that I was leaning toward a worse user experience.