Archetyped

Though it wasn’t a computing powerhouse, the iMac G4 definitely had one thing going for it– an LCD screen that could easily be repositioned with just one finger. Ever since I first played around with one of those years ago (way back in 2002), I’ve always wanted to experience such an ease of use on my own system. With all the software development and graphic work that I’ve doing as of late, I’ve been ending most days with a sore back/neck/shoulders/you name it. As a result, I am now seriously looking into acquiring a monitor arm that will allow me to easily position my 20.1 in widescreen LCD (Dell 2007WFP) at the optimum height and distance.

Continue reading ‘In need of some support’

While I’m still working out the exact method to define a content type, I’m far enough along that I was able to start working on the code to display the extra forms for each content type.

The idea is simple: Select a content type, and the additional form fields for that content type appear below the main form.

Today, I built a working example of just that. Most of the work now will go into making this functionality more robust and flexible.

It’s hard to keep working on the plugin when I find out that a new version of Wordpress has been released.

Lot’s of cool stuff from a user and developer standpoint. Read the announcement.

Sounds like there’s a lot of new goodies for plugin developers. I don’t know whether I should keep working on my plugin or spend the rest of the day playing with the new version!

I’m currently working on the Content Types feature of my CMS plugin for Wordpress. As previously discussed, I think this is an important feature for a CMS that is truly extensible and flexible enough to be used for any purpose.

At the moment, I’m working on determining the best way to define a Content Type and its options in the database. Some types of content will use data from wp_posts along with data from other tables (joins), while others will be totally separate, so it’s important that the definition format is robust enough to handle all sorts of types. From there, the next step is to implement that format so that I can easily (and efficiently) pull all data (including custom metadata from other tables) for a post (or group of posts).

Last night I reached a point where basically had all the core functionality I wanted for Lists. I uploaded it to the live server, and it worked equally well on my PC and my mobile phone. Awesome.

When I started working on it today, I felt that it still wasn’t quite as “dynamic” as I would like. I felt that I was doing too much configuration, and more of the inner working should be automatic for me to really call this app “intelligent”.

The goal again is to make a system where relationships are automatically determined and content is displayed based on these relationships. I’m at the point in development where I’m starting to work on the layout and structuring of the content. Things feel quite a bit less flexible If I have no single-use functions (such as a function to display lists and other to display items in the current list), but rather all content display is handled by intelligent functions and variable values.

So now, I’m about to rewrite a large part of the code to make things even more automatic. I’d like to get started on this as soon as possible, but I’m still working out some of the details:

• Just how object-oriented should it be?
• Should configuration (parent->child relationships, etc.) be set in the objects or based on the DB structure (or both)?
• What’s the most optimized way to fetch all the content while still retaining as much flexibility as possible?

Trust me, there’s more. I’m stopping for evening in the hopes that some time away from the questions will better help me find the answers.

I’ve recently started working on a simple web-based application in the hopes of solving on of (my) life’s little problems, which I am currently referring to simply as “Lists”.

The Problem: Whenever I talk to others, I’m always hearing about new things– restaurants I should try, movies I should see, books to read, etc. If something something sounds interesting to me, I’d like to take note of it so that I can try it. Now, since I first started using a PDA (starting with the stately, Palm Vx, say, 7 years ago or so), I don’t really ever carry paper or (more importantly) a pen around with me anymore. This was not really ever a problem with a PDA, as I could simply add a note to my PDA, which could later be synced to my PC, saving the item for future reference. I’ve since given up the bulk of having to carry around a PDA and a cellphone in lieu of a smartphone (the svelte Audiovox SMT 5600/HTC Typhoon). While my smartphone satisfies 99% of my on-the-go needs, there is no built-in tool to easily manage my ever-growing list of interesting things to do/see/eat/etc. (though 3rd-party solutions may be available). On occasion, I have carried around a pen and a bit of paper to write down anything that I may want to remember, but I wouldn’t consider this the ideal solution because it 1) adds the extra step of having to re-input anything I write down into my computer to add to my main list, and 2) having to carry more stuff in my pocket kind of invalidates my reasoning for giving up the utility of a full-fledged PDA for the pocketability of a smartphone.

The Solution: Manage lists of items anytime, anywhere using any web-enabled device.

The Implementation: Using a simple web-based interface, Lists enables me to do the following:

• Create lists to manage different groups of items
• Add items to a list
• Mark when an item has been done

As this tool is meant to help me when I’m on the go, it needs to be easily accessible via my mobile phone. In addition to the above-mentioned functionality, the following are also a priority for a good mobile experience:

