Thinking of updating the default DXA blueprinting structure? I’ve outlined some of the commonÂ scenarios toÂ helpÂ considerÂ how to best structure your DXA implementation.
Why change the DXA blueprint?
The out-of-the-boxÂ blueprint is great for sites that have completely different content whilst sharing common functionalityÂ but does not allow for (a) sharing of global contentÂ (b) differing functionalityÂ per site (c) differences in local content.
The great thing is that the simplicity of the default DXA blueprint allows for many variations of extension. Creating just a handful of publications canÂ get you on the way to a more suitable structure for your organisation.
Each example below shows the default DXA structure (left) with myÂ recommendation (right).
TIP: It may be worth downloading each variation thenÂ flicking between them to easily see the differences.
Same functionality – SameÂ content
Use this when you want multiple sites with the same functionality and the same content.Â The importanceÂ here is the global content at the 300 level which allows you to share content between DXA sites. Notice that you can always localise components at the 400 level for any site specific content.
Same functionality – different content
Here we allow for sites with theÂ same functionality andÂ shared content but we introduce an additional translation layer so we can have multiple sites of a specific language.
Different functionality – different content
Imagine you want one content managerÂ to host a multitudeÂ of DXA sites all inheriting theÂ core functionality whilst allowing for additional functionality per blueprinting flow. e.g. you have 2xÂ site types, ‘marketing’ and ‘corporate’, they’re both DXA but differ in specificÂ functionality, i.e. one uses social media and the other doesn’t.
In this scenario our ‘100 master’ will contain the out-of-the-box DXA module (core) and the 150 level will containÂ modules specific to a site variation.
‘200 global content’ allows us to defineÂ shared content whilst the 250 level allows us to define content specific to site type.Â
Different functionality – different content (with Translation)
Same as previous but we take this one step further and introduce a translation layer.
Requirements differ per implementation but I hope this providesÂ you a foundation for designingÂ your DXA blueprint structure.
Note, you’ll most likely end up moving some pages between publications to match your chosen layout e.g. creating your search/HTML design page where appropriate.
Nice post Jon. I’d also comment that the architect should really be considering / discussing with the client what the longer-term plan is for DXA driven sites. Whilst the initial concept has been to put out a quick minisite (something some clients would have previously moved away from the CMS and towards WordPress etc. for) – they can very quickly start to move from the ‘minisite’ mentality to expecting DXA to be almost as flexible as a traditionally Blueprinted model – having some sites share functionality and some sites share design and some – well – both!
It will be interesting to hear the experiences of others working with clients and what their expectations of DXA evolve into…
One discussion we’ve been having is if the design publication is needed anymore. I hinted at this omni-channel BluePrint in this post: http://www.createandbreak.net/2014/01/carbon-20.html. It’s nice seeing some of the same patterns in your post.
One thing to be careful with the last translation example: separating the content between 250 Marketing and 250 Corporate can double the number of language Publications and non-localized global content (since it’s shared across both branches). I’ve seen this fit organizations with fewer translations or a small number of branches. But it can get unwieldy if the branches or languages increase.
Nice post and thanks for sharing. But where’s the animated gif?