CMS's are technologically not ready to enable users to control all the design aspects of a sophisticated website.  When a CMS software product attempts this, it gets into very complicated yet boxy looking template design interfaces which prevent graphical web designers from implementing the good looks that they had planned on.  CMS Programmers inform the design people that actually X can't be done unless the programmers hack the system or do some custom code. Although these systems claim to provide easier template building, they often require programmer-level-training to construct anyways.

Presto has NOT attempted to be a boxed solution that includes a system for designing web page templates from within its backend interface.  Presto provides basic tools for web implementation programmers to bringing content into public at the code level on front end website templates.  In the future section we do talk about our work on an abstract HTML and forms interface, which may get back to this goal, but no guarantees yet!

On a related tack, unlike a number of CMS systems, we did choose to separate the administration interface from the front-end website.  One can argue that the reason good websites don't look like applications is partly because of this seperation.  If a user logs into a website (via the usual downplayed login form or link) to view front-end administration options, due to current technology constraints, the editing controls usually interfere with how the page looks.  They usually require elbow-space, and in the attempt to keep them in or near the area they pertain to, they break the template.  In the future, use of elegant DHTML menuing systems & page construction may get around the HTML earthquakes that WYSIWYG editing controls trigger. 

But a second problem arises: web pages are often a composition of different kinds of visible and invisible content, where each component item may need its' own editing environment, its' own focus of administration.  Secondly, content items may occur in a variety of contexts, and we often want to see what these contexts are, past, present, and future, or navigational, or by some reporting trait, i.e. from various perspectives (e.g. all events on hold, awaiting my approval only). 

Some simple intranet applications can be edited in situ, but many web pages and applications would overload front-end templates with options, and so need their own specialized "backend" editing contexts.

However, this doesn't preclude against the simple linking of front end items to a backend interface for editing.