Drupal ninja

Overview

Coding standards matter. Why? Because they free the mind to get to the more interesting bits of programming. Programming is more than just problem solving, and it is best when you can contribute patches and modules which provide the most elegant solution. With help from the audience, we can share our experiences of successes, rabbit holes, and hitting brick walls (and how to get past them too). This talk is aimed at programmers of all levels of experience.

Agenda

* Creative: it's not just for graphic and UX designers
* Code Quality: standards, coder, devel, api.drupal.org, code examples
* Creativity Killers: deadlines and budgets
* Rabbit Holes and Brick Walls
* Resources to Help You Stay on Track
* Further Reading and Recommendations

Goals

After participating in this talk, people will walk away with inspiration to write high quality code. In addition, more experienced programmers may take heart when seeing a beginner show their first contributions.

Resources

Recommended reading:
* coding standards - http://drupal.org/coding-standards
* http://api.drupal.org

Modules:
* devel
* coder

UPDATE: Never mind, there is still a chance.

Overview

Drupal's bot module is an IRC bot that is pretty awesome, but it can always get better. This session will walk you through setting up a bot to run on your channel, and then coding for your bot to make it better.

Agenda

* What is bot module?
* Installing bot module on your site, and configuring it for your needs.
* Running your bot
* An introduction to developing modules based on bot.module - bot.module's hooks.
* I'll build a sample bot module.
* Bot_autenticate: user authentication with the bot module: how to use it and why to use it.

Goals

The participants should walk away ready to provide patches to the bot module to make it even awesomer!!!!!!

Or at least know how to set up their own bot.

Resources

It is recommended that you know how to build modules, unless you just want to know about installing and running bots.

Overview

The formal user tests at the University of Minnesota and Baltimore have got quite some attention. They also had a common bottom line: Drupal is quite hard to get into for novice users.

We want to improve this. But how can we make sure we really tackle the major issues? And how do we find out if improvements are really improvements?

Repeated testing is the answer. Make sure to find out how the user experiences Drupal for our own attitude cannot be but biased. How is someone who is not accustomed to the workflow and UI able to perform a given task?

And how to make user testing fun? I'll try to depict how this can be done utilizing the
Usability Testing Suite (UTS).

Agenda

• Tests in U of Minnesota and Baltimore: have there been reliable results?
• A bit of theory: how is user testing generally carried out in other projects and companies
• The Usability Testing Suite (UTS): A way to go?
• A plan how to encourage and organize constant testing

Goals

Find a way to make user testing an asset to Drupal. Just like code testing has got a key role in Code Quality.

The talk will have an ensuing BoF to discuss the further steps in user testing. If we could come up with a plan that feels feasible, this would be wonderful.

Resources

Usability Testing Suite
In dev state,
maintained by boombatower

Overview

Come up with a plan how to encourage and perform constant user testing in Drupal. The BoF continues on what has been said in the Session "User Testing in Drupal".

Agenda

