Furthermore, such a separation eventually goes a long way in abstrating the concepts for non-technical users (+ - 98% of my app’s eventual user base). Not to mention the fact that my “backend” development can go ahead in parallel to the design (look and feel) development. Thus, users get a feel for the backend and how it operates before they;ve even signed off on the highly subjective design aspect. As such, when the app/site finally goes “live”, the users are already comfortable with the operation and administration without then having to re-familiarize themselves with the fact that it now “edits in place”. When development is eventually complete, it’s much simpler then for the designer to just hand off the approved design for me to “templatize” and put the dynamics of the Website/Webapp frontend into place. This fact also alleiviates a lot of issues from the graphic designer’s perspective since he can then fully concentrate on getting only his portion of the development spot on since he is free then to specialize in and experiment with different layouts and CSS techniques.

Perhaps eventual improvements in AJAX and the like will enable us to TRULY make such “edit in place” options viable. I have been part of projects where the administration of content was built into the frontend itself and those projects have, BY FAR, had the most complaints, bugs, and (according to users) a steeper learning curve [beleive it or not] compared to the separated presentation and administration architecture.

In the end it’s all about the users after all so what’s best for them is what gets done.

Well browsing the content of a site and creating those contents are very different operations and they need a different interface. Mixing those interfaces is not a good idea. Very basic cms might not need this separation, in fact only amateur cms feature on-the-fly page editing (as far as I’m concerned). Not to mention security and caching problems as everyone pointed out.

I was going to pick up on this point, but someone else has noted it, so I’ll just add that I agree that for administrative areas, standards compliance is just as important and a requirement.

You can’t get around it, just because it’s not public facing doesn’t mean it’s not just as important; In fact if the standards offered were to drop for the administrative area, I would hold the designer/developer negligent in their duty.

As for letting ASP.NET [I]be[/I] ASP.NET well, that just about sums up Microsoft’s platform, now doesn’t it? Standards compliant? Pah!!

That is something they’ve never quite got the hang of, have they…

However, in every other way I have found the embedded admin interface to be an improvement over the separate backend, especially from a usability standpoint. If you’re expecting lay users to do content management, it’s got to be intuitive and user-friendly; users (myself included) don’t much like having to learn two separate sets of navigational and interface metaphors for what is, fundamentally, the same system. After all, a database-driven web application is, in a manner of speaking, just an artfully useful interpretation of an underlying database; why make the users learn more than one way of accessing that database?

Not that I disagree completely; there are advantages, especially from a security standpoint, to having a separate subsystem for administration. I especially appreciated what you had to say about locking down the public database user; that would be a pretty effective help against some common attacks.

I would caution, however, against assuming that things like standards compliance, cross-browser compatibility, and accessibility are unimportant in the admin interface, especially if you’re not developing for a strictly controlled corporate environment. For instance, in building open source applications, one has to be especially rigorous in one’s standards compliance in both public and admin interfaces, since standards compliance is the only reasonable way to assure the long-term viability of your application in a wide variety of uncontrolled environments. No one can guarantee, for instance, that their open source users will be using Internet Explorer.

Even though some web vendors disagree with standards compliance in practice, that gap is starting to close considerably…and in that bright future where all browsers interpret standard languages in standard ways, applications whose admin interfaces require non-standard behaviors will likely be tossed aside.