Drupal

Drupal related posts by Gábor Hojtsy.

Time to prepare for Drupalcon Paris!

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.

Presentation Zen book coverNeed 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!

Drupalcon DC - Multilingual Drupal panel slides

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!

UN Flags photo by clearrants on Flickr

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!

Presenter commentary for "Drupal Module Development Kickstart"

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.

for those about to code we salute you

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!

Second day report from the drupal.org upgrade sprint

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.

Self-made project planning tools on Drupal.org

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: