At the heart of “Thinking in Drupal” is data relationships. In this blog, I’m going to share how I acquired skills that ultimately enabled me to plan and build Drupal websites.
As a Project Control Manager, I used complicated spreadsheets to create budgets, estimate the impact of changes, and balance accounts against actual expenses. The task of estimating the impact of a budget change could be time consuming. It didn’t take me long to figure out how to make my life easier.
In short, changing one number so that hundreds of other data cells would update automatically was the key. In order to do this, I needed formulas (Yay simple algebra). I also needed to identify data relationships, a term that never entered my mind, but that’s how it turned out.
Imagine months going across the top of the spreadsheet and employees down the side. Each intersecting cell contained a formula that applied overhead and G&A rates to the salary earned in the month. Here is just one example of how I saved time and effort.
Imagine your boss asks for a projection of cost if the overhead rate changed. You might think changing one cell and copying it to all the others that need to be updated would work just fine. And, in Some cases it would. However, by using a cell to hold the overhead rate, and then linking to that cell in the formula, all I needed to do was change one number.
Streamlining formulas that share a data point was just one step in my journey to thinking in data relationships.
There was a time in my professional life where relational databases took up much of my time. I already had complicated spreadsheets in my back pocket so designing, building, and utilizing databases wasn’t a huge leap. However, I still had stuff to discover. My first “ah-ha” moment was when I learned about linking tables.
Keeping it simple, imagine you want to establish a relationship between two datasets: the monthly budget for technology A and the implementation schedule for technology A. Each dataset has its own ID in it’s own database. Create a linking table where the ID for the budget is saved with the ID of the implementation schedule. Result? An established relationship between two, ultimately related, datasets. Generating reports got a lot easier.
Another aspect of relationships occurs within a database. Again, the concept of a linking table comes into play. Imagine a table with student IDs as well as their personal information. Now consider a table with a list of courses where the course catalog number, the classroom, and the instructor is recorded. The linking table would include two fields: student ID and course. Each time a student signs up for a course, the relationship between student and course is stored in the linking table.
Being a database person wasn’t my life goal. And, my other job responsibilities were just as interesting, like process improvement.
It started out as a way to improve processes. Total Quality Management and Continuous Process Improvement were the catch phrases at the time. Yet another aspect of data relationships. Inputs and outputs are influenced by controls and tools. Data is changed. Humans interact. Screens change and users make decisions that impact the next screen to display.
Process is at the heart of “if this, then that” thinking that plays a significant role in system, information, and interface design. So, when the opportunity to add another skill set to my back pocket presented itself, I jumped on it: HTML and websites.
Websites and Web Pages
The most common method of creating a relationship between web pages is a link found in a website menu. In traditional HTML development, each page contains HTML code for the menu.
When I worked as a webmaster at a university in 1999, I learned fairly quickly that managing changes to the menu across hundreds of web pages was time consuming and frustrating. Armed with a spreadsheet and database mentality from my past, I figured out how to move the menu code to a separate file and then used a server-side include to insert the menu code into each page. In order for this to work, I used the server to insert the menu code into the html page before it arrived in the browser.
My next data relationship evolution came when I combined a web page with a database. If I could put menu code into a file and insert it into a web page, then why not pull data from a database and render it on the web page. I developed a custom relational database to manage training enrollment for faculty, leaning on my experience from a previous training management database. We used Cold Fusion to integrate the data fields from the database into the HTML code of a page. Online training registration and management was born without having to edit the HTML pages.
AND! We built the system as a plugin so that the various colleges within the university, who offered faculty training, could display their own courses in their own site. However, since the data was stored in one database, we were able to create a one-stop training site for the entire university. Another step towards data relationships and data reuse.
My next evolution came as a surprise during a content management system analysis.
Drupal is called a content management system, but that doesn’t do it justice. It’s a sophisticated, yet easy to use, data management system. When I discovered that I could create data driven, dynamically generated web pages without having to touch code, my Dreamweaver and Cold Fusion days became a thing of the past.
As I moved from Drupal 4 to Drupal 8, and the various challenges presented by clients, my data relationship skills grew into what many refer to as information and system architecture. Below is a sample list of skills.
- Planning and building ways to navigate websites
- Establishing ways to reuse content
- Capturing content and feeding it into condition-based features on the page
- Planning how to layout a page using data relationships such as “if this field contains x value, then display a list of pages that also have an x value.”
- Utilize URL aliases as a means of creating data relationships
- Selecting Drupal modules that work together to enable streamline content management
Much of what I have learned was put into three Drupal books, three reference guides, and many blog posts, some of which that I wrote for Promet Source. One example is “Empower the Content Author in Drupal.” It presents ideas that resulted from a process analysis of how the content authors would add content to the site. It also required identifying strategies for establishing relationships. Empowering the author is just perspective in utilizing Drupal appropriately.
I also wrote “Drupal Don’ts: Pitfalls to Avoid for Site Success” to share several lessons learned from the many projects I have been asked to consult. For additional Drupal articles that I wrote for Promet Source, please visit “Drupal Blog Posts.”
Careers in Drupal
My career path was not designed so that I could become a Drupal consultant. It just happened. Yes, I took some coding classes along the way. Understanding code logic added to my understanding of process and relationships. However, I’ve never written code for Drupal.
I hope you can glean some insights from my experiences and create a plan for yourself. In order to help you plan, please consider my blog, “Drupal Roles: Wearing Multiple Hats.” Perhaps you will find a role that interests you.