Does anyone have input on best practices (and side effects) of folder (not structure group) structure decisions on an XPM implementation?
I would always tend to option 1. as it makes content easier to find for content editors, and simplifies the creation with Page Types etc, but I'd be interested to learn other peoples experiences
I guess if you're working with Editors that concentrate on the content, types and reuse but don't really let the site structure impact their conception of the IA then option 1 would seem to suit best. Of course, an important factor is the experience (and perceptions) of the editors' themselves.
I've worked with editors that were closely engaged with the IA stages of the design and then I've worked with editors that have been introduced / worked primarily from a 'page' perspective for several years.
I've a client that has the folder structure to closely match the SG structure (to placate an editor group list the second I mention above) and then sub-folder this content by it's Type (as the {new group of} Senior Editors prefer to think from the 'Type' perspective. I guess this wouldn't achieve what you want in the XPM Page Type creation model as the specific type are spread across several (sub-)folders and not in a single location.
update: a quick thought... you could have event system code that read some sort of metadata (or looked at page usage) to relocate created content of specific types - so the XPM Page Type Creation can be in place and the components are then moved to something that (for the editor group) more closely matches their model of content structure.
also I'm aware that this 'mixed model' presents challenges for content re-use across multiple pages - but some clients are simply very thin on re-use {requirements}.
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...
I'm adding some thoughts on folder (and naming) conventions a bit later.
+1 to organizing XPM-created (or even CME-created) Components by content type. My first implementation even had a preference for the Schema name (singular) so we had folders like "Press Release" or "Article."
The benefit here promotes reuse and make it easier to find content by its type.
In addition to organizing by content type and possibly automation to move Components, you could also help organize items by using Custom Content Types.
The custom place holder values for custom Content Types such as %P%. By using %P% in the name for a custom Content Type, the Component created from the prototype will include the name of the Page in its name.
Similarly, for date-based types of content, use the %D% placeholder.
Multiple Content Types that may use the same Component prototype, but vary in where the Content Type is created.
From the editor's perspective, they could choose between Content Types such as "Banner Single" or "Banner Multiple" and even if they were based on the same Banner Schema. In short, the folder organization doesn't have to be 1:1.
