Note: The speed enhancements below are mostly about optimizing files and client-side stuff. You can also speed up your catalog on the server side with hardware and database optimization, though doing so is likely to require assistance from Innovative.

Why

Faster-loading pages make users happier. Some speed-enhancing techniques also increase server performance and decrease the amount of bandwidth used. Page speed also factors into search engine rankings, though that is less of a concern for our catalog than our website.

How

Most of the improvements came from Google Page Speed recommendations.

Sprites

Fact I found interesting: Before I applied the catalog changes, the directory contained 682 files. It now has 49. Having fewer files doesn't inherently speed up the app, but it does speak to the nature of the changes.

There are two types of images in a Millennium "example set": icons (or whole buttons as images) and media type indicators. A typical setup, until recently, had 145 or so button images. The most recent example set available from Innovative has 45 icons and a couple support images for making buttons. These images are coupled with some crufty markup to make the buttons work. The latest set also ships with 39 media indicators (in fairness, we'd use maybe 13 of those for our library).

CPL now has one image for all the icons and one image for all the media indicators. In total, the catalog screens have 8 images: one is required but never used, another never seen, and two others used infrequently. Yes, we grab book jackets from an external service, but that's the extent of the catalog graphics.

An individual example icon weighs in between 600 bytes and 1.3K. Our icon sprite is 5.44K. It can be loaded once and cached on the user's machine. For pages with many buttons, this results in far fewer HTTP requests and a smaller total payload. The same goes for media indicators.

How do we pull this off? We use two spriting techniques: 'traditional' sprites and pseudo sprites. The styles to makes these work can be found in the catalog stylesheet. What's novel, and how you can pull this off in Millennium, is in carefully crafting what're called 'wwwoptions':

# pseudo sprite example
ICON_BUT_REQUEST=<span class="but icon request">Request</span>

# traditional sprite example
IMAGE_MATTYPE3=/screens/spacer.gif" class="media-icon bookmp3

As you can see, in both cases activating sprites involves appending classes to a particular HTML element. In the case of the pseudo sprites, there's a class that makes anything look like a button, one that pads the left-hand side and loads the icon sprite image into the space, and one ['request' above] that stipulates where in the sprite image the request icon appears. In the traditional sprite, the "IMAGE_MATTYPE3" option must be an image. Since there's no getting around that, I used a spacer gif. It's 43 bytes — the smallest practical image for the web. I then circumvented the wwwoption to add the classes to the image. Those classes set the background size and position the sprite image.

Be advised that pseudo sprites only work in standards-compliant browsers and IE8+. If a substantial number of your users are on IE7-, you may want to wait. Users with non-supporting browsers can still see the button style we use, but the icons won't appear. Sites that work for everyone but look better for modern browsers are considered progressively-enhanced; that's what you can consider these buttons.

Distrusting Bowker

We use Syndetics Plus, Librarything for Libraries, and Google Books previews on our bibliographic record pages. That's a lot of stuff to load. As part of an overall improvement in JavaScript performance, we changed the way we pull in those resources.

Syndetics Plus, by default, loads onto a page something like this

• Page calls widget.js directly, via a script tag
• widget.js loads jQuery from Google's CDN
• After jQuery is loaded, widget.js loads widget_connector.js
• widget_connector.js gets ready, finds ISBNs on the page, and requests an ISBN-specific widget_response.js
• widget_response.js writes to the page and asks widget_connector.js to do stuff

This is a mess. It's a long chain of serialized resources that aren't well-cached by the browser, aren't served minified and/or gzipped, can't be served over SSL, and that block full page rendering until they're complete (whether or not there's a result). Total payload for this process is 49K.

Librarything for Libraries is even worse (here I go again). It goes:

• Page calls widget.php (served as javascript) directly, via a script tag
• widget.php loads connector.php
• connector.php pulls in connector_LB.css
• connector.php gets ready, finds ISBNs on the page, and requests an ISBN-specific widget_response.php
• widget_response.php writes to the page and asks connector.php to do stuff

What makes this process so awful is connector.php. It's over 150K all by itself, and it includes the sizzle selector library and a bunch of other utilities. Which makes one wonder — why not just use jQuery? Moreover, why does a file that loads a comprehensive selector engine need to define getElementsByClassName()? connector.php's JavaScript is a Frankenstein's monster of code that pollutes the global namespace. I'm afraid that some people might be having nightmares over it. This file also includes all functionality for all different ILSes (not just Millennium, the one we're using) and all LTfL features (a small fraction of which we're using). This massive file is unminified and uncompressed and is part of a call chain that doesn't support HTTP keep-alive. Minifying the file wouldn't solve all the problems, but it would be less than half the size (mostly because their variable names are massive). Ditto on gzip compression, which could make it less than a quarter of its heft over the wire (without minification!).

