You Say "Tomato," I Say "Taxonomy Term Reference"...
In years past I spent a whole lot of time developing applications from scratch, versus from frameworks like Drupal or whatever your framework of choice is. Building from scratch, you can make an app do precisely what you want it to and you can quickly figure out what needs to change because you built it from the ground up. Building from scratch though also means you also can bank on hundreds of hours just dealing with common and repeatable issues like user management, security, or database design before you even get to building the unique and fun stuff. Fortunately, nowadays days I get to use Drupal as that magical "make it do anything you want while not having to build most of it" kind of solution. I love working with Drupal! So does an ever growing number of other peopleapparently. In all the buzz and excitement however, I do think sometimes we overlook how much we can help our clients by giving them Drupal without making them become Drupal experts.
You see, Drupal has been around a while now. Through a colossal amount of goodwill from the developer community, Drupal has become something truly special but also something quite complicated to the newcomer. What inevitably happens in this type of life-cycle is the emergence of a whole lot of ways to slice and dice functionality and content, resulting in a rather expansive Drupal vocabulary that you need to understand if you want to build Drupal sites. Who of us began working with Drupal and immediately knew the difference between a node, an entity, or a taxonomy? (Yes, I know many of you are saying "But there wasn't even the concept of an entity when I started!") Who immediately looked at a Drupal page as an administrator and understood the significance of text blocks, view blocks, page templates, panels, etc? There's definitely a learning curve to working with such a mature and fully-featured platform, but that's ok because anything that's powerful requires skilled professionals to get the most out of it. That doesn't mean, however, that the end-user needs to be pushed through the same process. We at Ashday have been finding more and more that it can be a great service to a client to spare them the discomfort of simply being thrown into Drupal's default administration and terminology and instead take the time to think from the perspective of someone who isn't a Drupal developer. It means not focusing purely on functionality, but also on how the user will experience that functionality from where they're coming from. Let's take a specific example and see what we're talking about.
Let's say you want to build an invoicing system and each invoice has one or more payments associated with it. You then decide to create an Invoice content type with a bunch of fields and then create a Payment content type with a bunch of fields and then an entity reference field on Payments that connects Payments to Invoices so you can relate the two. You may have gone the Field Collection route instead of a separate content type for Payments, but decided against it because you need some special reporting as well as security handling on payments and Field Collection just isn't cut out for that. Anyways, you then give the user permissions to manage those two content types, hand them the Administration menu and you're done! Well, let's think further.
Thinking from the perspective of the end user, you realize they have to go to two separate places to add content that - in their mind - is so connected that it could just be considered part of a single component. You also realize that it's not going to be fun to enter a Payment and then have to search all existing invoices in order to map it to the right one. It's also likely that they will need to update the invoice after entering new payments to reflect a new "balance due" so they're probably going to multiple places every time. That's when you could decide to implement the Inline Entity Form module, which pulls the Payment creation right into the Invoice form. This allows you to keep Payments as their own content type but it effectively hides that architectural decision from the end user. All they see is an invoice form with the option to enter as many payments as necessary within the same form. That also means that now we can dynamically update the balance due using a little jQuery since all the data you need is present on the same page, thus sparing the user yet another task. Ok, so we're getting somewhere!
If you take it one step further, you'll notice that the Inline Entity Form module gives you a "Save node" button when you want to edit one of those inline entities. Well, what the heck is a "node" to the end user? So far, the user has hardly had to care. So let's go ahead and use hook_inline_entity_form_entity_form_alter and change the name of that button to just "Save." There, we've spared them confusion once again!
Lastly, to manage these invoices - rather than sending them to "Content" or "Add content", forcing them to think about which elements are "content types" or what that even means, we'll send them to a custom menu or dashboard like page (which has all of their management links) with a link labeled "Manage Invoices". This takes them to an Invoices view that allows them to quickly sort and filter their invoices as they need to. We've also included a Drupal "action item" labeled "Generate new invoice" at the top of the view so they can always kick off a new Invoice right from this same screen. No where in the chain at this point does the end user need to worry about how Invoices or Payments were built, nor do they need to know how to navigate the many menu layers of Drupal to find it. They don't need to know about nodes or content types or views. The interface is directed toward what they're trying to do, not how it was architected. It's intuitive and gives them direct access to what they need without requiring a bunch of training just to understand how to manage their content. To me, that's the real power of Drupal because you can build amazing stuff on a platform without requiring the end user or client to be an expert on anything but their own profession.
Hopefully this is help