Monorail CMS

Chronicling the development of a content management system built with Ruby on Rails

[monorailcms-blog]

DrupoomlaPress

Back In The Day

Highly skilled technicians would use things like text editors and FTP clients to magically produce static HTML files. cgi-bin was the heart and soul of contact forms the world over. And this wizardry was controlled by a choice few, fueled by the nectar of Mountain Dew, with lofty dreams of engaging in reciprocated, prolonged, and delibrate eye-contact with the opposite sex.

Since then, in a quest to find time to improve their eye-contact skills, a few brilliant individuals found ways to write programs that would generate HTML files and how to store “content” in databases. Not long after one of us actually got a date, WYSIWG editors started making appearances so other people could write “content”, store them in databases, enabling scripting applications to render HTML.

Now it's possible in many solutions to create dynamic email-forms, manage user authorization, and create virtual objects with relationships and attributes that once required a dedicated professional to create, deploy, and maintain that functionality.

The trend seems obvious. What used to be the work of a developer is being abstracted away to checkboxes, plugins, and one-step installers.

Enter DrupoomlaPress

The top three CMS' in the world: WordPress, Joomla!, and Drual. Each has their fans and detractors. Each can point to various high profile sites and sizeable developer communities as evidence they are the preferred choice. And they very well may be.

My primary contention with these solutions (and others like them) is not the languages or technologies utilized. But that they try to do too much. They intend to be the "Be all, end all" solution, suffering from what I call the DrupoomlaPress syndrome.

There will always be an growing level of automation and abstraction happening in technology. But when does that mean we have to “bake” every ounce of logic and functionality into frameworks, plugins, gems, and libraries?

Seth Godin has observed the growing trend wherein the middle man is dying. Could the same be true for developers? Are developers a relic of a bygone era? Is the future merely developer-turned-power-users, manipulating web-based GUIs to create functionality and experience? Is the future of web development wrapped in a form tag?

I don't want it to be. And I don't think that will be the case, because developers are not middle men. Middle men are about control, and monetizing that which they haven't created.

On the contrary, developers create, design, innovate, and enable progress. And therefore, developers will be in demand for some time to come.

True, not every website needs a developer. There is a place for such frameworks as Drupal, and WordPress. But as useful as a hammer is, it's not the perfect tool for every job.

Monorail CMS (or whatever we call it) is not intended to replace developers. It will be designed for editing content. It will provide an admin interface. It will deal with URLs and 404s. It will be designed with opinions (some with which you'll disagree). It will have some measure of a learning curve. It will have conventions.

But it will not seek to be your application. You will not become a Monorail CMS developer. There will be no such thing. You are a Rails developer will code Rails applications. And should you choose, you can add Monorail CMS to it. You will be able to extend and overwrite the CMS code. Your code will not live in the form of database records manifesting themselves in a series of drop downs, checkboxes, and inputs.

Monorail is not a framework. It's a tool to help manage content and the various aspects associated with that. I won't lie, there will be scenarios where the line between "CMS" and "Framework" will become blurred. In fact, we may cross that line. Hopefully, we will have very good reasons for doing so.

But one thing is for certain, Monorail CMS will let developers develop.

[monorailcms-blog]

Guiding Principles

Decisions, Decisions, Decisions

We've talked about how we will make decisions in building this CMS.

Here's a simple list (I'll expound on these later) we have settled upon as the principles that will guide the decisions we make.

In difficult, and possibly conflicting scenarios, we plan to err on the side of these concepts:

Just Rails

Design First

Non-Technical-User Centric

Adopt Best Practices

Let Developers Develop

Opinionated Software

[monorailcms-blog]

What's In A Name?

From There To Here…

I've always liked this Pinky and The Brain episode because for the first time, you understood why Pinky said the things he did.

I admit it, my train of thought isn't always clear.

Sometimes, it's just weird.

And I don't mean weird like the brilliant thinkers who are able to envision worlds and solutions so wonderful the average human could never conceive.

Often, my train of thought leaves people slightly confused and mostly underwhelmed.

Monorail CMS

When trying to come up with a name for this CMS, Dave Kruse and I were joking about some outdated web terminology like extranets and intranets and specifically: portals.

After laughing about portals, I mentioned to Dave, we should call it Monorail.

So, here's how I got from "Portal", to "Monorail":

The word portal made me think of a time machine.

Which, in turn, made me think of Jules Verne.

Which, in turn, made me think of 20,000 Leagues Under The Sea. 1

Which, in turn, made me think of the submarine ride at DisneyLand.

Which, in turn, made me think of the Monorail train.

I like the name Monorail because:

The 50s DisneyLand art and advertisement was actually pretty cool. And could be a nice source of inspiration for the art direction of the CMS site.

"Mono" comes from the Greek word μόνος, meaning only, or single (think mono vs stereo). That made me think "Only Rail(s)", which is one of my goals for this CMS, that it be simply, or only Rails (more on that later).

So there you go. It may probably most certainly will change. But for now it's Monorail CMS.

1. This also made me think of the SNL skit about 20,000 Leagues Under The Sea. I didn't include it in the list, because I'm focused if you can't tell.