Programmer

Overview

iwanttospeak.net is a worldwide language learning community. From the initial idea to its beta launch only a few weeks passed. This shows Drupals power and flexibility in "rapid prototyping". The goals were: Possible support of all world languages (managed by the community itself), Private messages, Custom User Profiles, easy but failsafe geographical tagging of users for a worldwide proximity search, ...

Agenda

* Rapid Prototyping to speed up developement
* Customizing Themes and Modules
* Multilingual support
* Geotagging of Users and worldwide proximity search
* Usability improvements

Goals

During this session we want to share our experience using Drupals army of contributed modules for „rapid prototyping“. We also would like to discuss, which contributed modules are essential for developing websites with Drupal. We think that knowing a number of contributed „keymodules“ is absolutely essential for developing websites with Drupal.

We will show how we used the Bio module for collecting all user related information during the registration process and storing this information as nodes.

A key feature of iwanttospeak.net is the worldwide proximity search for users. We will show how we used Googles API for the geospatial information and how we use this information to calculate the distance between users worldwide.

iwanttospeak.net is currently available in 9 languages (including Russian, Hungarian, German, Italian). All translations were contributed by members of the iwanttospeak.net language community with little technical knowledge and no Drupal experience. We will demonstrate how we used i18n module and a slightly modified version of the Localization client Module to let users directly translate the interface.

Resources

www.iwanttospeak.net

Overview

Messaging and Notifications are two complete frameworks for handling subscriptions, notifications about site events, or simply sending out messages using any kind of delivery method. The goal of this presentation is to show the new developments we've been building on top of these frameworks and the new and exciting possibilities that have happened in just the past couple of months since the first beta was introduced at DrupalCon Boston.

Background

Your Drupal site is generating all kinds of mail for all kinds of reasons: You have giant announcement list, a few dozen group discussions, automated content notifications, send-to-friend messages, petitions and postcards.
Now there is the Messaging framework that attempts to abstract all the needs of other modules regarding the sending of user messages, adding also a centralized way to manage all your message templates, filtering, and delivery settings. The Messaging framework accepts different kinds of plug-ins for different sending methods, like different email modules (mimemail, phpmailer), SMS, web notifications, etc..
The Notifications framework, which in turn uses Messaging as the delivery layer, attempts to simplify building subscriptions-like systems in Drupal. It is a collection of modules that provide a core set of notification types and developers API for building specialized user interfaces, use multiple message delivery methods (including email, sms and IM) and developing custom subscription types.

Agenda

* Moving beyond 'e-mail only'; let the users decide how to interact with your site.
* Enabling round-trip email discussions for any content type or topic
* The Messaging Framework - More than just email, IM & SMS plugins.
* Building on the Messaging framework: free message templating and sending for other modules
* Extending the framework with your own modules or distribution types
* Notifications modules - How to configure & use subscriptions and notifications.
* Integration example: Organic Groups now using the Notifications framework
* Real life usage: Some examples of live sites using this solution.

Goals

* Show you we can move beyond the mail only paradigm to sending and receiving messages through different methods.
* Raise awareness about new and exciting possibilities for user interaction or why just sending emails is not enough nowadays.
* Let other developers know how they can build on this framework and abstract message sending from their modules.
* Overview for site builders of how to set up a full featured subscriptions/notifications solution
* Present the latest developments built on these two frameworks and some new plug-in modules

Resources

http://drupal.org/project/messaging
http://drupal.org/project/notifications
http://www.developmentseed.org/tags/messaging

Overview

Panels2 is a powerful system for organizing and marshaling drupal sites, but the API has a steep learning curve. This session is about breaking the API down into manageable pieces. So, if you've ever wanted to:

• 'Panelize' your modules, like what og_panels has done,
• Extend Panels by writing new plugins that add new pane types, new styles, new layouts, new contexts, etc.,
• Get an authoritative overview of all the ways your modules hook into and take advantage of the Panels API,
• Toss some of your Panels-implementing ideas out and get feedback on them right on the spot,

then this may be the session for you! We'll divide the 90 minutes into two parts:

