Acquia

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!

Download the full Drupal package to test or download the d7ux-popups-skin only, if you are keen on applying all the patches yourself. Place the skin into the skins directory of Popups module.

Last spring, I've read a Drupal theming book and was amazed by how things like the search and menu features for themes need special settings and theming while their parallel implementation exist as blocks. I was also deep in improving input formats (which was since then taken on by others) and did a comparison of what is not input format enabled in Drupal. That uncovered even more parallel implementations of things which should basically be blocks.

At Acquia, we are (among other cool things) hard at work to improve the user experience for Drupal 7 and as part of that effort, I am focusing on regions and blocks so that page building can be more unified then ever. You should know where to look to position your content, disable items on the page, set up custom text for pages, etc.

Help settings

I started off with the help settings. Drupal themes have a $help variable and that help text is usually generated by one or more modules. There are two independent user provided settings for help however. One can put admin provided help on top of the user registration and the contact pages. These are implemented as custom settings which add this help to the page in custom ways.

I realized that by making the $help item a region, we can gain certain cool features:

1. You could add custom help to any page you want. Cut out the two one-off settings and let the admin put custom help on any page they want.
2. Use your favorite input format to enter the text with your favorite WYSIWYG editor for it (or without that obviously).
3. The admin could completely disable display of help. Display of help could even be disabled for higher roles (site editors), for whom help might be in the way. Different custom help could be provided for different roles.
4. Admins could provide users with user customization possibility for the help display. This is already supported by Drupal for any block.
5. Custom set help text could be displayed on more then one page (eg. in a site area).

All this without coding, loosing two custom settings and making the help area a region. Pretty cool, heh? Check out the patch which needs a reroll here: http://drupal.org/node/240873

Content region

In Drupal, the main page content is output by appending the blocks put into the content region in this order. There is no way to put stuff above the main page content by default. Many themes worked around this in Drupal 5 and 6 by adding a content_top and a content_bottom region instead, so you can put stuff above and below the main page content. I believe "top" and "bottom" or "above" and "below" are keywords we handle inside the regions system. We move stuff around inside one region to order them. So I suggested we should have one region for content and make the "main page content" a regular looking block instead.

There are obviously some improvements needed to ensure that all themes can accommodate this block and that people cannot easily turn it off. These are being discussed. Patch needing review at http://drupal.org/node/428744

Site mission

This case provided the title hint for the blog post. Mission statement is a setting in Drupal at least in the past half decade. It is configurable on a plain textarea on the site settings page (no input format selection) and is hardwired in themes to show on the front page of the site. Or not at all if the theme customization options have it unchecked.

If we go a bit farther, we see we have a way to put text into a region of the website on one specific page here. Wow, sounds like a highly simplified version of what blocks can do ripped of all the flexibility (even input format selection).

Having mission as a region would allow us cool things like:

1. We can have a mission statement displayed on more then the front page (e.g also on the company team page).
2. We can have the mission statement only displayed somewhere else, but not on the front page (eg. only on the company team page).
3. We can set whatever input format we want so we can even display complex maps for example.
4. We can put more then one block into that region, so dynamic data can be output there via module defined blocks.

This all sounds too good so obviously there are some small drawbacks as well. Discuss in the issue queue: http://drupal.org/node/428800

Even more blocks, even more regions?

If you look at the site and theme settings, a few remaining items pop into your face, which will need attention once we have the above covered:

1. The footer message. This should just be one block among the others in the footer. No reason to make it special whatsoever.
2. Special search feature of themes. This is just a search block themed differently. Sites using this most often not use the regular search block provided by search module. As shown in Mark's and Leisa's video on themes, having a search setting on themes, while search module is not enabled, so you cannot even enable it is disconcerting. If the theme has a special place for the search block, it can expose a search region, where people can put their search block, and that would be themed specially in that region. All block visibility and other settings would apply to this one nicely and it would only ever show up once search module is enabled. Plus it would allow to put alternate search boxes into that region. Blocks exposed by ApacheSolr or any other search module.
3. Special main and secondary menu display of themes. Again, these are *already blocks*. Themes can just theme them differently when they are in their designated regions. Again, less theme settings, more visibility control, being able to swap menus in sections of the sites via other menu blocks, and so on.

