One of the primary advantages of having a completely custom content management system and an in-house developer has been the ability to get things "exactly how we want." As we move to Drupal, we are building largely off of Drupal core and contributed modules. One reason for deciding to switch platforms was that Drupal can give us a ton of functionality without having to write and maintain a lot of code. As a result, I (Gwen, ILAO's Director of Technology Development) am freed up to focus on technology innovations that aren't so easily accomplished "out of the Drupal box" and broader architecture issues rather than on maintaining a custom content management system, that by and large, does exactly what Drupal does out of the box.
Now that we are a dozen sprints in, what I'm finding is that we still often cling hard to wanting "perfect" - which can only come from custom. This comes up most frequently in the context of UX issues, which we can't ignore (see #2 of our Ground Rules).
Here's an example of what I mean when I say 'trying to get to perfect': our calendar uses the event registration module and we wanted to add in a multi-step wizard to break the long form into sections. Because we are using the Registration contributed module for registration and our own Event content type, there are two separate forms to fill out. First, a user fills out the event details, saves and publishes the event, and then fills out registration settings. This wasn't so bad when we had a single page form for the event details, but once it was split into multiple pages, the UX tanked. So we spent a lot of time merging the two (technically, we just collect the registration settings in the event details and then programmatically submit the registration form as part of a custom module). In doing so, we were able to address a number of other UX concerns raised during development and demos:
- The Send Reminder template form in the registration modules requires the person creating an event to pick a date to send the reminder and enter the text of the email, and gives them the option to use "Tokens" as placeholders. A strong consensus from the team was that Drupal's token system may be too difficult to understand for the average Advocate user creating an event. We replaced it with a standard message that exists in our custom module. Now, the user can just check a box to send or not send the reminder on the day before the event.
- The registration module allows us to restrict registration to specific roles on the site. But the roles have more meaning to ILAO internally than to end users, and many have no meaning for event registration. By migrating registration settings, we were able to use the Audience field, which we were collecting for filtering the calendar, and associate those with a subset of roles and restrict permissions off of that field.
- Having the user publish the event and then completing event settings was not ideal. It would mean that if an event was published, there might be at least a few minutes where registration didn't yet exist for a live event. If it wasn't published, then the user would have to remember to go back in and publish after finishing the settings.
This was an instance where the custom work to get around some of the limitations of a contributed module for our use case while still keeping all of the otherwise awesome functionality of that module was worth the 6 days it took to do this. The workflow just didn't make enough sense to end users to NOT make the changes.
But more often, the value of investing in custom work is not so clear cut. A lot of times the change is to a text label or an existing field widget that isn't exposed through the Drupal UI. The only way to do that is with custom code. It may seem like "a little thing," but in reality, it raises maintainability concerns and of course, adds work now at the expense of building other functionality.
So, can we live with a button that says "Save" instead of "Submit"?
Can we live with a date widget that says "[time] to [time]" instead of "from [time] to [time]"?
It it usable for end users? Do we need to test to make a decision?
"we 'could' do all these things...but we'd launch in 2017 some time. I try to do things the 'Drupal Way' so that I don't leave a client with something unusable" -a Drupal developer on the cost of customization.
At the end of the day, it is largely a balancing act that requires someone on the team with UX skills who is willing to speak up for the end user (and both Dina and Teri fill this role very well), developers who can point out the effort involved and understand the ramification of any decision on future development and, ultimately, a willingness by the product owner to say "no, i can't live with that. Do the custom work." or "Yes, it's not the ideal solution, but it is still usable." or "Leave it for now and let's get this in front of users to see if this really is an issue or not and then make a decision." We are still working on finding the right balance.