On a recent project I had a project manager request functionality to support Twitter Cards for pages on the sites we were building in Sitecore. If you look at the documentation, there are 4 different “types” of cards and each of them have different fields. Sometimes those fields are used in multiple types (ex. title, description) and others are only use on one specific type (ex. player:width). Luckily, Sitecore can handle this without much problem. In fact, I’ve begun work on a module that I intend to share in the Sitecore Marketplace.
Normally, I would start by grouping the fields that always go together into a single template and name it something like “Twitter Player Card Fields”. Within that template, I usually define a single field section with a virtually identical name “Twitter Player Card Information”, to separate it from all the other fields an item might maintain.
Problem is, the Twitter Card definitions are so splintered, I ended up making 6 different templates just to make the grouping of fields discrete enough that they could be used to build aggregate templates that only display the fields necessary for that case. No Content Editor user is going to want that many fields sections just to accomplish one task. That’s when I had a thought: “Can I combine these somehow?”.
Turns out you can. If you have a template that inherits from two or more templates that each have a similarly named field section, Sitecore combines them when they are presented back to the user in the Content Editor interface. Some I chose a more generic field section name of “Twitter Card Information” and renamed all instances.
Now when I build a usable template out of these base template, I get a much cleaner interface for the end-user.
This is functionality that has existed in Sitecore for a while but I hadn’t seen a post specific calling it out. There is this post in the SDN that digs a little deeper by talking about the sort order of the sections and fields, which is worth noting.
Overall, I think it’s important for developers building flexible and robust information architecture to also consider how that will impact the people who will actually use that IA.