Although the “back-end”/“front-end” distinction is on the whole pretty useful, there are times where it feels like an inadequate way of describing questions I’m thinking through. Here are some reasons for that:

  • ‘Front-end’ problems aren’t always about how something looks or is represented — usually what I want from the distinction is to separate those aspects of the project which I do or don’t want users to pay attention to. This sort of separation is particularly relevant in an application like Goby, where a user is prompted to design a system that can be visually presented in more than one way. The tools for designing that system include structural affordances as well as an actual visual interface — I consider the former equally front-end-related because it's about what power Goby gives to a user.

  • In addressing any ‘front-end’ problem I’m not only thinking about these things, but also how it’ll scale, what repercussions it’ll have on the rest of the design system, and of course how it can or can’t be achieved in code.

  • In addressing any ‘back-end’ problem I’m also thinking about what limitations will be imposed by my solution on the (broadly-defined) ‘front-end’.

Nico Chilla