One of the chief buzz words during the second-wind of internet growth is/was "agile development." This phrase serves the web industry well, and can even have some relevance out-side the sector. It means, of course, adhering to a semi-regular schedule of iterative release... and more importantly a realization that perfection has little place on world wide web.

But even after we've all been whisked away to a magical head space where we're willing to concede our personal and professional shortcomings, learn as we go and listen to our customers... we still haven't agreed upon when to build.

All to often the decision to create is dictated by when the inkling is conceived.

In the best of cases, a set of previously dreamed up ideas are chosen from cyclically, based on an educated set of assumptions about users. This is currently about the best companies hope for. Register notions (internal or from outside), then prioritize based on effected user base and potential new users.

But what about that really awesome new feature you want to add that you're just sure will totally knock the socks off new and old users alike? You know, the one they don't really need. The one that Scott over at Funded.com Inc. just pushed live on his site. Should you build that into your system? Or should you speed up your page loads by 5ms?

I just had to bring it back to form vs. function didn't I. Useful alteration vs. bling. Should the web be an experience or an efficient source of information?

I bring up this question, because I think that each site/company/project needs to continually reevaluate which heading it falls under. The inevitable answer is both, but the questions remains: to what degree and in what portions of your online presence. When IMDB (internet movie database) serves a trailer, they are an experience; when they provide a listing of actors in a film, they are an efficient knowledge bank.

In which direction does your presence need to grow?

This may be just the right place for my anatomy of a feature release list...

1. Idea is conceived: you or your user(s).
2. Emailed, ticketed, feedbacked or mentioned orally.
3. Prioritized.
4. Building begins.
5. Pushed live.
6. User is wowed.

The key here is that we have to be ok with bumping something indefinitely. And sometimes dropping the bling project to listen to usefulness. Of course.

My current "when to build" belief is-- Hold out for desire. Act on need.

I'm tempted to say that only the big kids --Microsoft/Apple, Facebook/Myspace, Google/Wikipedia, Flickr/Youtube-- have the luxury of freedom to innovate bling. But we know that's not true. While they serve most of the eyeballs on the web, they too must follow the pull of optimization and house-cleaning against smooth experience and titillating innovation. Besides, innovation often comes from the edges and the new comers.

This doesn't mean you can't make time for un-affirmed improvement. You just need to hold off getting innovation "production ready" until it's at least actively desired. By the time it's an actual user need it should be in place and refined.

The industry term is "scope creep." The everyday human term is "a bunch of extra crap." One of the first few questions you answer when starting a web project is what are the core features. What's our site going to do for people? The simple answer you start with usually grows into a rambling monster of: instant personal messaging, event auto-recommendations, mobile video chat, holograms and real life status pokes.

At this stage of the web game, there is in fact a suite of features that set the standard. It's hard sometimes to step back and evaluate the difference between industry baseline and creeping requests.

I thought it might be good to create a list of the top basic features; things that won't differentiate you. But the right combination, plus nailing even JUST ONE of them, just might.

This is a check list NOT to be crossed off. Your job is to choose the subset. It's the right combination of basic features, for the right people, plus of course your totally awesome new twist.

• Search
• Private Message
• Blog Posts
• Comments, Reviews
• Profile, avatar, comment wall
• Activity Feed (you and friends)
• Photos and albums
• Tagging content (contextual)
• Similar Content
• Easy signup, password retrieval
• Groups
• Voting, Up/Down
• Filtering your view (popular, friends, recent)
• Aggregating outside services
• Categorized browsing
• Private notes, contacts, data storage
• Friends/Following
• Contact Import
• SMS/email posting
• Members only area
• Forum
• Video posts and replies
• Status updates / Micro posts
• Forward and share
• Bookmarking
• Upload/storage
• Collaboration
• Wikis
• Checklist/to-do
• Events and Calendar
• RSS (push)
• Map representation of user or content
• Customizable look/layout
• Polls/survey
• Notification, digest
• Add to cart and checkout
• Embedable elsewhere widget
• Multiple languages
• Desktop/Browser tie-in

*sigh* Now try and be choosy.

Course there are some newer features, that I'm sure will be standard by 2012, when Sarah Palin runs again. Ha!

• Alternate discover view mode
• Personalized recommendation, filtering
• Rich media meta indexing
• Organic data organization/clustering
• Comparative aggregation tools
• Mobile location check-in
• Location specific content
• Natural language interaction
• Location independent conversations
• Automatic outside social integration
• Hovercars
• Teleportation

