I wasn't terribly comprehensive in terms of my idea for content types in my last post. I blame this on it being late when I had written it, and my blogging skills being rusty due to disuse. I had spent a little time on IM after posting my last entry talking with Trice about the idea. There seems to be a bit of confusion on how this will be implemented. First, a little background.

Drupal is the content management system powering deninet. Drupal conceptualizes a single piece of content as a node. So, this blog post is a node. My last blog post is a different node. The deninet staff channel is yet a third node. At time of this writing, there are over a 1000 nodes on the site (actually quite few as Drupal sites are concerned). 

Each node as a type. So, this blog post and the one before it are of type "blog". Types are what you select when you go to the create page. At present there are only a handful of types available -- blog posts, book pages, channels, and Images. I actually see a few more types (Group, FAQ) due to my admin status. There's more information about nodes and types on this page. 

There's a third data layer that's important to bring up -- fields. Types specify certain kinds of fields. All types have two basic fields -- Title and Body. Things like Blog posts are little more than a title and a body. Channels have a few extra fields, such as "description" that channel admins use to provide a brief description on their channel. Fields are actually a complex mechanism that can allow nodes to have files attached, images displayed, references to other nodes, and so on.

Deninet uses views to display anything that isn't a node. Views can query nodes for specific fields and use them to create lists of content. The user track page is actually a view. We use views extensively to display content throughout the site.

Now that we have some concepts laid down, I can start explaining my idea.

One of the things I would like to see deninet become is a repository for our creative content. This includes written works, pieces of artwork, and possible music and video in the future. In essence, I want deninet to be our own, personal DeviantART. 

The problem I face as the site designer is how to package all this kinds of media. I've basically come up with three different models:

• The Musketeer model insists that there is one and only one content type for all creative works posted to the site -- a "creation". Any time you go to the create page, you would click on the "creation" link and upload a file of your work. The file upload would basically be a single Field. Special code would need to be written to handle this that would identify the file type you uploaded, and decode and display the content. The benefit is a huge amount of customization and refinement of the UI is possible, but at the risk of development time and bugs.
• The opposite model is the Content Type Sprawl model. This is where we have not one content type, but scores of them. Poetry would be a different content type from Prose. Architectural photographs would be a different content type from that of people. This leverages Drupal's abilities, but also makes things dreadfully complicated. Each type would need customizations and testing and would result in a similar development burden in terms of time as the Musketeer model. The creation page would also be a mess of different options that would be very confusing to the end user.
• The How it's Packaged model is a middle of the road approach. Instead of looking at what the creation is, we look at the kind of data we save it as. Poetry, prose, non-fiction, novellas, are all written material. In terms of data packaging, they're all text (*.txt). Music, podcasts, voice acting, and so on are all saved as audio files (*.aac, *.mp3). Photographs, sketches, and so on are saved as image files (*.png, *.jpg). Anything with video such as a TV show, video recording of a lecture, etc, are saved as video files (*.avi, *.mp4, *.mkv, *.mov). Users would select the type of data they have to post, and then select the content type (one of four, basically) appropriately.

All of these models assume that things that aren't creative works such as blog posts, book pages, or channels, still exist as separate content types. That will not change. I'm only speaking to adding content types, rather than replacing them.

I've been arguing over these three different models for months now. In the end, however, the How it's Packaged model seems to be the best course of action. First of all, it would require the least development effort on my part. Images, Video, and Audio already have modules that provide the necessary fields. Creating four content types, each incorporating their respective field, would be a trivial task. 

One question that Trice asked me is how we will handle categorization. If all written works are one content type, how will people be able to find poetry posts, or prose posts without shoveling through all the other potential kinds of text content? This is actually not that hard to solve. Drupal provides a complex tagging mechanism called Taxonomy that can be used to categorize content. When posting, a user would select the category of their content. It would be similar to how tags are entered in with Blog posts. Views would then be used to allow users to narrow down results to the particular category they want to see. 

Another question Trice had asked is how we shall we handle an ordered series of posts? I believe this can be done with an additional content type -- Collection. A collection is a grouping of Creations (text, audio, video, image). Creators can make Collections for their own material. It may also be possible for users to create collections of anyone's material by linking back to the originals. I haven't fleshed out the details here as of yet, but I have some ideas.

