The organization should be able to create several different kinds of events, and determine for each kind of event which detailed information will be taken. Those events can be displayed in a list or calendar format. Users can register for events, and pay using a credit card.

There are many ways to describe this story – it certainly can be a lot more detailed, but what’s clear is the result of this functionality. And, of course, user stories are great for agile development process.

Developers would determine how much this function would cost (based on our knowledge of the tools we use, and the time it takes using those tools to generate this sort of functionality), and clients would know exactly what they are getting from a functionality standpoint. When this functionality is complete, everyone is happy. The developers get reasonable compensation for a job well done, and the clients get the mission-based functionality they asked for.

And it would avoid a situation which I have become recently far too familiar with – vendors who underbid projects, and then feel the need to resort not to the intent of the contract, but the letter. Everyone knows it is utterly impossible to specify every detail in the letter of a contract – sometimes letter of the contract, unfortunately, details things like fields and queries, not functionality. The letter of a contract will be, almost by definition unless based on functionality, an inadequate representation of the final result needed. In this case, no one really wins. The clients either don’t get the functionality they expected, or they pay extra for it, and they leave the project with a bad taste in their mouth about the vendors, which will only come around to hurt the vendors later.

Human processes mold around software. We see this all the time. A CRM gives you these 5 canned reports, and you get used to making do with what’s there. A legacy client database requires a certain order of data entry, and your intake forms have been produced to copy that order. Your email software has particular limitations, and you find behavioral workarounds.

What’s also true in the realm of customized software, is that software is molded around people. You put in your RFP that a package spit out data in X,Y and Z ways because your ED is used to data in that form (maybe because a package they had at their previous organization had those canned reports.) You have a requirement that data be entered into the system in one particular way, probably because that’s the way you’ve always done it. Sometimes, you feel the need to replicate a process that the person 3 administrative assistants ago put in place that was molded around their particular limitations, just because that’s what you know.

When you are undergoing the process of creating or implementing a new system of any sort, whether it be a CMS for a website, a CRM, some internal system, it is a really good exercise to be like a 3 year-old, and keep asking “why?” Why do we need this feature? Why will this report be important? Why should the software work this way? Once you peel the layers down to the bottom, you’ll either have “we don’t know” or “because we believe it will help us meet our mission in this specific way.”  Then you know what you should take, and what you can leave behind.

One thing I learned is that it is incredibly sensitive to typos. One space accidentally inserted between the “<?” and the “php” led to a completely blank page. Ah well. I’m certainly learning what mistakes can lead to what kinds of issues, which is good. Eventually that becomes second nature.

But, in any event, by the end of an hour or so of hacking, I’d turned a template that I found online at Open Web Design into a Drupal template. I felt accomplished! I’m going to do a few more, and see how sophisticated with it I can get.

One thing I ran into (and haven’t been able to solve yet) is that it’s not easy to have navigation that requires more than just the standard <ul><li> tags. Adding <span> tags, for instance (which makes possible some more interesting looking navigation buttons) seems, at least at first, far from trivial.

I’m making a list of little(ish) projects that I want to do – sort of like problems I think I want to know how to solve.

• Drupal and google docs single sign on. There is already a SSO Module for Drupal 5.x, and someone submitted a patch for it, but it’s still up for review. I’d also have to cough up $50/year to get a google account that has the SSO API, but it might be worth it.
• Drupal sidebar connecting with the NPR API – perhaps to provide a targeted news stream?
• Doing a google map mashup of data in Drupal
• Working with getting flickr photostreams to show in Drupal

I’m still looking for a good project to try out in Cake. Unfortunately, the module Drake, which is meant to be a bridge allowing you to run Cake applications within Drupal, seems moribund. There is only a development snapshot for the 5.x branch, and no one seems to be picking it up for 6.x. Sigh. There is, for sure, another whole blog entry about Drupal modules.

The approaches are similar and different to each other. I set up both on my laptop, and tried out some really simple app development. In Cake, the database build is separate from the application building (you do it yourself), whereas in Symfony, you use Symfony to build the database with schema files written in YAML. Then, you build forms and such using the schema as a foundation.

They both use the MVC pattern, and both use object oriented PHP, which is great. I got a lot further with Cake in one evening of playing with both than I did with Symfony. At this point, I really prefer Cake – it feels like it jives with my own coding sensibilities better. I also don’t like the overhead of learning YAML. I can imagine, though, that the Symfony approach can be powerful.

Looking at Ohloh, Cake is more popular than Symfony (on Ohloh, who knows about in general), but Symfony has a lot more developers (81 vs 17). They both have good documentation and active communities.

For now, unless something strange happens, I’ll settle on Cake – although I’ll not be spending too much time on it, since I’m working hard to grok Drupal. But perhaps a cool project will manifest, and I can use it.

Update: I learned that Yahoo and delicious have a huge investment in Symfony (which, I guess, might be why they have so many more developers.)

So if you want to start adding content to your new site, and you need a little formatting, or a picture, etc., well, unless you know a bit of HTML, you are S.O.L.

On the other hand, this is actually, from my perspective, a really good thing (can you tell I’m becoming a Drupalista?) There are several to choose from, and they differ both in difficulty to get installed and working, as well as features. Want something barebones? There’s one for you. Want something with all of the bells and whistles? There’s one for you, too.

There is a great review of five of the major ones.

I’ve been getting to know a few of them (and, yes, they can be a pain to install, and they depend, generally, on other libraries that you have to install as well.) I don’t have a favorite yet, but I’m thinking I don’t need to have one – just to know which ones are well-maintained, and what the differences are in feature set. Then I can choose the one that makes the most sense.

My next step is to try and create a simple theme (so I understand how theming works,) and write a module (so I understand how modules work.) There are still lots of things that are mysteries to me, but perhaps I’ll learn more at Bay Area Drupal camp this weekend.

I’ve also been digging a lot into the new(ish) social network software Elgg, and beginning to develop a members-only site with it for a client. In my estimation, it’s amazingly promising, as a platform for interesting private sites. And, since it has OpenID (which seems to have bugs, though), OpenDD, and OpenSocial, it’s not such a bad idea for public sites either (although I’d still not suggest that nonprofits spend the time to do this.) Maybe someone will use it to create the Facebook killer (I kind of doubt it, but I can hope, can’t I?)

As well, I’m still honing my WordPress skills, mostly in the realm of dealing with themes and moving the darn things around and upgrading from ancient versions. I’ve done some theme hacking, but haven’t yet written a plugin (I can’t think of one to write that hasn’t been written yet.)

And, on top of all of that, I’m re-writing in PHP some core functions of a web-database/CMS framework I wrote in Perl a gazillion years ago (and still is in use for an application called EASE.) That’s been fun. What’s also fun in retrospect is that the framework (the erstwhile Xina) was written basically using the MVC architectural pattern before I knew it existed!

It feels like I’m beginning to focus on a core set of tools and technologies (PHP, Drupal, WP, Elgg,) and that in a few months, I’ll be up to speaking PHP fluently, like I spoke Perl a while back. And I’m looking forward to getting to work on the kinds of projects that I’ve been watching as a spectator in the last year.