The Node and the Page

Posted Jun 2, 2010 // 2 comments

Drupal can be used to build so many different kinds of cool things that as developers we sometimes forget that the users of our sites - and, more importantly, our clients - don't see their website through the same eyes that we do.  

When we think about what makes up a site, we conceptualize it from the inside out: we think about how the data is defined and stored, how the content is processed and filtered and formatted, how the theming layer applies logic and presentation to the raw data held in the database tables.  For us, the website is a system for managing content, the public face of which is but one part of a larger whole.   

Clients don't think that way.  The way in which they conceptualize a site hasn't changed much over the years - in the beginning was the web page, and even today, when sites are generated dynamically, a website is still defined as a collection of web pages.  When they think about their site, the picture that they have internalized looks like a site map - here is the homepage, and connected to the homepage are section pages, and connected to the sections are the pages that make up the content of the site.  

This manner of thinking has held true even as their website has evolved - they may have had five or six distinct sites over the years, starting with a simple brochureware site, and moving through flat html files to templated sites and dynamic web content management systems, but they still think of the site as having a distinct structure, and as each page as a singular object.  For them, the complexity of the systems that render their site is reduced down and flattened by the fact that they rarely encounter anything aside from the end result, which is, in fact, a distinct HTML page.  Even when managing the site, the paradigm that they work within is highly structural.

This is not an incorrect way to think of a site.  Part of our job as developers is to build structures that are easy to internalize, that have an intuitive consistency that speaks to the client's and the user's expectations of how a site is supposed to behave.  The problem arises when we as developers forget this when we talking to our clients, both current and potential

This doesn't necessarily indicate a deficiency on our part - it's simply a function of how we as developers think of the site.  We think in terms of the Node, and our clients think in terms of the Page.

Pages are straightforward.  They are a distinct entity - it's what you see on the screen.  They are singular, a thing, an item.  Nodes too are singular, occupying a single row in the node table, and often are most profitably thought of in terms of a page, but truthfully they are more than that.  A Node is defined, generically, as a central point of connection, and Drupal's entire architecture is built around this idea.  But what does this mean?  At it's core, the idea of the node makes the assumption that information does not live in isolation, and that the data points that describe one piece of information are relevant to and add context to other, related pieces.

This idea lies at the root of Drupal's power.  Because a node is a node is a node, any function that applies to one can be applied to another.  This allows for applications of startling complexity.  Drupal may not be the best tool for every job, and for some jobs it is frankly inadequate, but it can generally do more things well enough than most other platforms, and at a price point that makes it attractive.

It is tempting to try to explain this flexibility to clients, to show them that they are getting an extraordinarily powerful tool as part and parcel of their new website.  But they don't see this - their concept of what they need is tied to what they understand, and unless we relate the pages that they see to the processes that create them in terms that they understand, they are likely to become overwhelmed.  

Drupal has long had the reputation as being complicated and having a steep learning curve, and when taken as a whole this is often the case.  When clients are presented with all of the tools and controls and options that are present in the administrative suite, often times it is too much to take in, too much to reconcile to their idea of how a website works.  The better we understand this, and the more we speak in their language, the better their experiences will be, and they will eventually come to think of their site in terms of the Node rather than the Page.