• User testing is tedious, what can we do to make it more fun?
• The main problem is that in a test, you question your own work. This is unpleasant, because you might find out it has issues. Or is this no issue?
• One needs testing persons. How can one make it easy for them so they may participate in testing Drupal again? Who are the people we need for that?
• Generally two ways of testing can be done: completely remote, or with you directly watching the Tester. Which one is better?
• There is also the "big solution" (formal Studies like in Minnesota and Baltimore. We also need those. What role do they play, and what role play smaller ones?
• How can we utilize existing Infrastructure to minimize redundant work? Maybe the DROP program can be used and extended? Do the issue queues help?

Resources

Usability Testing Suite
In dev state,
maintained by boombatower

Some 40 Indymedia sites worldwide are now using Drupal, with different approaches to solve some of the general and specific requirements of their sites and collectives.
Other collectives are currently migrating their sites from other CMSs to Drupal.

Agenda:
* exchange ideas and updates face-to-face, sharing what's done
* Discuss and develop the survey
* discuss ideas for a basic install profile

http://docs.indymedia.org/view/Devel/ImcDrupalDevUsingList
http://docs.indymedia.org/view/Devel/ImcDrupalDevModules#How_IMCs_use_Dr...

Overview

Drupal is very modular "horizontally". You can add modules that inject themselves all over the place to add to the workflow of the page request. However, too many subsystems are inter-related, making it very difficult to separate out and modify one part of the system. Drupal is simply not as modular as it could be, nor as it needs to be.

Better separation between systems would allow for more rapid development, easier testing, greater flexibility, and at least 23% more awesome per square meter.

This hybrid lecture/brainstorm session will examine one proposal for further modularity, Handler objects. Working module code will be included.

Agenda

* Discuss the benefits and limitations of Drupal's hook architecture.
* Introduce a new extension mechanism, handler objects.
* Demonstrate existing uses for handler objects, including inspiration from Views and Panels.
* Discuss a broader vision for where Handler objects could go to transform Drupal.
* Open discussion.

Goals

This session is essentially a meat-space RFC. If all goes well, attendees will come away with lots of new ideas and the presenter will come away with lots of feedback. Best case, we'll have an awesome new roadmap for Drupal architecture. Worst case, attendees will get to see a nifty new module they can use.

Resources

Handlers as discussed in this session are an evolution of the concept documented in this article, after further discussion with other Drupal gurus. Familiarity with that writeup is encouraged, but not required.

The module is now available if you want to look it over before the session!

Overview

The DROP program is an ongoing program that aims at helping people learn Drupal through small, bite-sized tasks that are never too intimidating. This session will discuss the DROP program, including past achievements, future plans, and how you can help and/or participate in it.

Agenda

* Past achievements: what has been done through DROP?
* How can I participate in DROP as a mentor?
* How can I participate in DROP as a student?
* Where is the DROP program going in the future?

Goals

You should leave this session knowing what the DROP program is and how to participate in it. As a result, the DROP program should receive a boost of attention and effort, and many new Drupallers will have an easier time learning Drupal.

Resources

http://drop.cwgordon.com/

Fleshing out the plans is here: http://groups.drupal.org/node/12972

Looking for co-hosts!

example:
- do a card sort on the admin categories
- discuss the different 'dashboard' approaches people already use
- choose 2 options we want to compare / test

another example:
- let's pick a nice chunk of core interface text: labels, descriptions, help
- rework them for clarity, consistency and brevity.

BoF Usability Sprint Day 2

build prototypes: on paper, in photoshop and/or code
or: further work on interface copy, start documenting the copywriting guidelines we find.

BoF Usability Sprint Day 3

Test conceptcode with the Usability Testing Suite
Or work on concept some more, take it to the Code Sprint.
or: create patch for interface copy and start the guidelines handbook page on drupal.org

Fleshing out the plans is here: http://groups.drupal.org/node/12972

Looking for co-hosts!

example:
- do a card sort on the admin categories
- discuss the different 'dashboard' approaches people already use
- choose 2 options we want to compare / test

another example:
- let's pick a nice chunk of core interface text: labels, descriptions, help
- rework them for clarity, consistency and brevity.

BoF Usability Sprint Day 2

build prototypes: on paper, in photoshop and/or code
or: further work on interface copy, start documenting the copywriting guidelines we find.

Fleshing out the plans is here: http://groups.drupal.org/node/12972

BoF Usability Sprint Day 1

* zoom in on 1 or 2 issues we already decided upon before the conference
(redo admin categories, modules page, permissions page…)
* bring your ideas and proposals
* discuss the options, decide on 1 or 2 things we can work on.

example:
- do a card sort on the admin categories
- discuss the different 'dashboard' approaches people already use
- choose 2 options we want to compare / test

another example:
- let's pick a nice chunk of core interface text: labels, descriptions, help
- rework them for clarity, consistency and brevity.