Best practice for designing Experience Manager-managed tabs/sub-tabs component?

Question

I'd like some input on how to best achieve a schema design for tabs, that could contain sub-tabs and/or normal content. Pretty much like this one: http://os.alfajango.com/easytabs/#nested-tab-3

What needs to be content edited is

• the titles of the tabs and sub-tabs, as well as
• adding/removing tabs and sub-tabs, and then of course
• add the actual tab content (coming from another type of component like "article").
• the 1st level tab to be able to contain either sub-tabs or articles, directly.
• Both 1st level tabs, sub-tabs, and articles should be multi-value.

How would you normally do this? It's rather easy if we consider the traditional UI of Tridion, but given that the Experience Manager should primarily be used to manage this content structure?

Using SDL Tridion 2013 and DD4T for presentation.

Carl-David

Answer 1

Calle, when you say "given that the Experience Manager should primarily be used to manage this content structure" can you qualify if 'should' is a business requirement - remember that the XPM is a compliment to the Tridion implementation and not necessarily a replacement for other aspects/views of the product.

As the XPM exposes the end website, the editor would see the tabs in place and have access to the content within those for editing. In order to edit the structure of tabs (adding a tab/moving position) is this not something that would be best done within the traditional GUI view and it more structurally focused view?

What you describe above sounds like a (relatively) complex structure. Allowing tabs within tabs - is something not uncommon and as you indicate, often presented to editors through the use of container components/linked components - perhaps this is actually more appropriate.

The above said, it does sound like a technically interesting challenge ...

Answer 2

As much as I like the structured container approach, "content injection" can get unwieldy. As a balance between authoring needs, Experience Manager features, and maintainable development, consider CPs for the first level tabs and embedded schemas for the nested tabs. Use containers if you need re-use.

Main Tabs as CPs

Consider at least Component Presentations (CPs) on-the-page for the the first-level tabs. This simplifies content creation, enables drag-and-drop in Experience Manager (XPM), and gives you flexibility to change the CP layout from the page template (or view, if you will). Each component is also re-usable.

I outlined this approach in this post about CP-driven navigation.

Sub-Tabs as Embedded Schemas

For the second level of tabs, consider using embedded schemas. The typical "paragraph" or "body" embedded schema helps create the repeating sets of markup, which could display as tabs based on a template selection (or your view).

I describe the flexibility in using embedded schemas in this post on TridionDeveloper.

Containers for Re-use

If you need to re-use the individual sub-sub-tabs as separate components, then include the basic container approach. In Experience Manager, authors can still open the container in form view to add, remove, and re-order the individual components.

Configurable Regions

For the "ultimate" approach, consider configurable regions. A component presentation could create the JSON format needed to allow drag-and-drop in Experience Manager. Your page template or view logic must place CPs into their matching regions.

The best practice really depends on a given organization. I've seen teams disagree with having any page logic (authors had "ultimate flexibility" to create what they want at the CP level). I've also had some seen many authors struggle with containers.

So you'll likely need to adjust any best practice suggestions into a "best fit." My current "professional recommendation" is to test out some authoring scenarios with at least your power editors before committing to an approach.