kevin becker portfolio

Case Study: InsPro CMS

view the site | back to web

The Problem:

InsPro needed a solution that delivered a custom and engaging website, and they wanted to be able to update it on their own.

The Solution:

My company didn't have their own Content Management System (CMS), so the solution was to create one from scratch that could ultimately be reusable for future clients.

The Reasoning:

There are plenty of fully developed open source CMS's out there, but I've always had a problem with them. Despite the robust functionality that is already prebuilt into the existing CMS's, the admin interface on most of them is too difficult to use for an everyday client (who potentially has no technical experience).

I wanted a CMS that had all of that functionality, but I wanted to present a straightforward easy to use interface with certain aspects locked down to prevent the client from making a critical mistake. One thing I noticed while working with CMS's from other developers, was that they either made the page editing integrated within the website or they made you go through an arbitrary list of pages to find the one you needed to edit. The first way is great for browsing the site and making edits as needed, but it can be tedious to find a specific page. The second way is great for quickly finding one specific page, but if you are browing the site and you find a page that needs an edit, you have to switch over to another window with the list to find the page.

Neither way is wrong, but neither way is ideal; both work well in certain situations. So I created both. In the screenshot to the right (fig. 1) you can see that once you log in to the admin section an admin toolbar appears on the top of the window and stays visible whether you're browsing the site or in the admin section. If you find a page you want to edit while browsing the site, you can click the "Edit this Page" button right on the toolbar. If you want to see a list of all the pages, click the drop down menu to view a list of pages, callouts, files, etc. (fig. 2).

As I said, I wanted to create an easy interface for the user. As you can see in the screenshot (fig. 3), the fields for page name, header text, and content are all separate. The content field utilizes FCKEditor with a simplified toolbar to allow the user to edit text just like in Word. Creating a new page, event, etc. brings you the same simplistic entry fields. A resource like an event (fig. 4) can have different information associated with it so most of the fields are optional. If the user wants to enter a location, they can. If not, it won't appear on the page.

That's all there is too it. A simple interface, but all the functionality a typical website would need. Plus all the code is reusable. A couple tweaks and a day or so to work the design into the framework, and the site is up and running faster than you can say "change order."

The Response:

So far every client we've used this for has been satisfied with the results. It's so easy to use that there is essentially no learning curve. The clients are often surprised that it only takes 15 minutes to walk them through everything they need to know during a web share/conference call.