• Speedy code
• Optimized layout of content (i.e. nothing superfluous should take up space on the small screen of a mobile phone)
• Full functionality without requiring fancy client-side stuff (i.e. no ajax, etc.)

Admittedly, this is a very simple tool to create. So to make this more of an exercise, I’m working on making the whole system as dynamic as possible. The goal is to make it as intelligent as possible with as little manual code as possible. All database queries, relationships (i.e. between lists and items), displaying of content, etc. should be automatically determined based on a minimum of configuration information (database info, etc.).

After a few days of planning and writing the code, I’ve currently got the basic functionality working (add/edit/delete lists, add items to lists, edit/delete items, etc.). The next step is to further optimize the code so that it is even more intelligent.

How would this be used?

When I hear about a movie that sounds interesting, all I need to do is select my “Movies” list and add the movie to it (via my mobile phone or any other web-enabled device). Then, the next time I’m in the video store looking for a movie to watch, all I need to do is check the list with my mobile phone and I can see a selection of movies that I know that I’d like to see.

The same goes for finding a place to eat when we’re driving around trying to decide where we should go to eat. With a quick look at my “Restaurants” list, we’ve now got a list of potential places to check out.

Even simpler, Lists can be used to create a list of groceries to buy while I’m at home, and then use my phone to reference the list while I walk around the grocery store. Saves time and paper. Sounds good to me!

Other Thoughts

This is a simple project made mostly for me personally. But I do plan on adding multi-user functionality so that others can use it too. I also will most likely provide the source code for download on this site once I get to a point where I’d consider it fit for public consumption.

Compared to other content types, media types (video, image, audio, etc.) are differentiated by certain characteristics:

• Media files generally need to be uploaded to the server
• They can be embedded in other content (posts)
• They require specific markup to be displayed

It is because of these special characteristics that content types classified as media are not treated the same as other content types. For the most part, media will be added when adding another content type (an mp3 for a podcast, a thumbnail image for an article, etc.). Nonetheless, they are still treated as a separate content item (which means that they may be selected and embedded in any other content item as well).

Some differences regarding how media items are handled:

• Upload Capability - Media files may be uploaded
• File Organization - Media files are saved into directories based on file type
• Embed Media in a Post - Media can be easily added to a post by clicking an “Insert Media” button, viewing a gallery of media items (sortable and filterable), and selecting the media item(s) to insert.
• Automatic Media Viewers - When a media item is displayed, it is automatically wrapped in a the proper markup to allowing viewing. For example:
  • Images (gif, jpg, png) are wrapped in <img> tags
  • Flash Videos (flv) are wrapped in a flash video player
  • Mp3 files are wrapped in a flash-based audio player

  The nice thing is that these viewers are simply the default templates defined for each of the content types. This means that:

  1. Viewers can be easily modified
  2. Default viewers can be easily overridden via a template for further customization

Adding new media types is as simple as adding any other content types (define the characteristics of the media type, create default viewer template, and you’re done).

Personally, I like the automatic viewers for displaying media the most. This relieves template creators from having to do this task, and all they have to do is add a simple template tag (show_media(), for example).

One of the best things to come out of beta testing this plugin in a real-world situation is the advent of new features. Had I been developing the plugin in complete isolation, it’s quite likely these new features could have been implemented completely differently (or not at all).

There are several little enhancements and optimizations all over, but there are two new features that I believe have the most impact:

Content Types

Different types of content have different attributes. While most content types share some attributes (i.e. title, main content text, categories, etc.), they often diverge from each other in their “supporting” attributes (aka metadata). In the case of Cinema Paradise, a film would have a certain set of metadata (director, length, country, etc.), while an event would have completely different set of metadata (time/date, location, etc.).

For a site needing to manage several different content types, there are two important questions:

• How is the metadata added to a post (and how is it stored)?
• How is the metadata displayed?

Adding metadata to a post

Generally, additional metadata is added to a post via custom fields and stored in the wp_postmeta table. When you write a new post, simply fill in the appropriate custom fields (or add new ones), and you’re good to go. This is fine for blog sites (where blog posts are the only content type), but for a content-heavy site where several different types of content are added regularly (articles, blog posts, etc.), this just isn’t acceptable. Not only would a large list of custom fields be disorganized and hard to manage, but on a site with multiple users (each of whom may only need to work with certain content types), there is a good chance that mistakes will be made (e.g. typing metadata into the wrong custom field, etc.).

To make the creation and management of different content types simple and effective, the following functionality was (or will be) introduced into the plugin:

• Add new content types