We pull in jQuery from Google (the old-fashioned way, so it client-side caches for just about ever) and use it for almost all the (CPL-made) JavaScript on the page. The code for us to replace Syndetics Plus's payload (25K without jQuery) is 150 bytes before compression. The nearly 200K for LTfL? Less than 1K, and I could probably optimize further.

CPL-specific code pulls the primary ISBN from bib record pages, validates it, then makes sure the page is served as regular HTTP. All of this occurs after the page has already loaded. If the conditions are met, we then feed the ISBN to the widget_response files from the two services, getting back just the results specific to the bib record. The widget_response files handle writing to the page all by themselves, so the service-specific code just adds things those scripts expect to find and handles certain on-page actions. Since we do this all asynchronously, the page loads (and feels like it loads) as quickly as Millennium allows.

Being careful with the three widget services provided the biggest overall improvement to payload size and page rendering speed. Google Page Speed eliminated the warnings about redirects, uncompressed resources, request serialization, unminified javascript, and undeferred scripts.

What's funny about the terribleness coming from Bowker's servers is that a big part of improving the situation is both easy and a big sack of win. Users would get faster pages and Bowker'd save on bandwidth and hardware specs. Some quick apache config of mod_expires and mod_deflate is all that's required to pay dividends. A deployment scheme involving minification and/or a refactor of the connector scripts would be more time-consuming, but could make the widgets substantially faster. Serving out static scripts without query strings would be a huge help, for instance.

More JavaScript Optimization

I was more diligent about jQuery best practices like using fast selectors, caching selected objects, and delegating events to their appropriate containers.

Millennium has its own JavaScript library. It's ordinarily served out as 3 files, but we weren't having any of that. Our Millennium setup prevents the default files from loading, and instead serves a single file with all three components minified. iii.js is just under 20K before compression, and 5.2 over the wire. That's 2 fewer HTTP requests and 4.4K less payload on every page.

Image Optimization

I ran all the catalog images through PNGGauntlet, which uses PNGOUT to reduce file size — sometimes by 25% or more. For high-use files, I also weighed the quality reduction of making them 8-bit PNGs; the sprites, for instance, get served out as 8-bit files, making them substantially smaller.

Web Server

I also rolled out a sprite for the site's layout and theme, optimized the chat widget, and combined and minified CSS files for use by the catalog. Our web server, in contrast to the catalog, is pretty aggressive about caching. Files are served with far-future expires headers. APC for PHP caches the opcode to minimize file reads; this results in faster execution speed across the board, but not necessarily faster serving to the end user. We have drupal caching set up, which benefits from MySQL query caching. Apache gets some love from the OS's buffer cache. Altogether, the website is a layer of caches.

What's Next

I'd like to reduce the payload of every page on our site by rolling out a new theme. There's a lot of extraneous markup and styling that can get cut out pretty easily. Other possibilities:

• Optimize images as they're uploaded
• Minify CSS and JavaScript on theme deployment
• Defer jQuery and other scripts on page loads
• Put stuff into a cache manifest
• Investigate mod_pagespeed to do some of this stuff automatically

For the catalog, a few squeaks of extra speed could come from moving static files to our web server (which has longer cache lifetimes), combining the [minified] catalog CSS into the site CSS, and working with Syndetics to get book jackets from URLs without query parameters.

tl;dr

Google Page Speed.

Notes

You've got the wrong guy

I originally proposed this session not because I have a ton of experience on the topic and all the answers, but because I wanted to use presenting as an excuse to learn about git.
If you've been using git for a long time and/or have memorized large portions of the Drupal APIs, chances are you won't be able to learn much from me.

WTF is a git!?

The word git was first a British slang word for an annoying or stupid person. The software was named self-deprecatingly from that word. I like to think git stands for something else though: good shit.
Git is a fast, distributed version control system.
It was originally developed by Linus Torvalds in 2005 to be used for developing the Linux kernel

If you've used another version control system, you might wonder what sets git apart.
From what I've gathered, the most important differences between git and other systems are:

• Git is distributed — this is important, because having a local copy of a repo lets you access the version history easily, commit whenever it makes sense, and push it to one or more repositories, or remotes, based on the structure of your project
• Git reduces the pain of merging, which means that you can make lots of branches without worry

Other systems, like CVS, subversion, and others, are also considered slow for accomplishing certain tasks. While I don't have a great means of comparison, git seems pretty quick to do most everything.

Drupal and Git

The Drupal project switched from CVS to git in February 2011. The changeover is a 3-phase process, of which they're on phase 2.

1. Phase 1 was a git mirror, so that people could test and develop in git without affecting the project
2. Phase 2 is a centralized model based entirely in git
3. Phase 3 will be a decentralized, GitHub-like model that will change the Drupal.org contribution workflow. Details are still being hashed out on that front

Local Tools

