5 ms·

Thank you for elaborating. The thing I noticed on the screenshots, and as I've reiterated in alot of comments is putting editing of a site outside, in a seperat

Thank you for elaborating. The thing I noticed on the screenshots, and as I've reiterated in alot of comments is putting editing of a site outside, in a seperate admin interface. I did not see the site that was being edited in one of the screenshots. I think placing editing outside of context makes it hard for mere mortals to relate to the editing. On the topic of different UI for different users I'm on the fence. Modes in interface design is considered bad, but I do see how they can be effective. I think the two mot important roles to seperate is technical and non-technical.

gk47 16y ago
Having worked with media organisations and many journalists, writers and content producers, most of them don't care to see the content in context. Content can be used across many different sites or syndicated, making the ultimate destination unknown.
- lovskogen 16y ago
  So the conclusion is: most people doesn't care to know what/where content they are editing? I don't buy that. I'll buy that it's a OK solution, but not a good one.
  - knieveltech 16y ago
    You may not buy it but it's absolutely true. I spent a few years doing CMS support and site development for one of the largest newspaper conglomerates in North America and based on the design of our in-house CMS it wasn't even possible to edit a piece of content from the page it was displayed on. The really bizarre part was, all the journalists and editors where totally fine with that. Their biggest concerns where making sure the content published to the right section and making sure it also got pushed to the back end system used by the pressmen.
    - lovskogen 16y ago
      I think journalists publihing articles has a too narrow use case to make a conclusion for all non tech users out there.
lshepstone 16y ago
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.

gk47 16y ago

Having worked with media organisations and many journalists, writers and content producers, most of them don't care to see the content in context. Content can be used across many different sites or syndicated, making the ultimate destination unknown.

lovskogen 16y ago
So the conclusion is: most people doesn't care to know what/where content they are editing? I don't buy that. I'll buy that it's a OK solution, but not a good one.
- knieveltech 16y ago
  You may not buy it but it's absolutely true. I spent a few years doing CMS support and site development for one of the largest newspaper conglomerates in North America and based on the design of our in-house CMS it wasn't even possible to edit a piece of content from the page it was displayed on. The really bizarre part was, all the journalists and editors where totally fine with that. Their biggest concerns where making sure the content published to the right section and making sure it also got pushed to the back end system used by the pressmen.
  - lovskogen 16y ago
    I think journalists publihing articles has a too narrow use case to make a conclusion for all non tech users out there.

lshepstone 16y ago

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.