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

I have read a lot on and have a lot experience in interface design/usability , and for people who are beginners, a completely transportation to a new environment (the back end in this case) is usually a quite disorienting experience.

You have to assume a quick edit feature should be a simple experience, since it is a function aimed primarily for beginners. Intermediate and expert users prolly go straight to the back end anyway.

I may be wrong, but I suspect that once MODx has convenient front-end editing of content and published status, the desire to merge the front and back ends may go away or at least be significantly weaker.

Right now, my users can manage uploads and photos and create new docs from the front end but they have to log out and log in as managers if they need to edit existing text or change publication statuses.

It’s inconvenient and something of a shock for them to see the back end but MODx lets you scale it down so it’s not so frightening.

An obvious solution is to merge the front and back end, but I think front-end editing is a much better solution and will eliminate any reason I have to want the front and back ends merged.

I’d have built in front-end editing myself but I’m assuming I’ll see it in 0.9.7 and, with the merging of web users and admin users, I figured I’d wait for the new version.

I think the comments about the conceptual separation of functions between front and back ends are right on the money, but we need a really clear definition of what we mean by front and back ends (although for convenience, the back end needs to duplicate some of the functions of the front end).

If the front end is about creating and changing what the naive visitor to the sight sees and the back end is about controlling everything else, then the front end should include creating new docs and editing existing docs (including pub. dates). It seems to me that QuickEdit for logged in front-end users is the easiest and most logical way to do this.

Bob

I’d argue that the MODx manager, as shocking as it may be is a lot simpler than editing HTML.

"What do you mean I need steering wheels and gas and all these mechanical, noisy things? This mechanical horse will never get anywhere ... it’s too confusing and people will never get it!" — some not-so-forward-thinking buggy whip maker a few years back

I’ve trained individuals ranging from auto mechanics to CEOs, and even the CEOs get it in about 45 minutes to an hour.

This thread is becoming one of my favorites, nice debate !

I’d second what Ryan says I have trained quite a few people, most of them not even "web proficient" and it was a breeze teaching them to use the backend. Remember the backend is dumbed down a lot for a "simple" editor and even a content manager. The full package is another story but quite intuitive nonetheless !

It does not mean we can’t improve usability, we sure do, but it’s not that bad ! And you might have noticed MODx has already undergone nice little touches, like the ability to access a document’s children directly from the document properties tabs, but there are little nuggets here and there. I am quite optimistic about the future GUI, just watching at what getting done by the dev team already This thread is a nice pool of ideas to get things even further

I think ModX has done a great job, and it is in fact the usability aspect that got me hooked in the first place. I trained two people a week ago, who are near an intermediate computer level. One picked it up in a snap. All I had to do was to explain that the tree view was like windows explorer. That really helped. Learning the right mouse click was a second. Helped even more

I envisage the front-end as a way to quick-edit, as the name of the plug-insays. Or as something as a wysiwyg text editor / image uploader. This is what you use if you were for instance a journalist / editor, or something you offer to computer illiterate clients. Click the edit button, edit some in-line stuff wysiwyg and voila, done. Adding a subpage to a container might be helpful. (Say you have a news section, and a webgroup with clearance for that section, than a button appears to add a document to that section) Such a button would be enabled by the developer ofcourse.

I love to hear more about whats in store 0.9.7...is there a plan / roadmap somewhere I can take a look at?

Quote from: Paintbox at Jul 18, 2007, 07:21 AM

I love to hear more about whats in store 0.9.7...is there a plan / roadmap somewhere I can take a look at?

http://modxcms.com/roadmap.html

Quote from: rthrash at Jul 17, 2007, 04:56 PM

I’d argue that the MODx manager, as shocking as it may be is a lot simpler than editing HTML.

I’ve trained individuals ranging from auto mechanics to CEOs, and even the CEOs get it in about 45 minutes to an hour.

I can’t disagree with this one. I trained all my users with a single email message containing the necessary steps to do what they needed to do using the manager. I didn’t get a single question or complaint and they’re now working away at it.

One of the many brilliant design features of MODx is the ability for an administrator to create a slimmed-down manager using roles so that no one needs to see stuff that would only confuse them.

Bob

Quote from: davidm at Jul 18, 2007, 04:42 AM

This thread is becoming one of my favorites, nice debate !

I reed that everyone, MODx developpers as well as users (even CEOs, that’s a pretty strong point! ), prefer a clear dichotomy. I disagree, but I understand: debating on that subject may look like debating about the sweeter ice cream savor.

By the way, I currently have to migrate a site from MODx to CMS made simple, mostly because the administrator is lost in the MODx manager interface, partly because we had bugs with the cache, partly because multilingual did not work, partly because fields in the member profiles are not customizable. But CMSms separates front-end and back-end either. There is no perfect cms.

Quote from: dernier_recours at Jul 18, 2007, 03:51 PM

partly because fields in the member profiles are not customizable.

For the record, that’s not quite true. There’s a whole extra table specifically for adding extra user fields. You have to write your own snippet to do it, but using eForm as a basis, it’s quite simple.

And my version operates through the front-end

True Astronut ... PPP + eForm is pretty cool from what I’ve read (no personal experience with that specific combo).