Locally, there are a few tools that can make routine tasks fast and can integrate with the tools you already use.
I'm a visual, GUI guy, especially for menial tasks. So I like TortoiseGit on Windows, along with a Git plugin for Notepad++. TortoiseGit makes pushing changes a job of a few clicks. The Notepad++ plugin lets me press Ctrl+Alt+C, type a commit message, and click a button to commit changes to one or more files. If you think vi is a pain in the butt, tools like these are for you.

Remote Tools

It's probably not just you doing development. Even if it is, there's a compelling reason to have at least one central place for your repositories, which I'll explain later.

But a side reason to have bare remote repositories is that you can use tools intended for remotes, like redmine. Tools like this add another layer for project management. You can do project planning, bug tracking, wiki documentation, and other such tasks from a web interface, letting either you or your team keep track of things. And if your project is out in the open, you can leverage a much larger community using sites like GitHub, Google Code, or SourceForge.

Your First Repo

Let's say you have a directory of files that you want to put under version control at that path. You'd go there in your terminal, then initiate a new repository. Next you'd add all the files. Those files are queued up and ready for the first commit, which you then perform.

If you don't use the 'm' option to add a commit message, the commit command will show the log entry for the commit in vi, and you put the commit message at the top. It's at this point that I'd like to reiterate that vi is a pain in the butt.

So that's how you create a new repo from bash

Commands

These are the git commands you might use in day-to-day work
*Point at commands and explain what they do*
^ Learn what the commands do

These commands are used less frequently (in general), but it's good to know about them
bisect lets you determine where a bug began in the revision history, using a binary search to split the possibilities in half each time.

These are also git commands, though you might not use them very often or ever.
stash is commit for wusses

Workflow

So let's talk workflow.

At my job I've got two Drupal sites: "Beta," which isn't really the right name for it, since at times it's a dev box and at others it's a beta-slash-QA machine.
And the live site.
The design and development parts of my job revolve around creating modules and themes to add functionality and enhance the design of just those two properties.

I'm guessing that's NOT what your jobs are like. I'm guessing you make lots of sites. And those sites in various states exist in multiple places, like your local dev machine, an internal server for testing, and external hosting that you don't necessarily control. I don't envy you.

Wherein I Tell You Not To Hack the Core

A site is Drupal core, plus contrib, plus the data in your database.

Since Drupal is modular and nearly everything can be changed via hooks, it's really pretty rare that you have to change anything in core. And if you do, I've found from experience that it's usually for temporary debugging rather than for permanent changes.

Do not hack core.

Avoiding Temptation

So from Do Not Hack Core we can take away that all the things on the left are things you shouldn't mess with, and the thing on the right is the only place that customizations go (unless you have a weird multisite setup, which is cool, but your workflow's going to be different).

A repo at the whole site level is redundant, and reinforces the opposite of the number 1 best practice of the Drupal site-building community.

Drilling Down

What about at the 'sites' level?
This is workable, but you might notice something immediately.

Look at the sites/all/modules directory.
You're probably not going to be hacking contrib either! All of those modules are version tracked in git on the drupal.org site. The vast majority of those modules require zero coding to work exactly as expected. Putting them under version control doesn't accomplish much.

Then there's sites/default
sites/default/files contains uploaded and attached files. Those files are site-specific and are subject to database dependencies. The files also tend to be images and other files that are unlikely to change. There are a number of reasons why version controlling those files is impractical.

On the other hand, sites/default/settings.php is a good candidate for revision control individually, as it's something that you have to work on in the development process, and some of the settings will likely have to change depending on where the site lives. The branching model of git could be really useful for this purpose.

.gitignore Files

One way to wrangle sites/default/files and streamline the process is with .gitignore files. With a well-made, well-placed .gitignore file or two, you can continue using git add . and git commit -a without adding stuff you don't want to your project.

.gitignore files let you choose files to omit from the versioning index, based on wildcard notation. So instead of omitting /sites/default/files wholesale, for instance, you could just selectively ignore boring images and junk while preserving the directory structure wherever the repo might end up.

What You're Controlling

Conceptually, the two components that you're likely to work on that can most benefit from version control are:

1. Customizing the theme to the client's needs
2. Developing custom modules or modifying one or more contrib modules

If you start with a working theme, like Zen, you can clone down a repo from Drupal.org and use the history of that particular part of the project if you need it. You can create your own branch for your theme and develop from there.

If you code up a custom module, it might only be useful for a single site a single time. But maybe the functionality you add is something that other clients might want, or that can be contributed back to the Drupal community. Modules are reusable pieces, so structuring your repository environment to make them accessible for all sorts of projects is a plus.

Hypothetical Model

Here's an example of what repositories on a central server might look like.

I made the directory structure here very flat, putting core, modules, themes, and the site_projects repositories all within a single folder. This would work well if you always use the same base theme along with a limited number of custom modules. This particular setup plays nice with management software like redmine, which is one reason a flat structure is attractive.