It's possible I may be able to configure the appropriate node types by the end of the week using the model I suggest. Refinement will take longer, of course, but I believe this is a good start for us.

One thing that occurred to me today is that we really don't have a good place to put projects on deninet. For a while, I had planned on implementing project management features on the site. I did manage to start some of that by adding events and tasks. The further I got, however, the more it became obvious that "wasn't us". Other sites do project management far better and if anything, we should leverage those.

Project management, however, isn't the same as project -- is it? The former implies task lists, schedules, events, Gantt Charts... These aren't the features I wish to develop or maintain on the site. Again, other sites dedicated to that purpose do it far, far better. What I'm thinking about is a place to showcase our projects. 

Let me give you a little history: Years and years ago I came to the realization late one night that what we seemed to have in abundance was ideas. What we needed was a mechanism by which to store and categorize them. This was the beginning of a project called Net*man*a*ger. It was a Java based client for entering and storing ideas to a remote website running a Perl backend. Hey, it was the early 2000s, thick clients were all the rage! I spent most of my holiday vacation that year happily steeped in Java code.

As I began to put together the interface, I created a data topology. Ideas were made of Versions, Versions had Thoughts contributed to them, Comments and Votes were applied to Thoughts. Soon, however, I began to realize that Ideas needed a top level container. Naturally, the first one I thought of was "Project". The more I thought about it, however, the term seemed limiting. Not all Ideas could be grouped into projects, some were just....ideas. So, I instead decided to use the word "Net".

Eventually as client matured, I began to realize that it would be far simpler to develop a website that was both the backend and the front end. This was a couple before "Web 2.0" became a popular buzzword. Add more than a dash of ambition, and the "Internet Idea Database" was born. The term "nets" were dropped and replaced with "Channels".

I worked for years on IIDB, but there were a lot of problems with how it was put together. The code was too constrained and not easily expandable. I no longer wanted to work on the project, and as the system powering our website, I was stuck. I chucked it all and switched to Drupal. My thought was I could eventually reimplement IIDB on Drupal, but that never quite materialized. 

This is why deninet has channels today. First there were projects, then nets, and now channels. I had assumed that any project we wish to implement today on deninet could have a channel associated with it. These project-central channels would be the hubs by which visitors could find and follow project developments. This is why we have a Springboard, and why you can subscribe to channels to follow posts.

The biggest problem with this system is just how monolithic it is. How can we tell a "project-centric" channel from one that just is for general blog posts? There are a few ways to go about this. A field could be added that would identify the type of channel it is. This seems inadaquate however, as projects would have special fields attached to them like what users are working in what roles on the project, or the current status, or expected release date. Doesn't that imply that these should not be a channel but something unique?

I'm still figuring that one out...

One of the most requested features among our users (i.e., Me and the other four people using the site), is the ability to automatically save posts-in-progress. 

This turned out to be easier than I had thought to implement as the Drafts module provides all the needed functionality. 

Features of Drafts include:

• The ability to maintain more than one draft at a time.
• Maintain drafts for all content types.
• Autosaving of new posts.
• Autosaving of changes to existing posts.

Once you save a draft (or have it autosaved), it will be available in your drafts page, under the Springboard. Click the "View" link to open your draft. 

Enjoy!

Likes

• Simple markup. Easy to reorganize and format text
• Markup reference easily available, only needing to look up wikipedia's ref.
• Sidebar. search interface nearby main content. intuitive. 

Dislikes

• Not as good of image gallery. deninet does better. 
• "I'm not trying to publish, but create."

Tag pages

• Either overloads /taxonomy/term/[tid] or /tag/[term-name] or /tag-id/[tid]
• Channel like dashboard of posts utilizing this tag
• Tag Landscape? How often is this tag used? What content types? What users?

Tag pages for users

• /user/[uid]/tag/[tid]
• Similar to Tag pages, but filters down for one user.
• How often this user posts with this tag

Security Mechanism

• User centric. Lists built for "in" users and excluded users.
• May require custom development or simplification of current channel mechanism.