Barring the last two, I do actually have examples. These aren't empty predictions; I'm saying these things are to be standard in a few years. Their fringe now, not miracles. Here's what I mean: vimeo toys, digg labs, strands, youtube tagging, google gaudi-- sets-- inquotes-- trends, flickr draw searching, pandora, memetracker, powerset, chacha, etc.

Drupal is great for adding features via modules. Inside of a few days you can have a pretty sweet site prototyped. But without a good looking wrapper your candy will look stale. There are lots of great themes out there ready to drop in with just a few minutes work. Without a little sweat on your part the site will lack flavor, and give off the appearance of just another Drupal site.

I've been working on a new project that is anything but, and in the process I've been teaching Drupal to a friend... we just came to themes. As a good member of the Drupal community, I started the project in v6. There are some changes to themes, but when I hit the upgrade page to further browse the differences between 5 and 6, I realized most people probably really need a starter list. I wish I'd had one. Much of my knowledge is still in Drupal 5, but I've tried to include some of the changes in this tutorial.

Here is a list of a few things you should be aware of to get a solid start in themes.

(Of course Drupal has a great Theme Guide, for multiple versions.)

• Folders
• Template Files
• Template Base File
• Regions
• Hooks

Folders...

First things first, themes rock because everything that causes the site to LOOK the way it does lives in the theme folder (you probably already knew this.) That folder is sites/all/themes/your-theme-name. (This theme folder allows for multisites.) The cool part is that folder can have a bunch of theme, which you can switch between. Set one for admin, another for random users or even let your users switch if that fits your desires.

In the theme folder is the /images folder that holds all the theme specific images you need for that look of your site. NOTE: Files that will exist regardless of the theme are stored separately. In version 5: /files and in version 6: sites/default/files.

Template Files...

There are a few files that power most of a theme's layout. All of the files in the theme folder that end in .tpl.php are template files that determine Drupal rendered output. These files contain the HTML that finalizes each page. The master layout template is page.tpl.php. This file determines how all pages will be displayed. This contains your page structure tags, often much of the header layout, and most importantly the output places for Regions. If you have a layout in mind and a sketch in hand, then open up the page.tpl.php file and the style.css and create the basic layout.

The secondary template files are things like node.tpl.php, comment.tpl.php and block.tpl.php which determine how each of those are respectively output on a given page. Keep in mind that nodes can output as a list, table, teaser or full... and templates can then get more complicated as you perfect various outputs. In fact, you can even define a different template for each node type by creating files like node-product.tpl.php or node-blog-entry.tpl.php.

Template Base File...

The template base file is like the brains of a theme. It defines various functions that will take place before rendering Drupal output. It helps create breadcrumbs, can customize how usernames or avatars are displayed, can inject style classes and ids into elements based on what page you're on, and in v5 it was/is the way to call out different Regions, among other things. The base file is template.php. One of the most common reasons for editing this file is that a module asks you to in readme.txt. (You are reading all the module readme files aren't you!) Needing to edit the template file means that a piece of the module needs help in rendering the output function of the theme you're using.

Regions...

I think this is one of the most under-used elements of Drupal. Regions allow you drop a section of content (a block) into a region on the page. In your page template you can define as many regions as you want, wherever you want and via style sheet customize the look however you want. This allows you to have total control of layout with just a few files AND those few files are all isolated in the theme folder! As of v6 regions are defined in the .info file. I believe this is an indicator that regions are now being seen as a more essential and useful elements of themes, and Drupal in general. The only bummer with custom regions is that when switching between themes much of your content can disappear because the new theme doesn't have the region for your content blocks to land. (The database entries for assigning blocks to regions in admin/build/blocks are theme specific.) If you are providing multiple themes for admins or users, make sure they both have the same regions.

Hooks...

As a beginning themer, you won't need to write hooks. But this is a great time to add them to your vocabulary. One of the core structures of Drupal is hooks. They allows modules, themes and more to latch on to a thread of code being executed. If the Drupal core is processing something, like getting a user avatar, then Drupal is calling a function that provides a hook. A module can then, for example, edit the size of the image. This can then still be hooked onto by a theme function that places a link around the image. Anything that happens in Drupal, all the way down to core functions like write a comment, show a profile, write the date, etc. can be hooked onto and altered by a theme function. These are called theme overrides and are done in the template.php file. This, again, given the theme LOTS of power to alter the output, remain in a separate folder and easily switchable.

Hope this gives you a better jump into Drupal themes.