If you're going to have lots of distinct themes and modules, it might be helpful to create big repos called modules and themes, then use git's submodules functionality to manage the individual drupal modules contained within. Thanks Ben for the submodules tip!

Now that we have a central place for all the things we're working on related to building our sites, we can optimize our workflow to play nice with version control.

Leveraging Synergy

One way to do that is to set up pushing and pulling.

If you don't already have ssh keys set up between your development box and your repository server, setting that up will make it a lot quicker to push and pull from git. If you want to deploy via git from the repo server to other machines like your site testing server or even live web server, you'll also want to set up ssh keys between the those boxes.
On your local dev box, use the clone command to make a local version of the repo on your server. When you do that, the source repo becomes a 'remote' called origin.

Make some changes to the local copy (you can branch if you want to, you can leave master behind). When you're done making changes and they're ready for other people in your shop to see/use them, use the push command to send them back to the origin.

Drush Make and Install Profiles

Once the changes are on the server, you can pull them to your deployment boxes, or...
You can get fancy.

It's a common use case: you end up using the same base theme, modules, configurations, and other tweaks on most of your projects. You might already have an "install profile" informally; Drupal with all the stuff you use all in one place.

The "drush make" command lets you generate makefiles that turn your informal install profiles into the real deal. In Drupal 7 it's easier to make profiles that configure things on install, but technically it should be possible in D6 too. Some combination of the features, strongarm, context, and other helper modules could let you automate some impressive stuff — like pre-built views.

Hint: it might be manual coding work, but if you install a whole bunch of similar sites, writing a [profile name].install file could be a time-saver in the long run. Especially if you swipe one from an existing public profile and suit it to your needs.

