The Drupal Site Building Experience

It’s easy to get the impression that modern site building using tools such as Drupal, Wordpress or Joomla is just a process of installing them plus a couple of modules. Then click away in the UI-configuration and the site is ready. In reality it is in most cases a much more demanding task, which I will show you in this post.

With that said, welcome to the second post in my Un(b)locking the Drupal Learning Curve series.

1. Un(b)locking the Drupal Learning Curve
2. The Drupal Site Building Experience
3. Drupal Site Building Challenges
4. Drupal Limitations and Bottlenecks
5. How to Improve Site Building in Drupal 7
6. The Opportunity with Drupal 8 & Beyond

Each post will build upon the previous ones. It is therefore highly recommended that you read them in the above order to get the most out of it.

Note: Post 5 & 6 has, after feedback to post 1-4, lead to the formation of the Drupal SuiteBuilding Usability Initiative, which I write about in Making Drupal more User Friendly. I am very excited about working with other Drupalers in the community in this initiative.

A Long Time Ago...

There was a time in Drupal’s early years when most users were able to keep everything in their heads. As the project has grown, that has become increasingly impossible. Instead it has been necessary to differentiate tasks into roles such as core, module and theme developer as well as site builder, administrator, content administrator, editor and so on. In fact, it's now become so versatile and powerful that in many cases it’s needed to even specialize within roles, leading to experts on SEO, scalability and performance and so on.

Each of these, and other, roles have their own set of skill requirements defined. This is so they are able to fully focus on their role tasks. However, that doesn’t meen roles are isolated islands, no they are very much intertwined the other roles. In fact, most of them are designed to provide for the needs of other roles, or to empower those roles to be able to really focus on their tasks.

Before going into the site building experience I will briefly go over some basics about roles that are essential to know.

Understanding Roles is Important

Understanding the needs and requirements for the roles involved in developing, building, running and using a website is important. Even if you do everything yourself, this knowledge will make things easier. Especially when your site grows and the need to involve others happen.

Most important is to understand the roles directly connected to your own role. They are the ones that affect your work and ability to perform your tasks the most. It is these roles you will have an ongoing communicate throughout your work. Therefore a good knowledge about their unique terminology, skill requirements, etc and so on will be most helpful.

I would also like to point out that users in many roles, such as site owner, content editors, contributors, clients, customers and other visitors often turn out to have very limited web technology skills. Their roles on the website is simply part of their normal work conditions, which can be anything outside the IT sector.

Roles After, Before & Parallel to Yours

How other roles are connected to your role is important. Use these three rules as a general guideline:

• You are responsible for providing the functionality and features for the roles after yours so they can focus on their tasks.
• You are a user of the functionality and features provided by roles before you. If you find flaws or limitations in those, you give feedback so that they can make improvements.
• You team up and work with parallel roles.

In an optimal situation you would thus be able to focus on working with parallel roles to provide tailored functionality and features for the roles that come after your own role.

However, we are only humans and as such we often get a little lost in our own needs. We like complaining about what roles before us has done wrong, or not at all. Then we are quick to defend our own roles when people do the same to us. See the ironic pattern in this?

For me personally, my goal is to empower others to be able to fully focus on their role tasks. I do this by trying to create the best possible user experience for them. I also want to avoid them having to learn new terminology that aren’t part of their role or require them to spend too much time learning the new stuff.

The only way I can do that is to fully understand the task, workflows and results involved in their roles. In this process I ask myself questions such as:

• What if I was the [content editor, visitor, client, etc], what features would I need and how would I want them to work to be able to be productive and focused on the tasks?

This is not only helpful to get things right from the start. It also leads to:

• New users get started quicker.
• They enjoy using the new tools and see it less as a new burden they have to fit in with all the other tasks in their job description.
• They quickly see the benefits and want more of it.
• It demands less support as the tools are more intuitive.
• They often try harder to solve things on their own before contacting support.
• And, of course, they tell everyone they know about this cool new tool they got.

Limited Playground

The closer to the anonymous site visitors, the more limited the site features will become:

For some roles that is the whole purpose. Those in the blue box above are users of the live site. With the exception of the Administrator they all have access to features that is tailored to either work with content or interact with the site. For the latter that can be using the contact form, add products to a shopping cart and so on. The more intuitive and foolproof these features are, the better the user experience will be.

It is the three boxes to the left that are directly (site building) or indirectly (developers) involved in the process of creating the site features.

Code developers has the most freedom to change or create new functionality. They do that using the various languages, PHP, JavaScript and CSS, Drupal is based on. Module and theme developers are more restricted compared to core developers. They should follow the “Never hack core” principle and also make sure to only use the public APIs core and contributed modules provide.

Site builders simply do not have the same freedom. Their role description is to use the UI-configuration that Drupal Core with a bunch of modules and a theme provides to build the features the website needs.

That might sound like a simple enough task — Just install everything and start clicking away. In reality it is far more complex. The site builder role is very demanding and requires a broad knowledge about pretty much everything involved in planning, constructing and running a site. That  is what I am going to illustrate next.

