Apologies for the delay in reply, quite busy at the moment. A couple important points to address from your comment. That site only has a few screenshots taken

Apologies for the delay in reply, quite busy at the moment. A couple important points to address from your comment. That site only has a few screenshots taken from the UI, so unfortunately not all of the functionality is adequately represented. The product does actually have this capability, but as other have pointed out in the comments, this feature is low down the list of requirements for media customers as wasn't used much by journalists..hard to believe I know, but true. To your point, this is the difference between what we called in-context editing vs a dedicated console. It is interesting to note that Vignette has a general purpose CMS product and in that case, the in-context editing screens are almost the primary editing mechanism, definitely in the top 3 features for any general corporate users. We found in research this was due to most users on a corporate site are "occasional" users. Corporate sites don't change that much so users just need to edit a few things a week, maybe a few things a day on large sites. But for a Media site, they put out thousands of new content items a day and users log into the CMS at 9am and logout when they go home. In that case, they are dedicated users and they don't need as much hand-holding about what the page will look like, they know what the template looks like and generally the content is being syndicated in 25 different formats so it is kind of pointless to look at just one format. It is also possible to make a more efficient UI for a dedicated console. Think about it..you manage a CMS that has 50 sites in many languages and 100,000 pages or more and you need to edit a page 3-4 levels down in the nav...as an advanced user would you prefer to navigate through the site and wait for each page to load before getting to the page to edit...or do you do a quick search or filter (or navigate by ajax tree if you only know its site location) and then make a quick change? Quite amusingly one of the biggest requests we had from a really large media customer was to put in a search box so the could type in the id of the article (as in article 101995) so they could get straight to an article. I thought it was a bit of a crazy request at first but when you sit with media staff and the editor is shouting across the newsdesk floor to get the story out in 30 seconds, you understand that typing in a 6 digit number is faster than browsing 4 pages or even searching sometimes. I don't quite agree with the view that the most important roles to separate are the technical and non-technical. It might just be my personal experience but I've never been asked to build a CMS UI for a technical person, technical people are normally the ones implementing templates and are generally capable of learning any UI quickly. Normally I've been asked to design the UI for non-technical users, and the real challenge is optimising for "occasional" users vs "dedicated" users. Generally the UI you would design for one is really different than the best UI for another...for the occasional non-technical user you really need to hand-hold with in-context editing and things like wizards. With dedicated non-technical users they want search or filter based screens and bulk editing. The real trick is to achieve a UI that looks and works simply, but if the user wants can slowly reveal more advanced functionality over time...because user get more competent the more they use the tool. Regarding different UI for different users, it is certainly not modes which are generally used one at a time. The workspaces are more akin to presenting the best UI for the task you're about to accomplish...so one user role can span across multiple workspaces. One of the biggest things we discovered after observing users closely is that many people act as different roles depending on the context. So the same user goes from creator, to reviewer in one day, then switches to manager when he does the night shift sometimes. This is the real world, certainly for media companies at least. (i.e. Even the editor still contributes sometimes). So the different workspaces are not modes, but rather optimised for a particular common task like "working with media" or "reviewing". I agree that you can't generalise from what is quite a niche audience, the media vertical. I do maintain though that the CMS platforms built for media companies have the most hard core UI's out there for any CMS because media customers have high end requirements and pressures no other CMS users have. So if you're interested in cutting edge UX for CMS tools my extremely round-about responses were meant to convey that you might not find it in general purpose CMS tools but in specific audience focussed systems, especially Media. I maintain that you'll be able to achieve the best UI by closely observing the needs and actions of a defined audience, and that approach will always beat the general purpose targeted UI. Just look at Wordpress, awesome UI for blogging but honestly just average as a CMS (good enough for many cases, but not amazing) when compared to lets say Expression Engine. I don't know what you're requirements are, but if you have any opportunity to narrow your audience (or tasks covered) I would highly recommend it after I discovered just how much that can improve your UI.