You can use the drush make command to import all the dependencies for your profile wherever you need them. Then just run the installer (which if you're super fancy you could get working with drush site-install) to have a functional site in the time it takes to make a pot of coffee because your junior dev doesn't know proper coffee machine etiquette.

The makefiles are really flexible, so you can choose particular version numbers of modules for compatibility, apply patch files to change modules or core code, or grab external libraries from tarballs.
Nailing down a "holy grail" workflow for this sort of development takes time and effort, and I certainly don't have all the answers.

Over the next few weeks, Alex Fisher and I will be working on drush make and workflows, and will report useful findings to our respective blogs.

You may also ask about how to go from local dev to testing to quality assurance to live, all while easily managing your databases. You may ask that, but I don't have an answer. Sorry.

Pay it Forward

If you'd like to become a core developer or get involved in a contrib project, a working knowledge of git will help.

I'm fighting the urge to give nitty-gritty details here, as the instructions are both technical and well-documented. If you're not a project maintainer, contributing code involves creating patch files based on numbers from the issue queue. If you are a project maintainer, you can interact directly with the remote repo (albeit while following the guidelines).

One reason I'm avoiding an in-depth explanation is that the Phase 3 git migration could very well change how things get developed on Drupal.org.
But here's how to create a patch file, just in case.

Just one commit is the easiest for contributing back patches.

The Version Control tab on project pages gives really good instructions for grabbing source repos and other contibution tasks, including the specific clone command you need to grab a local copy of the repository.

So now that you're a git expert, go out there and contribute back to the Drupal community!
Thanks for putting up with me!

One thorny problem, though, is over-riding the style of certain elements that use the width of the screen liberally by default. One such element is the venerable data table.

Coyier's solution is great in that each table cell is labeled. However, doing this requires either writing CSS manually for every data table on the site (which is near-impossible for large sites) or having the same thing done with scripting on either the server or client side:

I propose a generalized solution that requires no scripting whatsoever. The drawback of this method, though, is that the cells are not individually labeled. The example is also more compact, but this aspect can be tweaked by marrying the two methods:

@media screen and (max-width:720px){
table{display:block;}
td,thead th{border-color:#444;border-style:solid;border-width:0 2px 0 0;display:inline;float:left;}
td:last-child,th:last-child{border-right:0 none;}
thead th{background:transparent;font-size:1.1em;}
tr{display:block;float:left;clear:left;padding:6px 0;width:100%;}
thead tr{border-bottom:4px solid #444;margin:0 0 .3em 0;padding:0 0 .2em 0;}
tbody tr:nth-child(even){background:#ddd;}
td:nth-child(5n+1),th:nth-child(5n+1){background:#FFD8D8;}
td:nth-child(5n+2),th:nth-child(5n+2){background:#FFE8D8;}
td:nth-child(5n+3),th:nth-child(5n+3){background:#FFF8D8;}
td:nth-child(5n+4),th:nth-child(5n+4){background:#D8FFD8;}
td:nth-child(5n+5),th:nth-child(5n+5){background:#D8D8FF;}
}

Open the working demo and resize your window to under 720 pixels wide to see the effect. I call this approach the "Rainbow Tables" method

Thanks to Chris Coyier for posting a thoughtful working solution, and thereby motivating me to post about my approach after sitting on it (in production no less!) for almost a year.

For one thing, most library websites are really outdated and bad. Comparing the design/development workflows of Apple and Google (nice!) or Amazon and Netflix (not exactly gems of design) to how libraries maintain their sites is apples-to-oranges. If a library has a flat-file website (Not a straw man: this is common in libraries!), performing a complete redesign/redevelopment is probably advisable. A "slowly evolved" CMS developed in-house at a library is likely to be slapdash, and there are tons of available CMSes that are well-designed, secure, free, and supported.

What's not mentioned in the original post is that redesigns don't have to be long, painstaking processes. Bad redesign processes are that way, but a sufficiently-experienced and talented designer can ease those woes. The solution for doing a good redesign is to have a good designer.

Likewise, iterative design isn't always a breezy process, and it often isn't design. Design needs control; website creative control is often lacking in library environments. What often ends up happening under the guise of "iterative design" is actually a patchwork; sometimes from having too many cooks in the kitchen, sometimes from having one crummy cook. We've all seen these websites; they start out clean and freshly-designed. Then someone pastes in a widget and it clashes with the design. Then comes more widgets ad nauseum until the site looks and works awful. As such, the solution for doing good iterative design is to have a good designer.

Library folks: don't resist redesigns. If a well-designed website is important to you, hire a good web designer. Trust their judgment to decide whether the best course of action is to iteratively improve your site or to do a full redesign.

The following notes do not reflect the actual presentation. If video evidence comes along to prove this, I will add it to the bottom of the post.

Slide 1 - Welcome

Hey, I'm Brad Czerniak. I'm the web guy at Canton Public Library.

Thank you very much for coming to see this presentation today. And especially thank you to Deborah, for inviting us to speak. I hope that what we're talking about will be useful.

My presentation is decidedly impractical - I'm gonna try to explain what Drupal is and some of how it works.

I'll be followed by two really energetic and talented guys: Alex Fisher from Commercial Progression, and Stephen Colson from Switchback CMS. They will put the rest of the puzzle together with real world sites and practical demos.

Before moving on, I'd like to thank all the people who contributed to this crowdsourced presentation, and all the local Drupal user groups for their support and advice.

Slide 2 - Drupal is a free & open source content management system the answer

So, right off the bat:

Drupal is free and open source. It's released under the GNU Public License, which is the same license used for the Linux kernel and around 60% of open source software.

You may have heard of LAMP. I love lamp. It stands for

• Linux
• Apache
• MySQL
• PHP

While Drupal could be considered a typical LAMP application, you should note that only the P is strictly necessary. It can run on Windows or Mac, with various web servers, and with a few different database systems. It is written in the PHP programming language, so you're kinda stuck with that requirement.

It's been around for nearly 10 years and a whole new version is set to be released soon.

Drupal is the answer, but what's the question?:

• Do you want a powerful website?
• Do you want to add more features later?
• Do you need support?
• Do you want different users to do different stuff?
• Do you want options? There's an easy way and a hard way for everything in Drupal*

I have to admit something now.

Slide 3 - Drupal kinda sucks (right out of the box)

If I have learned anything in the last two years, it's that Drupal is not a Ronco Showtime Rotisserie

It's not "Set it and forget it"

This out-of-the-box unimpressiveness is by design, though. The use case for Drupal is for a site more sophisticated than a small personal blog. It's assumed that you'll customize the site to some degree before unleashing it on the public. It's not strictly necessary, but a site based on a basic Drupal install won't turn any heads.

Drupal also has a notorious learning curve, partly due to an administrative interface that tends to scare away beginners. Luckily, one of the big features for the upcoming version is a big improvement in usability.

Let's take a look at what you get out of the box.

Slide 4 - Your New Site

It's like this.

A blue-and-gray theme called "Garland" is set by default, and you have two content types - page and story.

If you install Drupal for the first time, this can be an incredibly scary sight.

Content types are important: They range from "blog post" to page to a form to external content from RSS feeds to whatever you can dream up. Each content type has a bunch of options:

• Whether or not you want them to take user comments
• Which users you want to be able to create, edit, or delete content of that type
• Whether you want new posts of that type to show up on the homepage

Stuff like that. You can set all of that on your website if you're an administrator. No coding necessary. Once you get the hang of it, It's really easy and flexible.

Slide 5 - The Happy Middle

And it's that flexibility and ability to do complex things without code that sets Drupal apart from other solutions.

Here on the left we have Rails, Django, and CodeIgniter. The basic idea behind all three of them is that they're frameworks - tools for building web applications that help you do it quicker than starting from scratch and using some basic guidelines to make sure they don't suck.

But, when you install them, you have to write code before you even have a basic webpage.

On the right we have WordPress and MediaWiki. WordPress powers almost every personal blog on the web. It has like 200 million installs.

MediaWiki is the software that powers Wikipedia and a ton of other sites.

When you install them you're up and running. You don't need to worry about the particulars - just add content. These applications are great if you want a blog or a wiki, but they take a lot of work and aren't really intended to do much custom stuff with them.

Drupal sits in the middle. It gives you the flexibility of coding a site yourself and the beginnings of common website use cases right when you install it.

Slide 6 - Sweet, Sweet Nodes

So that's sweet, right?

One of the scary words that's really important to understanding Drupal and talking shop with other Drupalistas is 'node.'

A node is an individual page or blog post or whatever you've dreamed up.

All the real content of your site is made up of nodes. Everything is a node.

Node node node.

It might help to think of a node as a note. Or it might not. But a note or a memo has a subject line or title and some content. All Drupal nodes have those things too.

If you want to organize your notes you might put them in folders or attach Post-Its to them. This is kind of how Taxonomy works.

Taxonomy is another one of the scary words.

Here's the skinny. A taxonomy is a list of descriptive terms. Each term is like one tag in a tag cloud. You can stick these tags to any node and use them to organize your content.

Down here we have the tape dispenser, labeled CCK. That stands for Content Construction Kit. I'll talk about Modules in the next slide and Steve will demonstrate CCK specifically, but the general idea is that CCK lets you attach all kinds of funky things to your notes - like photos and even whole other notes.

Slide 7 - Modulez, Drupal Enhancement

There are 5703 total modules. That's a lot.

A module extends (extenze, get it?) what Drupal does. In fact, Drupal is made up almost entirely of modules. Each one performs some small role.

So there's a module called node that does stuff for the nodes from the last slide.

There's a module called menu. Confusingly, it mostly has to do with URLs, but kinda not really. It's one of the things you only have to learn at 1:00AM on a weekend while wired on Mountain Dew. So we'll skip over that for now.

Those are modules that come pre-packed when you download Drupal core.

Then there (contributed) modules nicknamed contrib modules. These are written by the community to make Drupal awesomer.

CCK from the last slide is a contrib module lets you add more stuff to your nodes.

Pathauto lets you make friendly URLs with tons of options

Rules lets make things happen on your site. It's a good example of the "easy way" of working in Drupal.

There are modules to give you fancy calendars, Word-like rich text editors, and 5700 other cool things.

Slide 8 - Umbday Exampleway

So here's a rich text editor. You can pick which one you want to use from a bunch of different cool options, then install the module and set it up.

Boom! Now you have WYSIWYG capability. And you have options, just like the Drupal gods intended.

Here in the text box we have some pig latin. If you aren't fluent, it says "This is a really dumb example."

It's a dumb example because --

Well... let's say you want to make a node and you want that node to appear in pig latin to your users.

You can type it out in plain English and let Drupal do the translation for you.

There are many modules that let you type in wiki syntax or markdown or plain URLs or ISBN numbers and the module turns it into something cool for your users when they view the page. At the library, for instance, we use double square brackets and links to books in our catalog to import book cover images and the title and author and stuff. This is a real time saver and it's all automatic.

And you can mix and match these filters. If you want to strip out certain html tags from the text AND put the text in Pirate-speak, no problem!

This particular example is dumb because when you're creating or editing that node, you'd just see English. So silly.

Drupal also has non-ridiculous translation built right in. You can put your menus and other site text in other languages and switch it for different users and all kinds of stuff. If that's an important part of your project then you'll be stumbling into a funky corner of Drupal's learning curve.

Slide 9 - Users

One of the most powerful features of Drupal lies with User management.

Out of the box it handles sessions and cookies and usernames and passwords and all the stuff that's a big pain in the butt to get right yourself.

On top of that, you can assign permissions to users in a really common sense way.

You can create roles. Roles are containers for much more specific permissions. An example of a permission is "User can edit their own blog posts."

So an admin is free to do anything on the site. A signed-in user can do some things, but is restricted depending on what roles on the site they've been assigned.

A visitor CAN have permissions, but generally can just view stuff through their binoculars.

When you install modules, they often give you new permissions that you can assign, so it's really easy to make sure that the right people can see and do the right things.

Slide 10 - API

This ability for modules to tie into what Drupal does is because of the API.

API stands for Application Programming Interface. It's the way that programmers can interact with the code and data in an application.

Drupal's API is full of these things called hooks. These hooks let you add stuff to Drupal in a standard way.

For instance, when writing a module you might want to use hook_user. Your code might say - when a user signs in, redirect them to a different page.

When one things happens, do other stuff.

Once you get the hang of it, writing code for Drupal makes a lot of sense.

Slide 11 - Page Theming

Along with coding modules, you can also code themes.

You can hard-code HTML into your theme, or put little bits of PHP in there to display the content from the database exactly how you want it.

If you use the default template language, called PHPTemplate, you can specify regions on your page to hold blocks of dynamic content stored in your database.

You can move these blocks around from your browser. Once your theme is coded it's really easy to put stuff where you want it.

Your theme consists of a bunch of template files. This one is for an entire page.

Slide 12 - Node Theming

This one is for a single node. A page can have more than one node displayed at a time, and those nodes can be of many different content types.

Does that make any sense?

Think of a bag of jelly beans. The page itself is like the bag. It wraps around all the good stuff.

Each node is like a jelly bean. All the buttered popcorn flavored beans are from the product content type.

But the bag also has black licorice beans. These could be wiki entries.

The one page could show products and wiki entries in one listing.

And the cool part is that you can make them display however you'd like using template files.

This doesn't speak to how gross a bag of popcorn and licorice jelly beans would be, but this is America so you're free to fill that bag however you'd like.

Slide 13 - jQuery is Money

Nothing's better than esoteric programming double entendres.

If you know jQuery, you know that the shorthand for the base function is the dollar sign.

But I also mean that jQuery is money. jQuery is so money and it doesn't even know it!

jQuery is baked in to Drupal's core. You can even code up your JavaScript is a very Drupal-ish way using Drupal's concepts of behaviors, settings, and locales.

But that's not all!

You can use all the same web standards that everyone else uses, or go your own way.

If you want to use a particular CSS Framework, there's probably a pre-existing theme to do it, or you can roll your own.

If you want to do everything in HTML5, Drupal won't complain.

If you want some visitors of your site to view your pages in full size and others to get a mobile page, that's very doable.

Drupal lets you do what you already know and gets out of your way.

Slide 14 - All the cool kids are doing it

What else can I say to convince you that Drupal will work for your site at the scale you need?

Argumentum ad Populum. Translated from the Latin it means "All the cool kids are doing it."

There are a lot more prominent sites and organizations using Drupal, but these sites are notable because you're in Drupal when you get to the home page and most if not all of the content is in Drupal.

That's a powerful indication of the trust organizations place in Drupal and the ability of it to suit complex needs.

Slide 15 - Support

Another great selling point is the available support.

You can get help directly from the Community via IRC, Forums,and other avenues.

You can get materials ranging from books to videos and more from Lullabot, Apress, and other publishers

The creator of Drupal has a company called Acquia that also lends support.

The documentation for every aspect of Drupal is amazing. If you want a quick how-to for a beginner it's on the Drupal site. If you need in-depth documentation of the API, it's there too.

Each module has an issue queue. These are really handy for seeing if the issue you run into is a known bug or a picnic error.

Most any problem you run in to likely has a forum post or page on the Drupal site. The site search is arguably the best tool for getting the support you need.

There are also plentiful user and developer groups. There are at least three in Metro Detroit.

You can also hire a firm to develop, design, consult, or for individual bounties to develop a particular feature.

Options. Drupal gives you options.

One more thing...

Slide 16 - One More Thing... (Views)

Views makes a Developer's life so much easier.

I'm not ashamed to admit that I frequently take the lazy route. Views is the lazy route in a very real and very cool way.

Remember the jelly beans? Let's say all the content on your site is a big tub of jelly beans.

Views lets you put whichever beans from the tub you want in whichever bag you want.

If you want an RSS feed with just the images from your products in order by the date they were last edited, you can do that by playing around in Views for a couple minutes.

If you want a block in the sidebar with the latest posts from one user's blog, that's a cinch.

If you want a page of all the posts tagged chicken in reverse-title order, you can do that.

With Views. Views is a miracle wrapped in a magic trick.

Views makes learning Drupal SO worth it.

Yeah, you're like me. So I'm going to assume these things are true too:

• When you wake up, the lights are off and your eyes have been closed for 4-12 hours
• You've kind of enjoyed being asleep, and are kinda cranky at whatever's making that racket
• When I say cranky, I mean your judgment may be a little impaired too

What am I getting at here? The iPhone alarm clock is really usable -- it's easy to set, fairly customizable, can schedule alarms really well, and is reliable as it gets. The only time that the usability sucks is when you're just waking up. Here's what it looks like when the alarm goes off:
Here are the problems with this in my opinion:

1. It uses your default wallpaper, which could be blindingly bright with undilated pupils and other changes to the eye that occur in low-light conditions
2. The text is small, condensed, and white, making it hard to read because optical resolution is lower at low-light conditions, and the brightness of the letters makes halos around each one
3. The snooze button is small, and fumbling around for it can be very frustrating
4. On an older-fashioned alarm clock, you don't actually read the word "Snooze" when you hit the button -- it's just the big button on top. Reading the word makes you mentally connect-the-dots. Call me weird, but sometimes when I wake up and read the word Snooze on the phone I think I'm in some Dr. Seuss-esque dream

So I propose an interface more like this:

An Apple designer could make it prettier, but the basic ideas are there. The background is black, all elements are - at brightest - 74% gray, the Snooze button is about twice as large, and it says Sleep instead of Snooze. Also, it doesn't really break from the core iPhone UI; the same slider bar, clock, top bar, and dialog colors are all present (though I used black text in the button for contrast's sake).

If you'd like to know more about human vision in low-light conditions, check out these Wikipedia articles for starters: Rod cell, Scotopic vision, Adaptation (eye). Also, for some User Interface advice, knowing about Fitts' law could be really handy.

It would also be great if there were an easy indicator to know when it's in Snooze mode. I often set a second alarm because I'm not sure, so then there are two alarms going concurrently. Then, as I finish checking my email and Facebook, a little dialog shows up and I hear that damned song again. How about putting the number of Snooze minutes left inside of the alarm indicator in the top bar? Thanks.

Also, for your time-wasting pleasure, I give you: Faker Baker BS3 . Anyone's who's ever used B&T knows this screen all too well. Now, all you have to do is point your browser to brad.hawidu.com/bt and you'll instantly look busy! For you pros out there, the color is #47768e.

My parody of the famous http://www.isitchristmas.com/ website.

IS it Opposite Day? Think about it.

1. Get the digg-like interface for resources up and running. This will allow anyone to contribute to the resources, vote on them, and add comments. The top five will be displayed on the "canvas page," with a link to the full listing. The universal resources will still be at the top (probably), but any catalog, database, etc. can be added.
2. The profile badge will have the newest and/or recently popular resources instead of the (hilarious) video from Weird Al's movie, UHF.
3. An additional section will be added that will link to an Information Literacy wiki (If a good one aimed at non-librarians already exists, please link to it in the comments) in colloquial language to help patrons help themselves.
4. Some sort of usage of the invite notification system provided by Facebook. This will be aimed at getting users. As expected, the initial users of the application have (mostly) been librarians. This is positive for a few reasons, and useful because the infrastructure is there for patrons with Facebook-based questions.
5. Tweak my database of librarians with additional email addresses, homepage URLs, and other useful data – currently-registered librarians can easily update, while new librarians will automatically have the option.
6. More stuff is on the way, especially since the feedback and suggestions have been wonderful!

Note: I get off work today at 9:00PM, and will be burning some hardcore midnight oil to get these launched as quickly as possible. Please be patient as things come into operation over the weekend. Thanks!

You can see what I'm up to by adding the alpha app – http://apps.facebook.com/fblibrariantest/

Also, look out for the open Application Data, and eventually the open source.

(Lastly, on a personal note – My packrat mentality makes it insanely difficult to weed "my" collection. Just wanted to get that off my chest.)

• be very lightweight in terms of images and text content.
• have the most useful and original aspects of your site included.
• create incentive to click over to the full site
• follow one of the most-common (netvibes, iGoogle) form factors
• be standards-compliant XHTML

What!? XHTML? The common view of widgets and gadgets are the XML + AJAX + web 2.0 whatevers that you find all over the place. I know Google supports URL-specific gadgets -- not to mention that the code you copy and paste into the XML is HTML for the formatting anyways.

It should be XHTML because the gadget can then easily double as a site for mobile users -- a growing segment of the online population. Pish-posh to iPhone Safari and Opera 4 Mobile – The screens are still small – so the content should be as well.

Outside users can embed it in an iframe, and the basic structure can be ported into almost any site that uses gadgets natively. This opens up the possibilities to a much wider range of web publishers – including novice users.

The thing that appeals to me the most about widgets is that they consolidate content even more than websites have in the past. A well-made widget puts the best dynamic content from a given site in a format that can be splattered all over the internet like leaflets.

Oh, and geniuses -- why hasn't anyone put AdSense in the minimessages library of GooGads yet?

The solution: widgetize based on use. This is how I lay out my iGoogle, and it makes sense:

1. "Main Tab" - Has my gmail, facebook notifications, some bookmarks (esp. for sites I go to daily), a last.fm recommendation radio for my account, and most prominently my Google Reader. Previously I had separate Gadgets for feeds, but refused to make a single tab big enough to warrant scrolling. So, I consolidated the feeds into Reader. While I was at it, I also threw digg, engadget, etc. into another folder and made a Reader gadget for that in another tab. That's just not "prime time" enough on my productivity to be in the main tab. The main tab is the home page of your home page.
   1. I would have Google Calendar on the main tab, but the Gadget doesn't fit my criteria yet. It shows a monthly calendar, and not a daily agenda! I go to the freaking page daily! -- what use is THAT!? That gadget would just be a link.
   2. Google Bookmarks could also use some work -- mostly the ability to import, but also some more del.icio.us-ish features.
2. Other tabs: The other tabs are for noteworthy gadgets that do not require daily checking.

The gist of what I'm trying to say: widgets and gadgets should be developed with daily or even up-to-the-minute use in mind. A Google Calendar should be that day's agenda.