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:
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.
Use your favorite input format to enter the text with your favorite WYSIWYG editor for it (or without that obviously).
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.
Admins could provide users with user customization possibility for the help display. This is already supported by Drupal for any block.
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:
We can have a mission statement displayed on more then the front page (e.g also on the company team page).
We can have the mission statement only displayed somewhere else, but not on the front page (eg. only on the company team page).
We can set whatever input format we want so we can even display complex maps for example.
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:
The footer message. This should just be one block among the others in the footer. No reason to make it special whatsoever.
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.
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.
I was initially a bit surprised seeing Mark and Leisa running a physical suggestion box in Washington DC for the Drupal 7 user experience rework. After all, we had IRC channels and twitter for the session rooms to discuss presentations, forums and groups to get input and all kinds of nice digital tools to discuss ideas. However, using paper probably made for a good way to actually drive people to the table, get them pull a piece from the stack and write down their suggestion. This allowed Mark and Leisa to engage them in a conversation, get a feel of what they think, and resulted in a better outcome compared to just using all these nifty digital tools.
I've had a very similar experience with the drupal.org redesing on paper. Initially, I had this idea to set up a website with an image annotation tool and get people discuss the wireframes using that. Drupal had a stable module called fotonotes, which mapped the library originally used to build out the Flickr feature to Drupal, but I liked the concept of the image annotate module better. This later one was based on jQuery UI, but had some flaws. So I contacted the author and sent in fixes and test results. As the project page says:
Compared to Fotonotes (another module for placing notes on images), this module uses the latest jQuery (shipped with Drupal 6) and the state of the art jQuery UI module, while Fotonotes is dependent on an old (last updated in 2006) custom JavaScript library.
After all my work put into making this work, I realized we might as well have a better way to bootstrap our work. We were just heading into Drupalcamp Germany in Cologne, the Drupal.org upgrade sprint in Cambridge MA and the Drupal.org redesign sprint in Paris in succession. All these events could use materials to look at and discuss with the drupal.org redesign. I figured that having the wireframes on screen does not allow for all the flexibility that we need.
So I ended up printing out all the pages of the redesign from Mark on my home printer and went on a "world tour" with them. Using the printouts turned out to have a fantastic effect on our productivity, since we could use them in an amazing number of ways:
In Cologne, we used the printouts to define what kind of major feature areas we need and delegated research to some people. Having been able to see multiple pages at once helped us identify patterns much more easily compared to just staring at pages one by one on screen.
In Cambridge, we looked at the pages to identify the initial feature set for our Solr rollout and used to target project module improvements so they are implemented with the target features in mind.
In Paris, the pages were used by designers to discuss remaining tasks, they were used to note problems with missing comment styling elements for example. People picked up pages and run with them to implement landing pages and design elements. We even scored a coffee stain on one of the pages, showing people actually made the mockups of their own.
Finally (so far), in Washington DC, we were able to sit down with Mark Boulton and discuss all the notes the themers and feature implementors made and got annotations on some of the pages from Mark.
The printed pages were better then just looking at the digital versions, since we could code on our laptops while looking at the printouts, compare different pages, sit around pages and discuss and have all this goodness at our fingertips.
How can the notes on paper get fed into our process? Well, through the sprints, people working on features were there in person, so they could see and absorb all the notes. Since we are more open now with tasks better defined and broken down for a bigger team of contributors, it became important to make note of the diversions we are going to take from the design. Therefore I made scans of the pages we discussed and documented decisions on the redesign implementors group. There were also finer grained themer discussions, which were rolled into the themer TODO list.
The spotlight time for paper in the drupal.org redesign might be over with issue queues and wiki pages taking on, but it was nevertheless a fun time using these printouts so far.
Unfortunately I've arrived late enough in Washington DC for Drupalcon to not be able to go to the Presenting You! Workshop by Emma Jane Hogbin. While I've been on stage in the past 20 years from presenting poems through singing in musicals to doing actual tech presentations, I feel I have some ways to go to improve my stage skills in terms of presentations: both slides and delivery. To that effect, I did manage to go to her presentation with the same title which was put on sometime mid-Drupalcon. One of her points which warranted this blog post was: start now to prepare for the next Drupalcon!
She recalled being singled out for sending in the first proposals for Drupalcon DC and therefore "cheating" on the voting system to get the longest time under voting. However, she points out that the underlying mechanics of Drupalcons are well known. We know a Drupalcon is always coming up (this time in Paris early September). You might have presentation ideas already. So why not start mapping out your message, building your outline and proposal already? As soon as the call for papers will be out, you can post your session and enjoy your well prepared presenter experience.
What happens, if the exact time for Paris turns out to be unsuitable for you? What if the plane ticket prices will go over the roof? Well, you will still be able to find local Drupalcamps and other types of small conferences where you can spread your message. You can even target both presenting at your local events first and then go to show your content off at Drupalcon with even greater confidence. So getting your act together sooner then later might get you even more fame.
Need advice for planning and laying out your slides? I've had the chance to actually sample in real life and consequently buy the Presentation Zen book from Garr Reynolds back when I was in Cambridge MA to work on the Drupal.org upgrade. After reading it, I decided to make the jump and try this "simplified" slide style, and refrain from overwhelming my audience with too much information. Overloading my slides with information was a mistake I believe I made many times before.
Eventually I've driven the Module development kickstart presentation we prepared and delivered with Peter Wolanin and my portion of the Multilingual Drupal panel with the zen approach in mind for Drupalcon Washington DC. With the development slides, there were lots of source code examples to show, so it was hard to apply these principles, however, with my intro to Drupal core multilanguage, I could quickly skim through a huge amount of knowledge with just summarizing the most important details with impressive slides.
Comparing that to the Do It With Drupal slides I had on the same topic (albeit with a significantly bigger scope), my newer slides have a lot less in themselves, but in turn direct the audience to what I have to tell. As Garr points out, a good slideshow should leave the audience with a desire to learn more. The best strategy to achieve that seems to show off the cool stuff and leave off the details for further exploration. While this might sound unfair at first, realistically, telling everything possible to your audience is not gonna work anyway. The reason you have a presentation is to fire up people and not to educate them with all the details you have under your sleeves.
Garr makes the point that if your slides include all the information you are gonna tell (and you gonna tell a lot), then why would you be there at all? If you treat your slides as if they are the handouts for the conference then you are not required in person. People can just read the printout and move on. To have a great presentation you need to engage your audience, you need to make them focus on you and your message. (And after the event, you can still publish your slides with presenter notes included, so people joining in later can still understand some or all of your points).
These are all just tiny samples of what Garr has to tell, and even these points he presents better, so I'd suggest making the jump, getting the book now and starting to prepare for your next presentation focusing more on your audience instead of your topic. See you in Paris!
I've had the luck again to join Jose A. Reyero and present about the multilanguage features of Drupal and its contributions at Drupalcon DC last week. I've had a presentation on the topic at Drupalcon Szeged last August, and we had a session on the topic at Drupalcon Boston last March with Jose. So looking back it almost felt like we are going to repeat ourselves.
What made this time special however is that we have a huge amount of experience gathered from users of the modules and Drupal core itself, and we see our strengths, real use cases and problems better. Previous sessions covered the concepts, but this time we had the fantastic Roger Lopez join us as third panelist, who talked about the Drupal 6 based multilanguage platform used to host Britney Spears', Pink's and other Sony stars' sites already. There was a nice Drupal.org front page post on their solutions and contributions while we were in DC. It is well worth a read!
So the panel ended up with me talking about Drupal core and some broader issues, Jose talking about Drupal 7 plans and i18n features and Roger talking about solving some of the tasks they have faced on Drupal 6 with core, the well known contributed modules and some custom development. He also called for involvement in some of the unresolved issues in his presentation. Finally we took some great questions and wrapped up.
I believe this was our best Drupal multilanguage talk so far, but unfortunately it was not videotaped. So all we can share with you are our slides in presentation order. Enjoy!
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!
A couple weeks ago, Dries posted a call for sponsors for efforts to upgrade the Drupal.org site with its existing functionality and design to Drupal 6 and then start work on the redesign, new features and theme implementation. We are on the first phase at the moment, and sitting at the boardroom of One Laptop Per Child in Cambridge, Massachusetts. We are getting to second day's close, and already achieved an impressive amount of progress. Here are some of the most exciting items.
We need to admit, these days, people are more reliant on contributed modules then Drupal core. What is in Drupal core is taken as a given and some requested new feature would ever come in a contributed module in a reasonable timeframe for a Drupal site builder. People are not waiting for Drupal 7 to get a feature, people are active in the issue queues to get things done sooner. Drupal core is supposed to lay the foundation and be stable for long, while contributed modules can experiment, change, and add new features on a much more active pace. So as a result, Drupal core can keep using the "will be released sometime" approach, and it does well with Drupal 7 allowing for more improvements by not keeping the "every 12 months" release cycle intact. With contributed modules on the other hand, much more frequent releases are anticipated with new features introduced through a shorter timeframe.
What's common in both, is that for longer lasting development, overseeing progress on major areas like the file API, the database layer and so on is important, while on shorter release cycles, knowing what is required for the release to be fixed, and whether the project is on track or not could be key to get contributors. So having (A) overviews of project progress and (B) checklists of things to be done is increasingly needed on drupal.org. There are a few things people did about these needs recently, and all have their advantages and disadvantages. There are some reasonably new approaches, so I decided to highlight the ways I see people approach project planning on drupal.org.
Drupal.org runs the infamous project* module family to help micro (and not so micro) projects run around the Drupal core. These include modules, themes and translations as well as installation profiles. Currently, drupal.org hosts more then four thousand (yes, more then 4000) projects, with support for a CVS space for hosting the code with branching and tagging, as well as a release system tied to those CVS concepts. Projects can also have an issue queue, which people can submit issues with, covering bug fix requests and suggestions as well as new feature requests. So a project's issue queue can be quite busy, but it is the only "core" way to track what needs to be done, who is assigned to these tasks, who is working on them, what is the current status and so on.
So eventually people started to experiment building new tools on top of project issues to help manage project planning, overviews and checklists. Here is a hopefully comprehensive list of what tools people built on top:
I had many requests for a case study on how we did the Drupalcon Szeged 2008 website. Granted, it was a long time ago, I just had time recently to do a writeup, sprinkle it with links to modules we used and attach some images for your viewing pleasure.
While it is waiting for consideration for a drupal.org front page promotion, since you are reading (an aggregation of) my blog, you'll get to see The tech story behind the Drupalcon Szeged conference website now. I hope it will help you get some insight into the good and bad decisions we made while we built the website, and the technology behind certain fun functions, like the registration system, the drag-and-drop scheduler, the wiki whiteboard and even the dynamic projection screen at the venue entrance. It was certainly fun to build.
Watch out, the next Drupal fest, Drupalcon Washington DC is coming up quickly in just two months!
Special thanks to Robert Douglass for proof-reading and fixing some of my non-native English writing.
I am curious if these codesprint efforts will be useful for other projects. I think it's fantastic so many people are organizing, but I wonder if whatever form the bulk of this takes will be released - or is it mostly a one-off effort that is too customized to be generally useful elsewhere?
I thought it would be useful to have a blog post about this instead of just sending the reply in the comments, since I think this is an important topic to talk about.
As Niel pointed out, the modules used on Drupal.org will get attention. I've just started to use the "drupal.org upgrade" tag over the weekend to mark issues requiring an attention for the Drupal.org upgrade: http://drupal.org/project/issues-term/346 General purpose existing modules used on the site including simplenews, comment_upload, comment_alter_taxonomy, image or imagefield, and so on will be tested and fixed where required. New modules will be used on Drupal.org and will get similar attention: CCK and Views are the first obvious contenders (right, Drupal.org is not using these modules as of now).
Drupal.org runs some custom core patches to improve performance by handling master and replicated databases. We will take a deep look on these changes and will implement a similar or better solution for the upgraded site based on Drupal 6. Our caching setup will have similar attention. Having this insight we will be able to document what best practice we found to scale drupal.org. This will join documentation on ways to make Drupal more scalable. Such efforts on Drupal.org also helped improve general performance in Drupal itself (both current stable and current development versions) in the past.
The upgrade is planned to omit some of the current features on Drupal.org such as the current search implementation and the custom Drupal based distributed login system. OpenID and a new search implementation are about to be implemented in place instead. It will be easier to find stuff on drupal.org for your day-to-day development and you will be able to reuse your Drupal.org account on any OpenID supporting site.
These items above all happen as products of our upgrade, even if there is no redesign. While all of the above items are great by themselves, the redesign will be the biggest hit. It will help you use a more fine grained navigation, move around the Drupal.org subsites seamlessly, find and understand modules needed for your projects, and so on. But what's even better is that it will be a site you can point possible customers to. It will help you market your services, consulting, books, courses and so on more effectively, since the Drupal site itself will do a better job to help the community and the project market itself and flourish in the times ahead of us. If you earn (part of) your living from Drupal related work, this will give you a boost. If you do not yet earn (part of) your living from Drupal, you'll be more tempted then ever to do so.
We are making exciting things happen, but your help is still vital to make this a reality. You can help by donating some money to get the expert teams together (use the ChipIn widget in this post) or by contributing to the sprints yourself either via the issues listed at http://drupal.org/project/issues-term/346 or by coming to the sprints. Thanks for being part of getting this huge improvement into production!
Drupal.org is in need of some makeup, and we know this quite well. It runs on the old and stable Drupal 5 codebase, while Drupal 6 is out for almost one year (and is just as stable but way more useful especially with all the new contributed modules). Drupal.org also sports a design which was last refreshed in 2005. So it does not really give justice to the software it helps to flourish. Therefore the Drupal Association hired Mark Boulton to help with a community based redesign of the site, and the results are outstanding. Now people from the community need to get together and actually implement it.
We are set out to make progress quickly, so Dries Buytaert decided to organize a series of developer sprints where people get together and plan and execute on the redesign. First we need to upgrade drupal.org to Drupal 6, so that we can work with up-to-date APIs to implement the new features. Then we can move on to actually implementing the redesign.
Thanks to Acquia letting me put some of my time on this job and my scheduling over the holidays and some free time put on these tasks, I've contributed work (to upgrading the existing theme, eliminate modules, help upgrade some other modules, etc) and had quite a few overviews, blog posts and call for actions. Now, these code sprints will actually get the real people together, so for example, two lead maintainers to the project module suite will be in the same room to implement, discuss and review updates to Drupal 6. We expect to make good progress this way.
However, your help is still needed! While some exceptional companies help fund and plan this sprint already, we need more funding for some of the people and also other members of the community who are willing to join and do the work. Sprints will happen in Cologne, Boston and Paris over the next few weeks (exact timing and more details in the drupal.org front page post); and we expect we will continue working on it while in Washington DC for Drupalcon and onwards. We found these places with people to help in mind, not so that we can travel around the globe (there is little overlap between the North-American and European sprints in terms of people, but some overlap is required for consistency in setting goals and planning). I've already contributed to the chipin and encourage you to do so!
If you are more into help doing the work, and you're available to attend one of these sprints, and if you have the time and dedication to work on the drupal.org redesign before, during and after the code sprints, join the redesign infrastructure team and let Dries know in the comments of the drupal.org post, and we'll figure out how and when you can best participate.
The printed pages were better then just looking at the digital versions, since we could code on our laptops while looking at the printouts, compare different pages, sit around pages and discuss and have all this goodness at our fingertips.
I had many requests for a case study on how we did 
Drupal.org is in need of some makeup, and we know this quite well. It runs on the old and stable Drupal 5 codebase, while Drupal 6 is out for almost one year (and is just as stable but way more useful especially with all the new contributed modules). Drupal.org also sports a design which was last refreshed in 2005. So it does not really give justice to the software it helps to flourish. Therefore the Drupal Association hired Mark Boulton to help with a community based redesign of the site, and