In the first half, Sam Boyer (sdboyer) will provide a fast-but-structured overview of how the Panels API works, and where your module can plug in.

In the second half, participants will be free to ask questions about techniques and approaches to implementing the Panels API; Sam (and/or other participants) will respond with comments & suggestions on how to bend Panels to your particular module's need.

Agenda

• Provide and quickly run through handouts that overview the Panels API. Lots of space for notes!
• Quick overview (with visuals) of how the Panels API handles editing and rendering.
• Overview of the general logic behind the Panels plugin system. We'll also cover panels-specific hooks.
• Open it up for questions.
• When we're down to 5 minutes, Sam will stop the action and record any questions that haven't yet been answered; we'll do our best to answer those questions in public & online later on.

Goals

Panels is a complicated beast; trying to cover the API in detail would be an exercise in futility. Instead, this session should provide participants with a framework for approach Panels in a productive way. Each half of the session should do that in a different way:

• The first half will provide a working understanding of Panels' various moving parts, and when and where you can hook in.
• The second half will provide concrete examples of how people are thinking of implementing Panels, and Sam's answers will suggest how to go about approaching each of those ideas.

Ideally, the combination of the two should provide all participants with a decent grounding in how to 'Panelize' drupal.

Resources

The only thing people need to bring is IDEAS! The second half will crash and burn if people don't bring big thoughts on how to implement Panels in new and different ways.

Important Note: this session is primarily geared towards developers writing modules that are or will be kept in the official Drupal CVS repository. If you have client-specific Panels needs that are unlikely to be genericized for use by the whole drupal community, please find another venue to raise those questions.

Overview

Drupal is increasingly making a place for itself among museums around the world. As a strong and flexible framework Drupal can be a good fit for these sorts of organizations.

This session will be a case study and lessons learned from two museum web sites Palantir has built using Druapl 5: The Indianapolis Museum of Art and the Art Institute of Chicago. Both sites offered a number of unique challenges but also the opportunity to share amazing and diverse content.

Agenda

* Bringing Drupal into a large, established web presence
* Designing a modern site that still has a strong artistic feel
* Bridging Drupal to legacy multimedia databases, such as museum collection databases
* Drupal as an application framework
* Existing open source museum tools

Goals

We hope to present both the challenges and rewards of integrating Drupal with large, established systems such as those of museums. We also hope to give some insight into how to bend Drupal farther than you ever thought possible.

Resources

Indianapolis Museum of Art: http://imamuseum.org/
IMA Drupal.org Showcase: http://drupal.org/node/188312
Art Institute of Chicago Collections: http://www.artic.edu/aic/collections/
AIC Drupal.org Showcase: http://drupal.org/node/279485

Overview

Drupal 6 includes a simple lazy-loader for page callback functions. Drupal 7 will feature a completely automated introspective code registry, allowing Drupal to skip the most time consuming part of a page request: The bootstrap. But how can you structure your modules to take full advantage of this new world?

Join Larry Garfield (Crell) and chx (chx) to discuss and develop a set of best practices for module design to take optimal advantage of the registry. Expect some discussion of OOP practices as well, since it's Larry and chx. :-)

Agenda

* What the code registry is and why it is. (Larry and chx)
* What the code registry is not. (Larry and chx)
* OK, so how do we use it? (discussion)
* Draw up recommended guidelines to be included in the handbooks.

Goals

You should come away from this session knowing how to speed up your modules dramatically through a simple cut and paste operation. We also intend to have a publishable set of guidelines for all module developers to help them do the same.

Resources

Past discussion and issues:

http://drupal.org/node/146172 (Drupal 6 page callbacks)
http://www.garfieldtech.com/blog/benchmark-page-split
http://drupal.org/node/221964 (the registry issue)
http://www.garfieldtech.com/drupal-7-registry

Overview

This session will discuss how Drupal finds and renders pages. In other words, how a Drupal path (like node/4) is used to deliver a page to your screen. This will be a high level discussion, but with some reference to implementation details.

Agenda

• Overview of the menu system architecture
• The flow from request to page rendering in Drupal 6
• Page rendering in Drupal 7
• Alternative page renderers - e.g. XML and JSON
• What we've enabled, what's left to do

