Last weekend the Drupal Developer Days 2012 were held in a warm, sunny, beautiful and relaxed Barcelona. This is the first of two or three posts about the sessions there.

The conference was targeted on developers and a lots of sprints were going on around and during this weekend. There were a lot of sessions so I can not cover all that happended during Dev Days.

Designing and building for the editor experience

This session of Andreas Sahle and Daniel Nolde was about optimizing the experience editors have on a Drupal site. We all know that Drupal can be a PITA when it comes to easy content editing.  They gave some good pointers to think about when building a Drupal site. We are developers and not editors, we think different! Start thinking in roles, like what would a content editor or a translator do most of the time and how can I make his life a little more easy.

But how do editors think and what do the do? Most of them will think of content as pages. “How will this page look”. We, as developers, tend to think more structured in blocks, menus, node content, views etc. We have to start thinking in editorial flows. See also the discussion on Drupal.org.

An important part to think about is the choice to generate a page automatically or let the editor create the page. Most of the pages in Drupal will be a mixture of both, like a node page with an automatic generated views block showing related content. The hard part is deciding in what will be automatic and what will be manual on a page.

Start testing early with user stories and personas. And the permission system alone is not enough. This is not a replacement for an interface strategy! The interface should be intuitive, fast and efficient, avoid confusion and clutter. You can find some good tips in the slides below. Some things are quite simple as putting the most important thing on top, thinking about closed or opened field sets etc. And a lot of improvements are coming to Drupal 8.
But there are a lot of things in Drupal that can be frightening for editors. There are just to many options. Taxonomy for categorizing, menu structure, switching options. Blocks come in standard, views, views content panes, node blocks, mini panels etc. The good thing about Drupal is that it is a framework and you can extend and change it to overcome a lot of the problems.
They also gave some good pointers for modules that can improve the editor experience.
For select boxes you have

• Multiselect
• Chosen
• Select or Other
• Multiple selects

For dates you have date_popup_authored, for maximum length validation there is maxlength.
Think about using client side validation. This improves the experience lot. And set the message on the form element where it happened and not on top of the page with inline messages or inline form errors.
Finding and selecting content can be a hell of a task in a Drupal site.  Auto complete for references fields and links is not always the best choice. But you can improve it with linkit. That module will not only show the title but also gives some meta data back.
Modules that improve the creation and ordering of node references are nodeconnect and references_dialog.
Daniel Nolde has created the content menu module, that improves the administration of menus a lot.
For a complete overview see the slides

Architecting Drupal Modules - Report from the front lines

Ronald Ashri talked about the choices that a Drupal developer has to make when building a new module. Because when you build a new module, the path is not always clear. Let's say you want to add a JavaScript library to your module. How should you do that? All the choices....

• drupal_add_js
• Managing JavaScript in Drupal 
• Hook_library
• Libraries API

Or how should I structure my files?

• Everything in the root
• .module, .info in root. Images in images, JavaScript in js, includes in inc etc.
• Some in root, some in directories based on history, module evolution, style changes etc

And how should I name my files?

• .module, .info, .inc, .install, .test
• Occasionally throw in .theme, .install.inc
• Sometimes .modulename.thing.inc, classname.inc
• Myconventionisbetter.inc

And what about storing data?

• My table via hook_schema + dbtng
• Entities are the way to go - always (maybe?)
• Fields, then a field group entity or node to add what you are missing.
• Is your data content or configuration.

There are of course some important things to take in mind when writing a new module like:

• Separations of concerns
• Decoupled
• Consistent

A good thing to do is to define a problem and design not in a Drupal specific way. Your module solves a problem. You should be able to describe that in generic terms in plain English, not in Drupalese. This keeps you from overlooking possible solutions you otherwise might had missed.
We need to address these issues in the community and develop some common patterns for building modules like:

• OO patterns
• Drupal patterns: separate UI from core module functionality
• Service patterns: where possible decouple interaction points within the same module

We need to work on the methodology of writing modules and collecting start collecting and documenting patterns, discuss conventions.
If you are interested in this talk to Ronald Ashri. He wants to get this going. You can find his slides here and his latest blog post about this here.

/* Talking about code */

Jakob Persson is not really a developer, but he is the chief knowledge officer of Node One. And his session was all about knowledge and sharing of knowledge. Now that Drupal shops are getting bigger and bigger, they have to think seriously about knowledge management. You don't want your developers to solve the same solution twice. Sharing and spreading knowledge in your organization is about the flow of knowledge. And that happens when people talk to each other. And remember, plain information is not knowledge. People have to pick up that information. People should talk to each other, that's the most important thing.

So what are the reasons people don't share there information? You can think of thins as:

• “Knowledge is power” - Mostly not a problem in open source companies.
• Missing awareness of knowledge – They don't know the have the knowledge
• Lack of time
• Missing reward system
• Missing knowledge management awareness

So what can you do to stimulate people in sharing knowledge? Remember that the people are the most important so look there first. It's 70% about people, it's 20% about processes and it's  10% about technology.
Some things you can initiate to let people talk to each other. are

• Community of practice
• Daily stand-up
• Pair programming
• Solution match-making -  match people that have a problem and people who know the solution.

For processes you can think of a script for training new staff.  And as technology you can think of

• Wiki - You need a moderator to keep content up to date
• Site document
• Browser notes, a cool script in Greasmonkey that shows annotations on a drupal.org module page from your colleagues. 

Let people know that sharing information is really useful. Try to find some use cases where it worked. Make people feel useful. Remember, we have mainly intellectual capital. It's all in the heads of the employees.

Thanks

It was a great conference with lots of interesting session and I want to thank all the organizers, sponsors, volunteers and attendees to make this an awesome Drupal event again.

• Development
• Drupal
• Conference
• Drupal-planet