Growing the Drupal Way

Learning curve image

At the beginning of my Drupal career, like most, I went up the learning curve ladder in pre-defined steps: Content types, Taxonomy, Fields, Modules, Themes, Views etc. What I learned is that whether you speed along, or trudge through slowly, Drupal is not a simple step by step learning curve, but one of plateaus that occur in an unscheduled fashion. But in general, Drupal people are all developers at heart on some level. It really makes no difference if you are a site builder, module writer, themer, designer etc. All of those things require spill over knowledge from other disciplines. The bottom line is that developers solve problems. So, with that said, learning Drupal can be considered a new developers largest problem. I found Drupal to be a toolbox with unlimited capability, so to me, the learning curve plateaus were quite attractive. As I hit those plateaus, new drawers and tools appeared in my toolbox. Or in other words... I was solving my largest problem. This unleashed a new bigger problem. We all climb the same learning curve ladder, so are all Drupal developers creating sites using the same methods? If so, how do we define ourselves as unique? How can we say we provide unique Drupal solutions? The answer to that problem for me, required asking myself  two simple questions:

  1. Who will use the Drupal sites I develop?

  2. Am I creating problems for these users because I am not a unique Drupal developer?

Reacting to the Obvious (but often overlooked)

Part of developing Drupal solutions is to train users to work with the solutions you provide. The question soon becomes is your solution adapting to a users thought processes, or are you asking a user to change their thought processes to adapt to your solution? 

  1. Upon login, is the user brought to their specific thought processes and related tasks?
  2. Does the UI follow a users thought process workflow?
  3. If errors are made, how does the UI react and help remove the error potential?
  4. Is a user required to hunt for things while trying to complete their thought process?
  5. Are we creating interfaces that work for "us" as developers, the end users, or just taking what Drupal gives us out of the box?

So what is a user thought process?

In my experience, a user thought process is the reaction of being given instructions to complete a task. To complete the task, a series of events must occur in a specific order. This point begins the concept for the Relativity data model procedure.

  • Does Drupal cater to a specific, independant workflow across all permission roles?
  • Can we remove most, if not all of the usual pain points that gives Drupal the mystique of being difficult to work with?
  • Can data be re-purposed throughout the system?
  • Can we remove the Admin Menu for all permission roles other than Administrators? 
  • Can we provide a unified dashboard with all necessary tasks related to the user that is logged in?

A reliable data hierarchy is mandatory:

I view Drupal content types on a level plane. There are no content types that are more important than another. There is no hierarchy to content types. Drupal gives us the ability to display related content records usually by classifying these records with a common taxonomy term. Taxonomy is a great module that has stood the test of time, but to me, it has holes that can produce undesired results. Consider these points:

  1. You have 20 blog posts classified with the taxonomy term "Apples".
  2. A user enters three new blog posts, doesn't see the term Apples, and enters a new taxonomy term spelled "apples".
  3. The result is two taxonomy terms of the same word, two different spellings, but the new blog posts do not become part of the original "Apples" display.
  4. Taxonomy vocabularies and terms are stored as a flat file structure in the database. This complicates Views based on Taxonomy and creates complex queries with performance issues.
  5. Taxonomy lives "outside" of the content types, therefore creating the need to hop between screens to keep nodes and their vocabularies in sync.

Breaking the mold we are all part of:

  • Why couldn't we have a modular approach to content types?
  • Why couldn't we have relational content structures multiple levels deep that can stand on their own, or even become related to other multi level structures?
  • Why couldn't we mimic the concept and functionality of a database and "join" content structures to other content structures?
  • Why couldn't we completely remove the need for Taxonomy?
  • Why couldn't we re-purpose content already in a relationship to other data structures not in the same relationship?
  • Can we implement all this with only a user interface?
  • Can all this be done with ZERO code or custom modules?

Where are we left now?

While I could continue raising questions and scenarios to question why we do things the "Drupal Way", I believe we have enough of a foundation to explore alternative methods. I also want to emphasive, that I am not bashing Drupal in any way. I adore Drupal and all it stands for. My vision is simple: Take the outstanding work of others in the community and offer new methods to streamline the development process and scale down the complexity and resource needs of Drupal sites.

Your fork in the Drupal Road:

You are now confronted with a choice.