Drupal 7 was propelled, in part, by two major initiatives: improving user experience and developer experience. UX improvements made Drupal easier to use, better organized, and more elegant. DX improvements resulted in a more granular API that allows developers to hook into Drupal to add, remove, or override functionality and output at virtually any step while rendering a page.
But what about TX: themer experience? While Drupal 7 made huge leaps towards improving TX -- a more granular templating system, the Stark theme, support for hooks in the theme layer, the enormously powerful hook_page_alter() -- we still have a ways to go. Work is well under way to add HTML5 support to D7, while many of us are simultaneously brainstorm ways to eliminate all markup from core.
Here are some ideas to improve Drupal TX:
- Creating a library of reusable design patterns (guidelines, UI assets) in core that can be invoked by modules and overridden in specific instances or contexts. This approach would allow for a standard yet robust collection of UI components that developers can draw from. For example, the "spinner" or "throbber" associated with AJAX lookups should be a reusable asset in core. theme_progress_bar() is an interesting example of a semi-standardized UI asset in core. Imagine a world in which modules don't have to re-implement spinners and themes don't have to override them, piling CSS upon CSS, JS upon JS -- all to implement multiple versions of essentially the same thing!
- Implementing this library as a design pattern API. Just like the forms API and fields API abstracts form elements and data fields into hooks, a module could invoke UI components instead of rolling its own markup, CSS, and JS -- all of which would inevitably be overridden by a themer in an unwieldy template.php file.
- From dvessel: Separating the markup from theme hooks, which should focus on manipulating and preparing data. Instead, move markup and CSS to libraries.
- Module-style dependencies listed in a theme's .info file. Some themes require base themes or modules to display properly. This will be critical for implementing design pattern APIs or separating markup and CSS into libraries.
Identifying and reusing UI components in Drupal isn't a new idea. Bojhan Somers and Roy Scholten presented a session on Drupal 7 interface patterns at DrupalCon Chicago, and Jeff Eaton highlighted the need to document design patterns in a post called Drupal 8: The Road Ahead:
Drupal's toolbox of UI elements conventions has been growing since the day it was first released: we need to document it and expand it. In the 1980s, Apple demonstrated the value of providing clear guidelines to developers on solving common UX problems. Module developers need to know when to use Vertical Tabs instead of collapsed fieldsets, why they should utilize drag and drop tables, and how to hide unnecessary information from novice users. In addition, UX tools that are unnecessarily tied to specific use cases, like Color module's color picker, need to be broken out for cleaner reuse. Enhancing and documenting UX Pattern Library for Drupal will pay off in greater consistency throughout core and contrib.
What do YOU think? What else can we do to improve themer experience?
Please show your support on the Twitters with the #DTX hashtag.
Postscript: Why "themer experience" instead of "designer experience"?
Designers, in the strict sense, don't necessarily work with markup, CSS, JS, or even Drupal. Themers are unique: We must be comfortable with all of the above, plus a little bit of PHP. We're really front-end developers who may work on the design component of a site but must also translate those pixels into code.
Also... "DX" (developer experience) was already taken.