I hope I managed to find some people who agree that special settings in site settings and themes should finally go and regions and blocks should take over the stage. They are already well developed and have all the features we need to implement the custom stuff we remove, but at the same time allow for amazingly more. Please help on the above three improvements and then we can move on to even more goodness.

Ps. Many people suggested that relying more on blocks is not good now that blocks module is optional in Drupal 7. Things like Panels are supposed to be able to take over the UI and set the layout for the page in more versatile ways, hence blocks module became optional. I believe that this does not mean that we should keep custom one-off settings around and broken theme settings alive. Also, Panels exposes all the blocks for the page layout setup, so people can just as well use them to set up their page.

When I was looking for topics to present at Drupalcon DC, I quickly realized I have not seen a Drupal module development presentation in the style I'd have liked to, so I should better try and deliver it myself. While playing with the idea, Peter Wolanin expressed his deep interest to join, especially since he shared the same views relating to what we should cover.

We designed our presentation to be complimentary to other presenatations, like the Gentle intro to Drupal Code which nicely explains high level concepts, but does not show the depth of what people can do, or the fun Pants.module session way back from Drupalcon Brussels, which shows a bit too much of what Drupal can do without explaining what people should not eventually do.

Interestingly, our session started off with why people should not write modules. After all, there are more then 4400 projects on Drupal.org, on which you can base your sites. If someone else maintains your code, it gets bugfixes and improvements while you sleep, you are on vacation or you sit at a presentation. However far these precooked modules get you, you will always find missing items which need custom development. Then and only then should you think about writing modules.

Therefore we focused our session around the alter hooks, modifying existing menus, form layouts, submission workflows, and so on. We did include an example of a complete module with SQL code and all, but quickly jumped to talking about why you should not do this at home. We might have picked a bit over-the-top examples for those not familiar with PHP, but the basic idea was to show off what you can achieve with a few lines of simple code, and then let people read the resources (books, cheat sheets, articles) with that in mind.

All-in-all, I think your module development should enter this era, if you did not focus already on this approach. Get your general improvements to the modules in question and use the alter, nodeapi, user, etc. hooks to modify behavior whenever you need to add, remove or modify capabilities for your own needs. Less code to manage for you, better for the community that you find the bugs in the common modules, easier the upgrade path when it comes to move one version ahead.

Peter was quick to post our slides while in DC with our speaker notes included and the sample module we compiled to contain all our examples. The sample code is a single installable Drupal 6 module with all our examples implemented. Happy coding!

Well, although I was the first employee at Acquia, I somehow managed to keep myself out of actually using the product on my own blog up until now. While I know we have a great product, built up from superb community contributed Drupal modules tested to work together, distributed under the GPL, I did not find the time to actually migrate my personal blog to this distribution of Drupal.

One of the factors causing this was that I actually ran Drupal 5. Wow, another shocking revelation about the Drupal 6 maintainer! Especially considering that I only run the contributed modules Pathauto, Mollom and Tagadelic, and these were ready for Drupal 6 already. In fact, I've tried to upgrade to Drupal 6 already, and in preparation to that, I've got rid of some contrib modules, replacing Flickr syndicated images with Flickr's own image script display for example, thus avoiding using Drupal modules for that. This helped me prepare for an easier Drupal 6 upgrade a few months ago. Except I never got around to actually doing it.

Being a maintainer of this simple blog, as a user of the above mentioned three contributed modules, the Drupal 6 based Acquia Drupal upgrade was the most logical step at this point. I've made a backup of my source code and uploaded files, as well as the database. Did a test upgrade on my local machine and it went great right from Drupal 5 to Acquia Drupal, even picking up the moved contributed modules. It was a piece of cake.

On the test upgrade, I've even played around with using the built-in Acquia Marina theme, and found it great, so switched to that from the Alek 2.0 theme. Because these three modules are included with Acquia Drupal, I could just use it for my blog from now. Additionally to keeping what was in already, the Drupal 6 upgrade allowed me to track updates to my modules, add support for OpenID, and so on.

If you are still considering upgrading to Drupal 6, Views 2 being out and Acquia Drupal soon upgrading to this stable release, it is a great time to switch. Drupal 6 is well tested in the field, as Dries shared it on the last Lullabot podcast, five hundred active sites are deployed daily based on Drupal 6. My site is just one of them for today.