Identifying an end user's pain points, mistakes, assumptions and general confidence in their website management interfaces is an interesting exercise. All developers can learn a ton from listening and watching users navigate the systems they provide. I think inherently, most Drupal developers ensure that interfaces cater to themselves. Even as beginning Drupal developers, we learn where things are inside of Drupal. With enough practice, it becomes second nature to know where things are and how things operate together. But to assume that an end user has the same knowledge, or, even cares to, is a major mistake. It's end users that tell their superiors how good or bad Drupal is. In turn, those supervisors tell their superiors how good or bad Drupal is. With multiple layers of people potentially announcing that Drupal is tough to work with, we have a situation to deal with. Drupal is in fact a large frame work with many complexities. But, do those complexities need to be presented to end users at any level? That answer is quite simply... No.
Creating simplicity guarantees elegance:
The Relativity Data Model thrives on simplicity. Using modules already tested and true by the community is the basic backbone of the Relativity Data Model. With strategy, full command of intended results and keeping simplicity as the goal, we can then easily design UI's that will cater to end users. What I have found is that if you give users things to look at, make assumptions on, guess intended function and/or experiment with, you immediately open yourself up for criticism, not to mention potential system problems. So, how do we plan our interface strategy? Quite simply, the magic is in providing "only" what is needed to complete a user thought process.
A journey begins with a single step:
Let's take a test drive and implement everything we have covered so far in this and previous pages. Please refer below and spin up a brand new development environment using the newest recommended releases.
- Drupal Core 7.34
- Ctools 7.x-1.5
- Date 7.x-2.8
- Entity API 7.x-1.5
- Entity Reference 7.x-1.1
- Entity Connect 7.x-1.0-rc1
- Field Group 7.x-1.4
- Token 7.x-1.5
- Pathauto 7.x-1.2
- Views 7.x-3.8
I recall hearing this phrase many times: "there's a module for that". So, by nature we take that for face value and usually throw all kinds of modules into Drupal sites, just because, we can. I can say this from experience many times over: if you want to watch a Drupal site topple over and fail, continue to load modules just because you can. Let's take another approach by rendering that phrase completely useless. Let's practice a new concept with a new phrase: "Only load a module if it helps your architecture complete a user thought process". You'll be amazed at what you can do by staying close to Drupal core, with the smallest amount of contributed modules necessary.
Those of you with some Drupal experience might be saying.... wait a minute, can you really spin up a Drupal site with all these new data architecture abilities on only Drupal core with nine modules? Can this same tiny number of modules handle our elegant UI needs? The answer is a resounding YES! Remember, implement only what you need to complete the intended user thought process. Keeping this strategy in mind will drastically scale down the footprint of Drupal sites. Yes, even those sites with powerful, new and limitless data architecture capabilities.
The marriage of architecture to UI
In the next section, all these concepts of architecture and UI will become clear. The trick is to keep architecture and UI together as one process. Using a single Drupal module named Field Group, we will create the lifelong bond between architecture and UI.