Breadboarding: Simplify with partials

Here’s a breadboarding technique I didn’t include in the book (yet).

Sometimes there are too many affordances to list under a single screen. For example, say you wanted to breadboard what’s on this screen:

How would you list all the affordances in each topic row? How would you indicate that the same affordances repeat in each row? How would you distinguish the affordances for navigation from the topic row affordances?

To simplify this task we can borrow a convention from Ruby on Rails templates. Rails has what are called “partial” templates. A partial is piece of a larger template that has its own name, can be rendered repeatedly for a collection, etc.

In Rails, a regular template might be called index.html.erb, and a partial is prefaced with an underscore like this: _topic_row.html.erb.

We can use this same underscore notation when we breadboard to refer to a partial.

Here’s an example:

Look how simple the latest place is thanks to the partials. This example uses another convention borrowed from Rails: collections are plural, members of the collection are singular. That helps us name these partials. First we give the repeating thing a name, like topic row. Then we name the collection the plural of that: topic rows. To indicate that it’s specified as a partial in another place on the breadboard, we preface it with an underscore: _topic rows.

Experienced programmers may catch a whiff of something familiar here. This technique is analogous to the Extract Method refactoring and Kent Beck’s Compose Method pattern (from Smalltalk Best Practice Patterns). Notice how latest is very easy to read because the two pieces on it are at the same level of abstraction, and the details are spelled out somewhere else. It would be natural to add _pagination or _nav as other partials on that screen and spell their affordances out elsewhere.

Whether we’re breadboarding, designing, or programming, it’s always a good smell when we have language to discuss different parts of the system. In this case, notice how _topic row and _last post both have a timestamp affordance. We might ask ourselves: is the timestamp on _topic row the date of the original post or the date of the latest reply? Notice how the names of the partials facilitate that conversation. “Should we use the date of the latest post on both the topic row and the last post? Or should the date on topic row be the original post date?”

That’s exactly what breadboards should do: facilitate conversation about what the right affordances are and give a language for the design and programming work to follow without overspecifying the details.