2 fixed delimiter issue
source | link

In my experience, it's a tough one to get right and often one that ends with more discussions than answers as editors are forced to focus on IA (that's not necessarily a bad thing though!)

I think the thing with XPM is that editors shouldn't need to know where the content is - they should be able to do everything they want to from the XPM interface as using in built page types in order to create and manage content.

This is likely where the vision for the XPM implementation of defining locations for components to be created at design time based on type (and a few bare bones naming conventions).

In my opinion it's a bit short sighted - editors will still need to look for content in order to add existing components to new pages and saying to an editor that they have to look through a folder of 'general' components for a global website just isn't feasible. Maybe search would go some way to helping with this, but given that editors don't control the naming convention of new components at content creation time, it severely restricts the benefits of search.

In the implementations I've been responsible for, our default approach (or at least recommendation to the client) is the page based storage structure design where content is created in folders mimicking the website structure.

As a default implementation, this is done through events code (like Mark mentioned above) which creates a matching folder structure when a page is created via a Page Type and moves all newly created components there.

As for configuration, all content types applied to Page Types are configured to create the new content in a set folder for all content (eg. \Content_XMGenerated\Content\_XMGenerated) and the events code then knows to pick up from this folder.

Mark's idea of metadata may well be a good extension of this approach though as it could give better control to editors as to where their content is - but if they're having to do that, then maybe their chosen IA model isn't quite as well defined as it should be...

In my experience, it's a tough one to get right and often one that ends with more discussions than answers as editors are forced to focus on IA (that's not necessarily a bad thing though!)

I think the thing with XPM is that editors shouldn't need to know where the content is - they should be able to do everything they want to from the XPM interface as using in built page types in order to create and manage content.

This is likely where the vision for the XPM implementation of defining locations for components to be created at design time based on type (and a few bare bones naming conventions).

In my opinion it's a bit short sighted - editors will still need to look for content in order to add existing components to new pages and saying to an editor that they have to look through a folder of 'general' components for a global website just isn't feasible. Maybe search would go some way to helping with this, but given that editors don't control the naming convention of new components at content creation time, it severely restricts the benefits of search.

In the implementations I've been responsible for, our default approach (or at least recommendation to the client) is the page based storage structure design where content is created in folders mimicking the website structure.

As a default implementation, this is done through events code (like Mark mentioned above) which creates a matching folder structure when a page is created via a Page Type and moves all newly created components there.

As for configuration, all content types applied to Page Types are configured to create the new content in a set folder for all content (eg. \Content_XMGenerated) and the events code then knows to pick up from this folder.

Mark's idea of metadata may well be a good extension of this approach though as it could give better control to editors as to where their content is - but if they're having to do that, then maybe their chosen IA model isn't quite as well defined as it should be...

In my experience, it's a tough one to get right and often one that ends with more discussions than answers as editors are forced to focus on IA (that's not necessarily a bad thing though!)

I think the thing with XPM is that editors shouldn't need to know where the content is - they should be able to do everything they want to from the XPM interface as using in built page types in order to create and manage content.

This is likely where the vision for the XPM implementation of defining locations for components to be created at design time based on type (and a few bare bones naming conventions).

In my opinion it's a bit short sighted - editors will still need to look for content in order to add existing components to new pages and saying to an editor that they have to look through a folder of 'general' components for a global website just isn't feasible. Maybe search would go some way to helping with this, but given that editors don't control the naming convention of new components at content creation time, it severely restricts the benefits of search.

In the implementations I've been responsible for, our default approach (or at least recommendation to the client) is the page based storage structure design where content is created in folders mimicking the website structure.

As a default implementation, this is done through events code (like Mark mentioned above) which creates a matching folder structure when a page is created via a Page Type and moves all newly created components there.

As for configuration, all content types applied to Page Types are configured to create the new content in a set folder for all content (eg. \Content\_XMGenerated) and the events code then knows to pick up from this folder.

Mark's idea of metadata may well be a good extension of this approach though as it could give better control to editors as to where their content is - but if they're having to do that, then maybe their chosen IA model isn't quite as well defined as it should be...

1
source | link

In my experience, it's a tough one to get right and often one that ends with more discussions than answers as editors are forced to focus on IA (that's not necessarily a bad thing though!)

I think the thing with XPM is that editors shouldn't need to know where the content is - they should be able to do everything they want to from the XPM interface as using in built page types in order to create and manage content.

This is likely where the vision for the XPM implementation of defining locations for components to be created at design time based on type (and a few bare bones naming conventions).

In my opinion it's a bit short sighted - editors will still need to look for content in order to add existing components to new pages and saying to an editor that they have to look through a folder of 'general' components for a global website just isn't feasible. Maybe search would go some way to helping with this, but given that editors don't control the naming convention of new components at content creation time, it severely restricts the benefits of search.

In the implementations I've been responsible for, our default approach (or at least recommendation to the client) is the page based storage structure design where content is created in folders mimicking the website structure.

As a default implementation, this is done through events code (like Mark mentioned above) which creates a matching folder structure when a page is created via a Page Type and moves all newly created components there.

As for configuration, all content types applied to Page Types are configured to create the new content in a set folder for all content (eg. \Content_XMGenerated) and the events code then knows to pick up from this folder.

Mark's idea of metadata may well be a good extension of this approach though as it could give better control to editors as to where their content is - but if they're having to do that, then maybe their chosen IA model isn't quite as well defined as it should be...