People, places, things, events, ideas

Perhaps some of you remember about a decade ago, when Apple was working on what was supposed to be the replacement to the crufty old Macintosh System (we didn't even call it MacOS back then), a sort of Finder successor (I think) was codenamed "People, Places, Things." This was clever, because it suggested what we want to use computers for, not how we use them.

Looking at CMSs today, I see much the same thing. The end purpose for a CMS is to organize people, places, things, events, and most importantly, ideas.

How can Drupal give users the most power to organize these?

Drupal started out like most CMS as a repository for ideas, with some date (event)-related features. Since then, the developers have been getting closer to covering all these bases, and with the very valuable addition of the flexinode module, it is getting closer to letting moderately technical users do just about whatever they want with it. What next?

Speaking as an non-developer, it's easy for me to make grand pronouncements without needing to think too hard about the implementation. I'd like to make some code contributions, but at this point, I'm trying to teach myself some PHP, and it would take me a while to simply wade through the functions in Drupal to figure out the kosher way to do things.

That said, here are some grand pronouncements. These are big, long-term ideas for how Drupal might evolve. In some ways, these suggestions would make Drupal more complex; in other ways, more elegant.

1. Redefine all content modules as flexinode profiles.

I'm sure this suggestion will be very popular with all the developers.

Obviously Drupal's default installation should have some "pre-rolled" content profiles (terminology here gets confusing: "profile" has meant a user's profile, but it is also a convenient word to use to describe a flexinode content type with a specific set of fields) set up, but these could be modified through the flexinode interface, and new ones created.

2. Extend the data types available in flexinode

"Person" could be a valid data type, referencing a person's (not exclusively a user's) information, and personal profiles could be reimagined as a flexinode content profile. Geographical locations and distances could be added (remember how popular GeoURL was before Josh Schachter got distracted by del.icio.us?). Time/date data could be augmented to handle start times, end times, repeat intervals. Keywords are a useful form of meta-data (and it's really nice the way Drupal profiles now let us find common interests), but these could be extended as well, to allow freeform keywords (as present), a controlled vocabulary of keywords (defined by the admin), a user-concensus approach (freeform but suggesting the most popular keywords, as with del.icio.us).

Fields would need to have various forms of metadata associated with them. The data-type and form widget, obviously. There would need to be a way to indicate "this field is the main body", "this field is a summary for use in teasers and RSS feeds," "this is a keyword field," etc. Data-validation is another form of meta-data that could be associated with each field, and I can imagine a cottage industry of data-validation modules. Out of the box, Drupal might include a "dumb" validator for phone numbers, but someone might write a smarter phone-number validator that knows the lengths of phone numbers in different countries, automatically reformats numbers, etc.

Some interesting consequences of all this:

• Personal profiles could be treated as just another part of the taxonomy, with a hierarchical structure, multiple terms, etc; this could be the mechanism for managing roles and/or groups.
• It would probably make more sense to have taxonomy-oriented permissions rather than content-oriented permissions.

3. Make appropriate functions available for all instances of a data type

Any node that includes a date can be hooked into a calendar function; any node that includes a location can be hooked into a mapping function; any node that includes a person can be hooked into a directory function (of course, these functions could restrict their scope to look at only a part of the taxonomy). For example--one might use a Drupal install to create a sort of history book. A node for Abraham Lincoln would reference him as a person, his date of birth, the coordinates of the town where he was born, and so on. Bringing up "example.com/calendar" for the month of February 1809 would show Lincoln's birth on the 12th; bringing up a map would show a pin at 37°34'16" North, 85°44'19" West. Etc.

4. Take node theming out of site themes and associate it with individual content profiles

For dynamic sites where a new feature can be added easily and where one user can view the entire site differently from another, site-wide themes make sense. They do not make sense for laying out the fine details of the sub-parts of a page.

When a site administrator creates a new content profile, he probably has a specific idea for how to present that content. Right now, it is too much work to realize that presentation. Content can be presented three ways--as a list or table of many nodes in summary form, or as a single node in its full form. Each of these three layouts should be defined during the flexinode's creation using the combination of placeholder tags, HTML, and CSS used by Blogger and Movable Type. The flexinode could (and should) automatically generate a primitive template for the admin to use as a starting point.

5. Improve the tools for relating content types

This is suggested by the previous points, and it is the hard part. Right now you need to know at least a little PHP, and probably a little about SQL queries, to really get the most out of Drupal. Less technical users can get a lot out of it, but (speaking as one of them), I always get the feeling that there's a lot more power just out of my grasp. I'm not exactly sure how to approach this, but I can imagine the following:

• A query-building wizard. This would present the admin/user all the various fields that have been defined in the various flexinode content profiles, and a few buttons for building queries based on them appropriate to their datatype. This would produce a human-readable query in a sort of SQL pseudo-language like "all birthdays for (users where role is 'authenticated user') in range 'today' to 'today+7'" and would build a table or list accordingly; the format of the results could be defined by the admin in an accompanying HTML snippet with pseudo-tags. I envision this as something set up by the admin as a custom block, without user interaction.
• Something like the Smart Playlists in iTunes, where the query terms are defined entirely through drop-down menus and there's no fancy AND/OR/NOT logic between terms. This would be less powerful, more accessible, and perhaps easier to implement. Some clever DHTML would come in especially handy here for adding/subtracting query terms. I envision the admin enabling this kind of search for specific parts of the taxonomy, and having it available to all/most users.