Rethinking the Admin Interface

Over the past few weeks I've been doing a major overhaul of the "Simplist":/simplist_cms code base, the CMS I built to run this site. The biggest change is that I've been rethinking the way I approach an admin interface. (Much of my motivation and inspiration for this was drawn from Scott Raymond's "refactoring to REST":http://scottraymond.net/2006/7/20/refactoring-to-rest article.) Much of what I removed ended up being mostly admin interface code. Using Rails' @before_filter@ methods to protect dangerous actions (new, edit, delete) is pretty sufficient for a website that is mostly content. I also found that this allowed me to shorten my workflow when making changes to the site. I could edit a page without having to go through a special interface that duplicated all the information I already had right on the site. I'll go over this in much more detail once I make the big upgrade to the site official (probably over the course of a weekend), but the lesson I've learned is to give your applications one coherent interface. Sure, hide and restrict functionality as needed, but making one big monolithic wall between users and administrators is almost always overkill and not very "DRY":http://en.wikipedia.org/wiki/Don't_repeat_yourself.

2007-03-19T12:21:41+00:00

0 Over the past few weeks I’ve been doing a major overhaul of the <a href="/simplist_cms">Simplist</a> code base, the CMS I built to run this site. The biggest change is that I’ve been rethinking the way I approach an admin interface. (Much of my motivation and inspiration for this was drawn from Scott Raymond’s <a href="http://scottraymond.net/2006/7/20/refactoring-to-rest">refactoring to REST</a> article.) Much of what I removed ended up being mostly admin interface code. Using Rails’ <code>before_filter</code> methods to protect dangerous actions (new, edit, delete) is pretty sufficient for a website that is mostly content. I also found that this allowed me to shorten my workflow when making changes to the site. I could edit a page without having to go through a special interface that duplicated all the information I already had right on the site. I’ll go over this in much more detail once I make the big upgrade to the site official (probably over the course of a weekend), but the lesson I’ve learned is to give your applications one coherent interface. Sure, hide and restrict functionality as needed, but making one big monolithic wall between users and administrators is almost always overkill and not very <a href="http://en.wikipedia.org/wiki/Don't_repeat_yourself">DRY</a>. 117

Rethinking the Admin Interface notebook/2007/03/19/rethinking_the_admin_interface