Getting rid of the Front-end and Back-end dichotomy

Imagine that back-end functions a user has the right to use are available in a menu that appears on a page when the user is logged in (a kind of Quick-edit with all the MODx back-end commodities). And forms to post content, edit ressources, edit settings, manage users or use modules are all integrated into the template. This is not my idea; Drupal works this way.

Regards,

dr

Getting rid of the backend - frontend dichotomy sure is an attractive idea but I don’t think it’s the way to go. Don’t get mistaken, frontend editing can be improved and it most probably will. For instance, having the tree handy from the frontend would be great... Also, the inherited admin and web users dichotomy should disappear.

I don’t know about security concerns choosing to get rid of that dichotomy and giving access to backend features in the frontend, but I can say that from a usability standpoint, it suck IMHO. Drupal is a good example : the admin is cluttered, though Drupal 5.x has greatly improved things by grouping items and a more "sugar coated" web2.0-like design, I find it poorly usable... Overall, the interface is still the same linear/hierarchical logic and lacks visual hierarchy and intuitiveness.

The way I see things, interface have to be "layered", i.e primary / most used information first then second, third layer get you get more detailed or advanced feature. Also contextualizing things is key to user experience. Context menus and help are a great addition. This is all quite obvious to say, much less to achieve

Some have based their success getting the ligtweight, 20% features admin that gets 80% of the job done (think 37signals and Apple here). I think it’s a good target for the future of MODx interface, and the process is already in the works.

Indeed, the concept is not a big thing. It could be applied with four relatively minor modifications:

• theming the manager in a way it look like front-end
• synchronize the Preview window with the manager (for example, if I click on Blog into the preview window, the page "Blog" appears, but the document data does not change as it should)
• move the preview window before the page data
• load the preview window in the page, not in a frame

We could navigate front-end while editing the site or manage the whole site in an integrated manner.

No, for these reasons:

• Makes extensibility a nightmare - with the ability to create custom manager pages soon to come, moving everything to an unnecessarily complex front-end is a backwards step.
• Inability to properly display complex administration options - I don’t want to be editing Configuration options from the front-end, nor do I want to be browsing user security things either.
• Difficulty for usability - See user’s comment above
• Not 508 compliant - it’s a nightmare to try and make accessibility compliance with a ridiculously complex front-end manager

And others, but I think you get the point. MODx is not planning on moving to oust the backend - rather, you’ll see the backend become more and more powerful as versions come out.

Excellent points splittingred.

In addition, I just want to add a little about the overall MODx philosophy and vision in respect to splittingred’s points. The goal since day one has been to take MODx from a simple content management system into a flexible, and fully-customizable content management framework. A framework that would allow adopters to design re-usable content management solutions that could easily be tailored to the particular needs and skill-levels of their customers. Consider MODx a toolbox of building blocks for custom content management solutions.

With the new object-oriented API’s and AJAX-enabled connectors, we’ll be taking the biggest step yet towards this framework goal. You will be able to write custom management features like you describe into your front-end, quite easily, on a case-by-case basis. And if you do not have the PHP skills to develop these add-ons to the MODx core yourself, I think most of your desires (the ones that are appropriate for front-end access) will fit into future implementations of the QuickEdit add-on, which I’m sure will be maintained going forward.

I think one of the reasons the whole Front-end/Back-end dichotomy works is because it makes sense to the laymen end user. A lot of the content management systems I’ve played with where everything appears to be blended in such a way where there is no clear delineation between what is the content of the site and what is administrative functionality fail for this very reason. I think MODx works well because it is clear to an end user that the manager portion of a MODx driven site is what drives the functionality. And the fact it’s a framework means you can add-on to the whole paradigm and make it work differently and add functionality to the front-end as you see fit. The QuickEdit module is a good example of this.

The main reason a left MODx is because it is too much focussed on geeks. I seriously think that a single way to manage a site instead of two ways (add Jot, and let’s say two and a half ) would improve its usability.

I don’t see that [a powerful front-end manager] as a good solution overall.

What I do notice that users love the "edit" button of quick-edit. One usability step forward would be that it would edit in-line instead of in a new window.

personally i think the best implementation would be to seperate the CMS from the presentation (website) as much as possible, so people can quickly design a preview and a live website environment, where the preview would have f.e. an edit button inside the templates, which would redirect to the CMS backend and open the page directly. Hippo CMS has is implemented this way, and it’s quiet powerfull.

Olaf

That’s a great idea Olaf... should be straightforward to create a QuickEdit like plugin/module to do that I’d think.