It is that phase of my life! I'm just turning 30 in a month, working with Drupal for 7 years and just had my third Acquia anniversary a week ago. Time to look back and evaluate how things went, all the good and bad things; even better if the wisdom can be shared with others. This was part of my thinking when I submitted the session titled "Come for the software, stay for the community" for Drupalcon Copenhagen.
Ever since Drupal uses major versions for compatibility changes and minor versions for bugfix and security updates (since Drupal 5), it was most often the case that a new minor Drupal release included bugfixes and security fixes packaged into one update.
Early on in the development of Drupal Gardens, it was clear that we needed some type of simple Views-like functionality. You know, letting users set up simple lists of content beyond what is included with Drupal 7 core, but simpler than the Views UI which can be quite intimidating to first-time users. Drupal Gardens' goals include making Drupal easy to use, and that sometimes comes with feature sacrifices. You cannot do everything you could do with a self-hosted solution, but you can do most things easier. If you exceed what Drupal Gardens can do, no worries, simply export your code and database and adopt any Drupal 7 module.
So when looking at our options for implementation, we had the obvious choice to roll our own code and live with that or postpone this feature to get released with Views D7. There is some very nice discussion going on around the Views D7 UI at http://groups.drupal.org/node/64143 and it is evident it is not a small task. For Gardens, we needed a very easy to use UI with a limited feature set. And of course there is a module for that, its called Simpleviews, from Jeff Eaton himself.
We decided to contribute to the community efforts within our limited scope, so we took Simpleviews and upgraded it to Drupal 7 and posted it for review in the issue queue. But Simpleviews depends on Views, right? So without a Drupal 7 version of Views, how useful could that all be? Whether by chance or Jeff Eaton's genius, Simpleviews is actually a pretty standalone module. It only requires Views where it clears the Views cache. The architecture of Views lends itself very well to these kinds of alternative interfaces because it works with array dumps, so an alternate UI module can just have its own ways to generate these arrays.
The original Simpleviews UI screenshot from the module's page
Simpleviews itself stores all simpleview settings in a database table and generates Views arrays out of that. So if we don't have Views, we can just look at the settings in the database and generate output based on that. This way we get the best of Simpleviews by being forward compatible with Views if we later decide to include Views in its entirety, while we can have a very simple and lightweight module to generate output for the small use-cases we cover today. Because Simpleviews is indeed very simple, the backend for generating pages based on the settings there is also surprisingly simple.
My initial version of this backend module was 167 lines with plenty of code comments, which covered all kinds of funky Simpleviews features, except exposed filters. Honestly, we attempt to practice restraint around adding more features to it, but currently it already grown to 460 lines to support some additional things like taxonomy term based filtering and style support for blocks. It is still a little-bitty module compared to Views.
What are we going to do with this feature in the future? Well, we are still not decided yet. We certainly want to provide a lot more Views-like functionality and features this year, but we are starting with design and UX first -- and then we will decide what back-end supports it best. We might use all or some of Views in the future, we might tone down its UI, we might use another alternate UI, we might keep using an alternate backend. It is an ongoing discussion at the Gardens team at this stage. I believe that there is no point in publishing our current backend module on drupal.org given its interim nature, but that does not make it closed source or unreleased. Any Gardens site that is exported will include a copy of this module, and it is released under the GPL.
What do you think about our approach? How would you make the Views user-experience so easy anyone could use it without getting help? If your suggestion pertains to the Views module itself, please contribute to the existing groups discussion, otherwise leave a comment. Thank you!
At Acquia, among other Drupal 7 UX improvements, we've been working making the overlays work as designed by Mark Boulton and Leisa Reichelt. The plan includes a header with two levels of fixed items, which all invoke overlays (almost full window popups), showing above the current page. Instead of reinventing the wheel, we started working towards porting the existing Popups module to Drupal 7 and implementing the Drupal 7 overlay looks via a skin, so we can leverage the existing work, testing and wisdom from the module.
Due to how hard JS is to debug still with Firebug, we faced some issues, but given that we are over those, we have the basic overlay looks ready and facing some other engineering problems which are pretty much standard with how the Popups module works. For integration purposes (and because our proof of concept version of the header did not look as good), we worked with Young Hahn's header patch. You can find my modifications to that to work with overlays on the issue. While Young's patch does not yet map to the D7UX plan to have a fixed set of top level items and a fixed set of lower level items, redefining the D7 admin information architecture, for working out the overlay, it is pretty good as it is now.
Since we were working on (a) porting Popups module to Drupal 7, (b) create a d7ux skin for it, (c) a header which we did not use in this experiment, and Young Hahn was working on a header which needs a patch and images added, I've decided to pull together a quick Drupal package for your testing pleasure. The distribution includes a D7UX install profile which should be used so that the proper modules are set up. It also includes the latest header patch from Young's issue (which has my popups class modifications) and the images and sprite from there. The ported Popups module and the D7UX skin for it is also included.
While I am searching for the best ways to collaborate on the overlay (and possibly also on the header), so we don't need to work back and forth in issue queues, possibly stepping on each other's toes, I am also sharing the D7UX Popups module theme as a separate package, so those fond of applying patches and adding up images from different sources can keep up with development.
There are some pretty significant known issues with the overlay/popups. The biggest one being that since the overlay page is loaded into the same DOM tree (same HTML document) as the rest of the page, ID collissions can easily apply. If you load up a node edit form on a page with a node edit form, #node-edit will appear twice. Behaviours rightly assume that an HTML ID will ever appear once, so they do not expect this situation. This breaks some behaviors. Also, since Popups modules opens new popups on clicking on new links without closing the previous ones, this can also happen if you open two node forms in the popup in a page view. There are also smaller styling problems (eg. overlays on lower layers move up a few pixels when new popups are opened), but we should focus on the significant issues first.
I am looking at breaking down the Popups module (again) to core patches so its parts can be included in core. That would assume that the basic working of it (loading up new HTML-particles into the same HTML document) can be made work without major issues. The great maintainer of Popups module, Tao Starbow worked on quite a few core patches, but unfortunately those got the fate of the overdebated. The issues were split up, then some of the individual pieces were discussed to be over-generalized and in other areas, the scope of Popups in core was narrowed considerably to some confirm forms. No doubt Tao got burnt out from there.
That was way before Mark and Leisa suggested using the overlay technique for the Drupal 7 administration UI. I hope we can revive and refocus some of the issues and get this effort going faster, so we can focus on usability of the actual admin screens showing up in the overlays. Rendering API, JS and CSS wizards welcome! Look for my upcoming blog post on a plan to get this into core!
My previous blog post entitled On a mission to improve page regions in Drupal 7 outlined how special casing things like custom help settings, the mission statement and footer message make understanding and using Drupal harder and general assumptions not being applicable to set text formats or visibility on such items. Having the somewhat special content region was also another example.