Site Building is Central for Everything

In the introduction post I wrote that the site builder experience is central. To help illustrate just how central it really is I will use a simplified flow chart that contains the bare minimum of roles involved:

As you can see above, the site builder is connected all other roles except the Site Owner. In reality the site builder is often sitting in on the meetings with them too.

What this means is that the site builder needs to possess a waste amount of knowledge about what other roles needs, the tasks they include as well as how to best communicate with them. A good amount of analytical and research skills is a requirement to become a great site builder.

Now, lets break down the above chart in smaller parts and go through them to better understand just what is going on. Please note that I am not going to explain things in detail, just give you a broad general idea of the main processes involved.

The Pre-Planning Process

Here the site builders task is, together with the Site Architect, to go over the features the Site Owner wants and create a plan and/or specification based on it.

The site builder will use all the knowledge and experience they have about Drupal core, modules and themes they are used to work with. If a feature requires unknown functionality, they will have to research, often also test several alternatives, if there exists any modules providing that. If not, either a compromise has to be made or someone tasked to develop the needed functionality.

At this point the site builder uses their Drupal experience to give estimates about if features can be built and how much time and resources that will be required.

This process can involve many iterations when going over possible feature alternatives.

The Planning Process

The next phase is to identify all the various roles that will be using the website, the tasks they will perform and the specific workflows involved. Often these tasks and workflows are connected and depends on each other. The site builder will have to understand how these roles not only need to perform their tasks, but also often how this will fit with their normal, non web related, job tasks and workflows.

With this knowledge, the site builder starts the work of planning how to implement this. They also communicate with the site architect to make sure it is within what the site owner wants.

Often the site builder will have to build prototypes, proof of concepts, to test if and how wanted features can be built. This is especially the case when those features requires the use of modules that are new to them. If there is no suitable module available, then a decision needs to be made about either develop such module or come up with an alternative solution. In the latter case this also needs to be communicated back the the site owner to make a decision about.

The Design Process

The design process can come in at various stages when building a site. It is not uncommon that there exists mockups of how the live site will look like for users and visitors for example. Often, though, these mockups are of the final view of content and features, not how content is produced and managed.

The Theme Developer is the one that breaks up the designs, received from the Graphic Designer, and creates a Drupal theme of them.

They need to communicate with the site builder about how the theme will work with the site features. The use of CSS styles is also part of this, especially the names of classes and ID’s are important as they often are inserted in the UI’s used to configure the site.

The Site Building Process

Armed with the implementation plan the site builder start the work of configuring the website using the web based UI Drupal Core, modules and the theme provides.

In an optimal situation, the UI would provide the site builder with all the configuration options needed to tailor the functionality to exactly match what’s needed. Sadly that is seldom the case. Instead they will often run into limitations due to that functionality isn’t exposing flexible enough UI configuration options. Sometimes there are no UI configuration options at all where there should. Other times configurations are global and can’t be tailored to work as wanted in two, or more, isolated places. These limitations are, however, out of the scope here, but will be covered in detail in the upcoming posts.

The site builder normally have a good knowledge about these limitations, especially when it comes to the modules they use the most. But all sites are unique so many things won’t be discovered until the work on implementing them starts.

As the site builder runs into these limitations, solutions must be found. With some luck they find a new module or a solution in the issue queues to sort things out. In the worst case a feature has to be scrapped. Most often, though, a workaround compromise can be made. The bad news here is that these workarounds often turn out to be hack(ish) solutions and also unique to the particular site.

Since they usually consists of making functionality work in ways they were not developed for, they also have an negative effect on the maintainability of the website. When the site is updated or new features added, there is rather high risk they will break things, resulting in unwanted extra work of getting it right again. The more this is needed on a site.. well I believe you get the picture.

I will write about, and demonstrate, a lot more about how these limitations affect the site builder role in the next two posts, so lets leave it for now.

The Site Builder Role is Demanding, but also Rewarding

As you can see of the above, the site builder role is very demanding, sometimes frustrating, even though I have only described a subset of the tasks and interactions it has with other roles.

Since these other roles all have their own unique set of skills and tasks, it also means the site builder needs to have a good understanding about them all. That also includes a lot of unique, and very different, terminology and technology.

All this added to the requirement of a great understanding of web technology and, of course, how to configure Drupal and several hundreds of the 16,000+ contributed modules and themes existing for it.

There are many things surrounding the site builder role that needs to be improved. Not just to make the role itself easier, but more importantly to make it possible to build better, more maintainable and future proof websites using Drupal. That is something that will be covered in more detail in the upcoming posts.

But, before I close this one I want to say that being a Drupal site builder is also very rewarding. You will interact with a lot of different people, understand their vastly different needs and how you can help providing better solutions for them. You will also play an important part of creating websites from start to end and beyond. Thanks to all this your work will seldom be boring repetitive tasks.

Then, if you take time to really get into the Drupal community you will also meet a lot of amazing new people. People that come to there to share experiences and learn about things from you too. You will quickly also realize that it is buzzing with people working together on making Drupal even better.

Related: BoF at DrupalCon Munich