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?

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 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 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.

Next Section

Taking Inventory