An Idea for Website Management

You may or may not know that I’ve been building a pretty sweet (in my opinion) website management system at Notre Dame. Every content management system of any sort on the web always starts with a text field for a title and a text area for content. Knowing this, that’s how Conductor started. Each page was made up of at least a title and some content.

The Trend

Now, with 13 sites live and another 16 in development, I am seeing a trend. Most pages on the web are more than just a title and some content. Thankfully, when originally developing Conductor, I tweaked some ideas that I liked from other systems and created page parts. Basically, we can put a page part in a template and a new tab will appear in the page editing area. The picture below has a main content area and three page parts (info, thumbnail and url).

The Problem

Nothing seems wrong with that idea, right? It allows us to store content in smaller chunks which gives developers more control over markup, which in turn gives designers more control over layout. Wrong. Exhibit #1: the edit window for a page using a faculty template on the law school website.

Below is an example page rendered in the template above.

We wanted to show things like biography, courses, and contact information in unique ways but not force content owners to mark things up uniquely. Because I assumed that all pages will be made up of huge content regions and not tiny pieces of data, the only way we could do that is by creating a page part for each item we wanted to store separately. This, as you can see in the screenshot above, caused a very tab happy interface. While this works, I believe it creates a sub par experience for the content owner (who does all of the updates). One reason I believe that is now the content owner has an entire text area, to fill in something as small as a website url, which could be better represented by a small text field.

The Solution

All of the above has led me to an idea. It might be something that sounds good as an idea but in reality would be awkward. It might also not be my original idea, as someone else could have used it somewhere in the same fashion I speak of, unbeknownst to me, but here it goes. All you need is a way to store data and a way to present data. Also, those two things are completely intertwined. How you want to display data affects how you want to store it. The more control you need when displaying data means the more separated the data needs to be stored.

Each piece of content that makes up a website needs two templates: one that determines how it is stored and the other how it is displayed. There could also be a third template that is how it behaves but I’ll leave that out for now. I think the ideal website management system has almost a form builder interface for developers to define what they need stored. From there, the developer should also be able to create the xhtml or xml or json templates that determine how the data will be consumed. The final piece of administration would be an area where content owners can fill in those created forms with glorious content.

The Use Case

Here is an example use case. Content owner wants to show courses on their website. Developer creates new content template called ‘Course’. They define the storage half of the template to be name and number as text fields, professor and semester as selects (from comma separated list of options), summary as a text area and order the fields how they should be presented to content owner. At this point, the content owner can begin entering name, number, professor, semester and summary for all their courses, while developer starts creating the other half of the template, which is how it should be viewed by site visitors. Developer dumps in xhtml, css, and javascript to view all the courses styled up to meet a designer’s every whim.

You might be thinking, uh, duh, this is what happens on every web application. Someone needs something stored, so you create your model and your controller and your views and you are good to go. You’re right, but that stuff always happens at the programmer level and requires a programmer to do it. What I’m thinking about would be at the software level and could be done by anyone with front end web development skills (xhtml, css and javascript).

The Conclusion

Once this beast was created, a front end web developer could build dynamic websites very easily tailored to a content owners needs and the administration of the website could be left in the hands of the content owners. The bad news is that I would have to start from scratch to build a pure version of what I just explained. The good news is I can get close to the same result using what I’ve already built in Conductor (more on this at a later date).