This morning, I happened upon "Wired's Essential Apps for 2011" and quickly found myself frowning. I wasn't frowning because of the Wired editors' decisions about which apps are the best, it was because I was frustrated with a glaring design problem in their article and I suspect I know the reason it looks so bad:

Developers Built it That Way

Of the initial thoughts discussed in part 1 about using various usability strategies within Drupal development, the most important, and perhaps most aligned with achieving business objectives, is clarifying value.

User experience is an implied science within engineering, especially when what you're building is an application. Your creation is never fully realized until it gets into the hands of its users and, ultimately, makes their lives easier.

With the advent of Drupal 7, the importance of user experience (UX) continued at Drupalcon Chicago. One of the biggest hurdles to its consistent adoption is articulating its principles to developers.

How do we fix this? I think the solution exists in the answer to the following questions:

As a developer, having your hand in the stream of information within your field is a job necessity. We tend to watch things we're interested in, debate the issues we are passionate about, and ignore the ancillary.

Well, what if I told you that the ancillary, especially within Drupal, was key to making your life easier?

It's been a major focus in Drupal 7, especially with the user, but User Experience (UX) principles have just as much potential within developer circles too!

Today I released the Node Reminder module.  The Node Reminder module was based upon the code for the Post Reminder module.

In a previous article I extolled the virtues of keeping your Views in code, which lets you deploy or change them as easily as uploading or updating a module on your production site. In the article, I wrote about using Drupal 6 and Views2 to do so.

Drupal 5 / Views 1 Execution

Views 1 for Drupal 5 also has this mechanism in place, so if you're working on a Drupal 5 site, it's still worth using. It’s how the calendar and date modules provide a default calendar view, among other things. The method for putting default views in your modules is pretty similar, and it’s still a great technique to practice. In Views 2 for Drupal 6, you had to implement two hooks to have a module provide default views in code: hook_views_api() and hook_views_default_views().

Since getting started with Drupal over two years ago, the sites I’ve built with it have naturally gotten bigger and bigger in scope. As your sites get bigger and bigger, you always look for ways to keep your site running as smoothly as possible, and this usually ends up meaning getting rid of queries wherever you can.

One feature of Views which is often used by module developers is the ability of a module to expose a set of default views. The calendar module, for example, provides a default calendar view in both its Drupal 5 and 6 versions. This is an obvious asset for developers of contributed modules: if your module interfaces with Views, it makes sense to provide a default view that users can modify.

Implementation and Potential Benefits

The hook used to do this is hook_views_default_views(). Since most modern sites are run off of a number of Views, you can also realize several benefits by building your sites with a custom module that implements hook_views_default_views():

1. It improves performance. Views implemented via hook_views_default_views() do not require a database query to instantiate. You will realize an even greater performance gain if you also use an opcode caching system such as APC or XCache.
2. Providing views in code will allow you to override the default view to make changes, and you can then choose to keep the changes in the database, update the module file to reflect the changes, or revert back to the version in your module file.
3. Because the view (and theoretically, changes to that view) are stored in files, you can put them in version control and see how the views used in your site change over time and revert to an earlier version without having to go to a database backup.

Introduction

The Need

Our clients and other Drupal site administrators would like to use the Workflow module to schedule transition states in their publishing workflow.

The Problem

Currently, within the Workflow module a node cannot be assigned a scheduled state change upon node creation. A node must be saved first, then edited a second time by the user.

After reading this comment in the Workflow module issue queue: http://drupal.org/node/189572#comment-704334 I decided to try to add a little more automation to the process of creating a node and adding a scheduled state change.

In this Post

You'll learn how to create a publishing workflow for your website, and how to improve the process of scheduling a transition change during node creation.

Let's begin.

Note: This demonstration is build on Drupal 6. The process outlined below may be adapted for Drupal 5 install.