Users are able to create new content types and define its attributes. For each attribute, users may define the different characteristics such as data type, default values, etc. Some examples of data type are:

• Date
• Address
• Phone Number
• Database Lookup - (Creates a drop-down list of values fetched from the DB. Used mostly to create relationships with other content types)
• File Upload - (image/video uploads, etc.)

The order and layout of the content type’s attributes can also be set.
As an example, three content types from the Cinema Paradise site were “Director”, “Film”, and “Event”. Here is a breakdown of each content type:

Director

• Name - Plain Text
• Country - DB Lookup (List of Countries)

Film

• Title - Post Title
• Description - Post Content
• Country - DB Lookup (List of Countries)
• Director - DB Lookup (Items matching “Director” content type)
• Genre(s) - Post Categories

Event

• Event Title - Post Title
• Event Description - Post Content
• Start Time - Date
• End Time - Date
• Location - DB Lookup (Items matching “Location” content type)
• Select content type for a post

Once a content type has been created, it may be selected from a drop-down list in the Write Post form when creating or editing a post. When a content type is selected, a form containing a field for each of the content type’s attributes will appear below the post content text box. The user can then fill in this form with the appropriate metadata.

Each field in the form is not just a simple text box either. A specially formatted form field will be displayed depending on the data type for each attribute. For instance, a date field will have a field where a date (month/day/year) may be entered, along with a popup calendar for quick and easy date selection, and an address data type will have text fields for Street, City, State, Zipcode, and Country data to be entered.

This makes it simple to enter metadata for different content types, and because only the form fields necessary for that content type are displayed, the likelihood of user-error is greatly minimized.

A note on metadata storage

For the first implementation of this feature on Cinema Paradise’s site, a new table is created for each content type. Since there were a finite amount of different content types to manage, I felt this was the best solution (faster/more specific queries, etc.). However, I am currently reevaluating the implementation of how metadata is stored to best accommodate the creation of an unlimited number of different content types.

Displaying metadata for a post

Template Hierarchy

Once a post has been assigned a content type, the focus now moves onto how to display this extra data. First, when creating a new content type, a default template may be defined. This template will be used if no templates have been set for a content type in the template directory. If a template for a content type has been defined in the template directory, it will override the default template. Currently, content type templates are defined by creating a file with the same name as the content type (this may change in the future to better differentiate content type template files from other template files). Furthermore, content type templates may be defined on a per-section basis. This means that content of a specific type (e.g. an article or an event) can be made to look different from one section to another. Again, if a section-specific content type template is present, it will override both the global content type template file and the default content type template (only for posts in that section, of course).

Custom Template Tags (Conceptual)

Currently, metadata may be displayed simply by inserting $post->attribute-name into a template. This works and is quite simple, but I would like to align the display of a post’s metadata with the main data of a post which can be displayed using template tags such as the_title(), the_content(), etc. So for an event, a user could create template tags such as event_location(), event_start(), and event_end().

Honestly, I don’t know whether this is practical to implement, or if it is even possible. I need to look into this more.

Development has continued steadily on the CMS plugin for Wordpress. I am currently beta testing it on some projects to help me better develop this plugin for real-world use. The first of these projects is a site for an international film festival called Cinema Paradise.

So what did the CMS plugin do for the site?

• Logical/Hackable Permalinks - http://cinemaparadise.org/films lists all the films, while http://cinemaparadise.org/films/lady-vengence displays the details of one of the films in the festival (Lady Vengeance)
• Simple Section Creation - As easy as creating a page or a post in Wordpress (Actually, there are two ways to do it, and one way is even simpler than adding a page or post)
• Easily add content to sections - When writing a post, simply select the section the post should belong to via a drop-down menu (in the post form sidebar).

Other features, such as Section-specific RSS feeds, tags, and categories are available, but the client chose not to use them. But they are still there. For example:
http://cinemaparadise.org/films/feed

Next Step: Roll the additions (i.e. new features) and optimizations gained from working on this site back into the plugin itself.

Things have gotten a bit busy around here as of late, but I’m still working on building a more efficient interface for managing content. I have eschewed Wordpress’ default single-column interface for a more “explorer-like” two-pane file manager. The left pane will list the hierarchy of Sections. When a section is selected in the left pane, the posts in that section will be displayed in the right pane. I think this works much better than paginating the listing of posts independently for each section, as that can get quite messy real quick-like.

Ultimately, I would like to integrate drag/drop functionality to for moving files from one section to another. However, to keep things simple initially, it’s simply going to be form-based

1. select the posts
2. select the section to move the posts to
3. click submit

I’ll post an screenshot of the interface once I get it working.