The Buckblog

thanks for your time Jamis, it’s a great source of information

Nice sentiment, but this is a pretty naive way of looking at web application development. I’m not a fan of scaffolding either, but in real enterprise applications (vs the usability-oriented tools that 37signals produce) the models are far more complex and important than the UI. If you’re inventing a nice little personal organisation application from scratch then of course it’s fun to sketch out the UI first and use that to brainstorm what concepts should be represented in the model, but an existing business already has things in the real world that need to be modelled directly: customers, products, accounts, credit cards, invoices, subscriptions… This reality is more influential than the design of the user interface.

Your point is a specific instance of a correct but more general observation: there’s no point in starting with models (in the abstract) because you need to have something concrete to examine in order to decide what models you need. But it’s a mistake to believe that the UI is the only concrete thing to work from, because there are other potential starting points too (e.g. the business reality) that may make more sense depending on the context.

I’ve found the scaffold-resource to be a great way to start an application. I always go through and refine it, and change the behavior, but it’s a great way to get an application up quickly. (by the way, the ajax-scaffold plugin is a marvelous way to get a quick admin section up, and is flexible enough to get it to do just about anything you’d like)

However, I agree – you should never try to scaffold the entire application, and then deliver. Scaffolding alone is not enough.

I totally agree with the notion that the UI will, most of the time, uncover a better understanding of where you should go with your models. As Tom mentioned above, you will sometimes have to take a business-oriented view instead … the business logic is more paramount and must be solid and concrete. However, I also believe that every application is an opportunity to make something inherently complex seem simple … and that usually starts with your UI.

Oh, and scaffolding rocks when you’re a beginner but it’s not for the real world.

I think scaffolding is quite useful, but not strictly required. As many things in life, depends on the context. There will be cases when you can sit with the customer and throw scaffolding to match customer’s mental model with computer’s model. Some other times, you’ll be drawing a big o dynamic model and trying to get it on sync with the computer’s model. It depends. Finito.

I seem to work on applications that require a LOT of data entry.

I find scaffold_resource to be a fantastic time saver to get the basic forms created as a starting point which I will then re-work.

I still haven’t got in to the whole test first (or even test at all if I’m honest) mentality and perhaps my thoughts will change when I do.

I’ve been working on an app for two weeks, and I haven’t committed a single controller into SVN. All BDD and models for now. Scaffolding would just get in the way. Jamis +1.

Applications are designed from the inside-outwards where I work. Unfortunately it’s a fact of life that most organisations are unwilling to invest in the user interface of their internal applications. I head the UI team and it’s an uphill struggle to create a good user experience in an environment where the resources are weighted toward “real enterprise” things like EJBs and UI is regarded as just making things pretty!

I’m surprised there’s no mention of REST. I would like your opinion on how it fits in with this discussion.

I definitely agree the UI should be considered before creating the models, but if you are going with a RESTful approach, would you not repeat basically what scaffolding is generating? Scaffolding does tend to add too much crud (pun intended) than necessary. For example, you may not need to present the show/index actions to the interface. But, for the most part it does what a RESTful application would do – create a controller which is the plural name of the model with basic CRUD operations.

The way I do it is start with a rough representation of the UI, from this I can see little REST patterns through the interface. Use these to create the models and the RESTful controllers. It’s okay to base the controllers on the models if the models are based on the UI. Does that make sense? Do you agree?

I second Ryan’s question. Maybe before REST, scaffold was pretty unnecessary because you were going to immediately go through and invent a myriad of actions anyway. But when you’re using CRUD as a guide, there’s not much to complain about in scaffolding—in fact it’s quite helpful, it even writes your migrations for you!

However, I absolutely agree that the views it generates are generally useless. On the other hand, if you’re actually dependent on a third party designer, particularly one that is only very slowly working for a client alongside you, sometimes it can be beneficial to speed things along with a little scaffold magic.

A couple of weeks ago I started a new rails application; Admittedly, I am a newbie in Rails, only had done a delicious clone with limited functionality for a presentation on rails. I am not clear what you mean by starting with the UI first. I did draw up some screen flows and ideas what users will be able to do, but this time I started design and implementation on the domain model. I saw that a couple of Rubyists and Railers are using RSpec for testing, so I got myself the latest version and this time round starting with the model I really could get to grips on thinking what exactly my application will be able to do, writing specs for that and shaping the model to satisfy the specs. The problem domain is in the model. If it is solid and well spec’ed, things move on from here. I just think, don’t be too strict on guidelines to programming. Starting with interfaces (like a UI or an API) is surely a viable approach that will give you results. I think though, if you have a problem domain that goes beyond e.g. managing content, and the specification of it is fairly clear it is quite legitimate to start with that. I definitely agree though that also for such cases scaffolding imposes way too many restrictions on your intention.