Goals

This session should give the participant an overview of how these central Drupal systems work in Drupal 6, and how they may change in Drupal 7. We will focus on how page rendering may change, and what other advances those changes enable.

Resources

It would be helpful to have a basic familiarity with how pages are defined using Drupal 6 hook_menu, and what a Drupal path is.

Overview

The navigation menu, breadcrumb links, primary links, etc are important for users to be able to navigate your site. Is the way they work in Drupal 6 optimal for usability? Are there better default behaviors we could build for Drupal 7? Could we better accommodate non-standard browsers (e.g. screenreaders)

Agenda

* Fixes up to now (e.g. http://drupal.org/node/270917)
* Default markup
* Your suggestions and input!

Goals

This session will focus on Drupal core, not on contributed modules which can alter or enhance the built-in menus and taxonomy.

By identifying usability problems and possible fixes, this session will hopefully result in some fixes being identified to be addressed in core.

Resources

You should have used a Drupal 6 installation and thought about how you navigate using menus and taxonomy, and how you arrange or assign menu links and taxonomy terms.

If possible, think about "scalable menu parent choosers" and hierarchical select widgets. See: http://drupal.org/node/191360

Usability testing at the University of Minnesota and University of Baltimore suggested that new Drupal users would benefit from more example content in default installations. There are also technical limitations to install profiles which have prevented their widespread adoption in contrib.

This workshop will examine the existing 'default' installation profile, the 'minimum' installation profile (if it's committed by then), and discuss additions to these and other possible profiles for core (single user blog etc.)

The session will also discuss the current limitations of install profiles for developers, and look at alternative mechanisms ('packages', 'install profiles as modules').

Resources:
More defaults in the default install profile: http://groups.drupal.org/node/11691
RFC:Installation profiles as modules: http://groups.drupal.org/node/11548

Overview

Google has shown us that search matters. Drupal's core search has strengths as well as weaknesses. What are they and how are the weaknesses being addressed? What new search options have emerged, and how does one evaluate them?

Agenda

* Core search in Drupal 7: What needs to be done?
* Minnesota Search Sprint: What got accomplished and where does it go from here?
* Xapian, Sphinx and ApacheSolr: With so many third-party options to choose from, how does one evaluate and decide?
* Search and Drupal.org: What special needs does Drupal.org have, and how can we improve things now and in the future?

Goals

Increase focus on improving core Drupal search. Increase awareness of alternative solutions. Increase awareness of different search features, such as faceted searching. Encourage more collaboration amongst developers.

Resources

* http://drupal.org/project/apachesolr
* http://drupal.org/project/xapian
* http://www.sphinxsearch.com/
* http://groups.drupal.org/node/4102 (Search group on g.d.o.)

Overview

User experience (UX) can be defined as “the overall experience and satisfaction a user has when using a product or system.” A product’s UX affects a user’s interest, ability, and enjoyment when using a product. If a product’s UX sucks, people will not use it if they have a choice or hate using it if they do not.

Well, programmers are people, too. When creating a software product like Drupal that is intended to be used by other developers, the UX includes the experience of those developers as they write code for the product.

Since developers face different kinds of issues than the end users of the product, it is useful to consider Development Experience (DX) distinctly from UX. DX might be defined as “the overall experience, satisfaction, and efficiency a software developer has when using a software development platform.”

In this workshop, we'll brainstorm about ways that Drupal's Developer Experience can be improved.

Agenda

* Why Developer Experience matters
* Open discussion of how Drupal's DX can be improved.

Suggestions I'll bring the workshop include using defined names instead of anonymous constants, abandoning anonymous arrays in favor of typed data structures, and replacing form submit handlers with API functions. Please bring your own!

Goals

We'll come up with a list of proposed coding style directions or improvements for Drupal 7+ and contrib modules that will make Drupal a much more enjoyable and efficient platform for which to develop.

Resources

Anyone familiar with Drupal development is qualified and encouraged to attend. In many ways the less experienced you are, the better, as you will not already be indoctrinated into The Drupal Way of doing things.