Submitted by chrishu on Mon, 11/16/2015 - 08:59

Introduction

I have been away for a while but Drupal 8 is nearly here so I guess I need to 'get back on the horse'.

Creation of a Drupal site involves a number of roles although often someone is acting in more than one capacity, sometimes I think the role of Site Builder is underrated and understated.

I am currently in the position where I am 'the Drupal guy' for a large site build. From a Drupal perspective I have to fulfill all the Drupal roles at some stage in the build, although there are talented knowledgeable people handling other areas of the project, they have never used Drupal. In an ideal world this will be my last big greenfield Drupal 7 project (D8 was not yet a viable option for this project), but the world is not ideal.

I am about to enter a Site Building stage, which led me to think about what Site Building actually means.

What is Site Building?

I am not sure this is always clear, for me Site Building is all the stuff that is done through the web administration of Drupal to build and configure a site, including content structure, business logic and display logic (to some extent).

Administration may run/grow into Site Building, but there are clear lines:
  - A Site Builder may have created structured content (types): an administrator may create, curate content
  - A Site Builder may have created roles, permissions, work-flow : an administrator may assign users to these

Site Building may be carried out by somebody who thinks they are developing at the time, without a dedicated Site Builder on a project many 'developers' may actually spend considerably more time configuring content structure, views, panels, rules etc. etc. than coding PHP (which appears verrrryy strange to some people peering in from outside Drupal).

No country for Site builders

Like a lot of things, understanding the significance of Site Building for me comes from "getting off the island" and using other tools and frameworks etc. as well.

To some extent with ExpressionEngine (I only hesitate a little because I didn't try out a lot of the contrib. modules) and a larger extent with SilverStripe (a cms and framework I am growing to like very much) there is no real Site Building space. Developers (front-end and/or back-end) build sites with them, they build in or augment some functionality for administrators to 'administer' the site they build.

Site Building as a role is not 'broken' with the many tools and frameworks where it is absent, it is just not a consideration, not part of the requirements, and in some use-cases this is a positive advantage (building content structure as part of a model in code can be very efficient for a developer). It does mean that although little bursts of what we might describe as Site Building may occur, it is not an activity that is going to make sense as a separate function within an agency or for an owner of website/s.

Site building in Drupal often clashes with development, especially on larger builds and teams, Drush makefiles, source control, advanced use of Features all potentially clash with pure site building.

Site building as a job description

With Drupal there is space for a Site Builder, in fact a lot of the development of Drupal has been to enable and empower Site Building (to the detriment of some other activities some would argue...).

Site building is not administration and implies some minimal degree of technical knowledge (to me a least it implies that), the 'Web and IT Knowledge' area described in the details for the Acquia Certified Drupal Site Builder exam mentions basic HTML, PHP knowledge for example, although personally I would say knowledge of how things fit together and where the edges are could be enough.

I would think that basic command line/drush knowledge would be useful also (depending on hosting environments).

Perhaps most importantly a Site Builder needs to understand content to build sensible structures within Drupal, people invested in the project in prior stages may well be focused on web pages rather than content, leading to the kind of site that needs building from scratch next time the design changes...

Within a relatively busy agency dealing with multiple Drupal sites, I can easily see a productive role for dedicated SiteBuilder/s although this is extremely rare in the UK agencies of various sizes I have been involved in.

Within a large company or corporation there may be a clear benefit in having a Site Builder especially where multiple sites are concerned. In this case a Site Builder may well also be an administrator, content manager and/or have some kind of marketing role, this scenario is more common in my experience in very large companies (often a department trying to buck internal politics and if there is no Drupal available they may well have gravitated to setting up individual Wordpress sites to get things done).

Site builders as digital advocates/translators

Based on the above a Site Builder within a company may be in an excellent position to act a digital advocate, translator/interpretor.

Lack of digital literacy is sadly far too common even in digital related companies and agencies (project managers, account managers, sales managers, manager managers etc. etc. may suffer from this) To the extent that if the company was a funeral directors we would be seeing conversations such as
manager: "Ahhh sorry I understood we need a vehicle to transport a body, and costed for that, is that not so?"
client(or developer): "The vehicle is not appropriate.."
manager: "I know all about 'vehicles', have worked with them in previous industries!, I assumed a moped would be fine"
client(or developer): "Actually no."

Too cruel perhaps? 

A Site Builder could act as an excellent filter/antidote/educator in this respect and from within a company start managing development expectations and skills needed for the next big thing... (sorry Site Builders, but it looks like somebody still needs to do this, developers are far too literal/blunt most of the time).

In this 2013 Drupalizeme podcast "What is a Drupal Site Builder", the implemention seems to be that Site Building naturally may evolve to theming or development, I think there is also an arguement for evolution in other direction directions such as project management/planning.

Site building for D8 is 'all?' win

Well actually I think development and theming is all win in D8 as well, with the exception that there is lot to learn (the learning is applicable elsewhere however).

Site building in D8 from my experience is slicker, familiar enough that learning the differences is mostly incremental and 'on the job'. As a bonus lots of essential stuff is now in Core.

The new configuration management means that finally most of the awkwardness arising from code vs configuration should hopefully be resolved, it appears that Features can finally return to what it originally intended, bundling functionality. I need to see how this really pans out, development and maintenance of D8 sites for real, but it should enable Site Builders a lot more flexibility to develop views etc. customise sites and if needed work with Features outside of developer support.

Conclusion

I have to conclude the following:

Site Building is a valid and important stand-alone Drupal role, in fact I can think of a number of projects that would have run better with a dedicated, skilled Site Builder on the team.

When site-building as part of also doing something else on a Drupal site it worth taking time thinking about what you are doing.

Any comments or thoughts gratefully received, this has been the views and musings of one cantankerous developer I probably need to stand corrected on at least on or two things.

Comments

Steve (not verified)
Mon, 11/16/2015 - 13:03

The datatypes of a content type are sometimes critical. Wrong choice of datatype for a field could compromise the performance of a site. So it potentially goes further than creating sensible datastructures.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.