Scaffolding makes for a good demo, and even conceivably a good management interface sometimes (as long as you modify it a bit).

My major problem is that it doesn’t really teach newcomers that your controllers should be based around the interactions you want to perform, rather than the model. People get stuck with the UserController (for example), and it doesn’t necessarily occur to them that it’s actually the interactions that should be driving what controllers you have.

Which is essentially what you’re saying, I think. I’m going to sit on the fence a bit about which should be designed first - I think pretty much they should be designed at the same time. On the understanding that the “user interface” is actually the whole user interface - what all potential users of your system may want to do, not just the admins, or end-users. Then it’s obviously an iterative development—interface feeds model feeds interface etc. Seeing the relationships between objects can sometimes add features to the interface you wouldn’t have thought of. (Assuming they actually seem necessary.)

My perspective is mainly from internal, data-centric applications. To a large extend, my views correspond to a single model or an aggregate of a main model with a few appendages.

For that scenario, I find scaffolding very helpful. My own, custom scaffolding, that is. The out of the box Rails scaffolding would be all but useless.

What my own scaffolding gives me is, declarative specification and filtering of list views. Declarative auto-completion. Combined with a custom FormBuilder, this slashes away reams of repetitive code. As a result, most of my controllers are all but empty save for a few declarations.

Same thing ;)

You are spot-on, Jamis. I think there’s also a mistaken conception that there are cases where a good UI is not necessary, and some of the previous comments imply that. I’ve come to find that even technical users who don’t really care about frills will STILL appreciate a fluid, well-thought -out and usable interface. It really makes the difference when you spend your whole day using it, even if only for data-entry!

Jamis,

I also agree with you in principle. In terms of Rails evangelism; scaffolding is a two-edged sword. While scaffolding has probably drawn many folks to Rails, it has also tended to alienate some of those who thinks that scaffolding is all that Rails does (standard FUD).

In the end, “classic” Rails scaffolding is useful for newcomers; but has limited usefulness and can be a downright anti-pattern.

As for me, I am glad it’s there, but I constantly find myself having to educate Rails newbies on its purpose and usefulness.

Wonderful post.

I try to follow TDD. Typically I’ll start each sprint with a new acceptance test (using a home grown DSL that only interacts with forms/links based on the “user perceiveable” content ie no name/ids used to identify controls), followed by a series of View tests, then controller tests (both using Test::Rails), and finally the model tests.

The point at each stage is to consider what the user interface/API should be to the next layer below.

Staying away from scaffolding is important, to me, for two reasons.

1) Its hard to keep it TDD… I trust the rails core team; I trust that the generated scaffold will work and thus it doesn’t need to be thoroughly included in my own test harness. (However there should be at least one test that drove the initial typing of the “script/generate scaffold …” command.) However at some point I’ll have to start customizing the scaffold at which point the lack of an existing harness around it is felt.

2) Scaffolding encourages the notion that you’ll have exactly one controller per model. Which is a dangerous thought pattern to fall into. Often it will be the case, but it shouldn’t be the only thing people expect.

Jamis,

I’ve written a defense of scaffolding (as part of a well developed toolkit) here:

URL:

http://jchris.mfdz.com/code/2007/1/restful_application_designwit

Excuse the mess… here’s the rest of my comment, uneaten by html.

We just had a lot of success in our application by running with scaffolding while we fleshed out the models that had been inspired by an intensive UI-first approach to a single page.

RESTful Application Design

Jamis, you’ve hit on something I always try to keep in the front of my mind: to the users, the interface IS the application. Unless they are programmers, they have no clue what’s behind the interface, nor are they likely to care.

I agree with this, I think scaffolding is stupid. I never even knew why scaffold forced the create/new/update/save methods when a single “form” method could do the same thing. Although I hear a lot about RESTful working real well, but I still think scaffolding is a waste. I just write out my code, usually pasting from an existing, similar controller to begin with.