Yesterday I took on teaching my friend Matthew from A Bollen Design about Drupal. We're helping with a project that, while there will only be a few users, seemed like a good fit for the platform. Normally my rule is that if you'll have a small team adding content then you should defer to a smaller CMS like WordPress, but this project will have a few more features just beyond what I think is reasonable for only WP plug-ins. It's not a tech project so I hesitate to think about custom development options.

I can't help but use the opportunity to log how I go about explaining the Drupal platform. First of all I'll mention that I've started with the Drupal v6.4 release. The v6 core has matured well, and many key building block modules have been ported to the new version. I went ahead and did the installation process, set up clean-urls, named the site, created a developer role with pertinent permissions, renamed the 'story' content type to 'post', created a taxonomy (category for v5 users) and configured some basic admin settings.

Admittedly, I softened the blow of dealing with Drupal. If you're setting up the platform for the first time then refer to your install and read-me docs, then return here for steps to discovery.

So step one, the first 'assignment'

1. Create a content type
2. Create a new taxonomy, assign it to a content type.
3. Create a few pieces of content
4. Change the theme
5. Look at the module page
6. Set-up the primary links menu
7. Turn on and place a few blocks

Actually, I only stated step 1-5 explicitly. He did 6 and 7, so I added them to the list because he was right. I think this list give you a good idea about the structure and tools available in the Drupal system. The only pieces missing are the various admin functions of Drupal. There is LOTS of power in: error reporting, stat tracking, comment settings, url aliases, input formats, not to mention actions. Plus of course the power that comes with multiple user accounts. But I argue that to get started, you need to learn the structure-- take the user system for granted-- and bypass the plethora of admin settings.

I recommend before you install any modules learn: basic content types, creating content,

taxonomy, blocks, menus, user management, roles, permissions, core modules, and then move on to all the other admin stuff. Once you've bothered with things like tweaking your "post settings", changing the date and time, and choosing which content types display post information in your global theme configuration... then you can drop a new theme in and start installing modules.

I DON'T know about the project you have in mind as you read this, but might I recommend you go peak at: cck, views, imagefield, imagecache, (imageapi), pathauto, and token to start you on your Drupal journey. I said peak, not install. Be sure to read up and compare options before you roll forward. And one last piece of advice...

...Install modules one at a time. Test them out, set up the configuration, use them, and only then move on.

We offer our talent a few tools to pool info about projects; this way we save time and work more cohesively. One of our first "Cheat Sheets" was about SEO (search engine optimization.) Since the purpose of our TalentEd blog is to present such knowledge, here are some of the greatest hits for SEO.

The main goal is to let the engine know when you should be displayed. It has to guess about your purpose. Provide goods hints.

KEYWORDS

• If you don't know what meta tags are then stop right here, that's your one lesson. Put a meta tag for keywords and another for description. You can also have a script dynamically insert keywords more appropriate for that specific page. PS: trying to double up words makes you look bad to search engine brains and wastes the small number of words you get.
• Make sure to use h1, h2, etc. tags. They are more semantic and help with search indexing. Engines only pick up one of each on the way through.
• The title tag in the head of your HTML document is also a premier way to describing the content with a simple title and some perfect keywords. Bonus point: if your title and h1 tag match, then the engine knows it must be true.
• Go find out which keywords to use. Examine competitors; be more awesome. Don't just guess.
• Repetitive keywords looking spam-ish? Search engines are real smart.

TAGS

• Use valid markup, otherwise the robots will get lost while viewing your site.
• Similarly, broken links make search engines, and people, frustrated.
• Use the alt attribute in your image tags so that blind people, and search engines, know what they would see.
• This goes double for image links. Include the title in link tags that surrounds images.
• Include the title tag for links in general... at least the important ones.

URLS

• If you're going to be content poor (small number of pages) then let your URL describe your purpose to some degree. (Large networks have the luxury of content to do the describing, i.e. Flickr, Facebook, Bebo)
• It's all about the prominence of descriptors, so get your URLs readable.
  
  If somone could read the address and understand where it will take them
  
  then you're golden, i.e.
  
  www.readydone.com/blog/jul-08/search-engine-cheat-sheet
• Often
  
  tied to URLs is your site structure. Make this logical and get yourself
  
  a site map. You can have a page do this or even better provide a link
  
  to an XML site map for the robots to eat up.

LINKS

A main factor in your relevancy is how many links come into your site and where they head to. The internet is a mesh of hyperlinked documents. You want to be a hub. There are lots of ways to get sites to link back to you... I recommend having great content.

Having a whole lot of great content will make you even more vauble.

Lastly, there are lots of other people trying to present their relevance to the web out there. They can be a great resource for exchange and sharing. Two web presences mingled is more than the sum of it's parts.

That's all you get.