At the 2016 SDL Web MVP Retreat, the big topic at hand was merging DD4T and DXA, as announced during the Tridion Developer Summit earlier this year. You might think that this isn't actually a big topic, since DXA has been using DD4T from the start already, but then you are forgetting that both frameworks were build by different people with different things in mind. Add to that the overlap which exists between the two, and you can see this could end up in a mythical battle. Luckily this years MVP retreat was being held in a convent, with most of the discussions taking place in an ancient church.

The actual merge of DD4T and DXA is overseen by the steering group (consisting of Nuno Linhares, Quirijn Slings, Raimond Kempees, Will Price and Wouter Kers). They had written up a manifesto for the merge prior to the MVP retreat and started with a feature analysis which could be used for the architecture discussions. On the first day of the retreat we all broke up into smaller groups to do get started on the following analysis tasks:

• Routing, controllers and regions & compare the Viewmodel approaches (DD4T .NET/Java, DXA .NET/Java)
• Application architecture / technical modules (what is a module and how does it work?)
• Functional modules (which modules do we need, how are they managed in CM?)
• Testing & continuous integration
• HTML design for example web app / requirements for front-end developers

Throughout the retreat all groups came back together to discuss their progress and there was also room for switching groups and broader discussions (which continued till deep into the night, as it always does when you bring a group of highly skilled professionals together for a few days in a remote location).

I joined the group to discuss the HTML design and requirements for front-end developers, since that has always been a pet peeve of mine. I was closely involved in the whitelabel HTML design of DXA, and took the merge as an opportunity to look at where we currently stand and how we can improve. Our team was small, consisting basically of Frank Taylor and myself, which meant we could have structured discussions without the risk of going off-track too much. We started off with determining what would be the initial goals of this front end module, to then start looking at the strengths, weaknesses and opportunities of the DXA whitelabel HTML design.

Initial goals of a front-end module

A well working module should:

• provide a visual for clients and users
• be professional level quality
• separate concerns

Strengths, weaknesses and opportunities of DXA whitelabel HTML design

Strengths

• good continuous integration
• uses modern tools
• enforces a workflow
• is open source
• and uses open source tools

Weaknesses

• doesn't communicate its purpose well
• not self-documenting
• TBBs aren't flexible for changes
• doesn't appear to separate concerns

Result:

Seems to encourage ditching entire module and starting from scratch.

Opportunities

• documentation
  • merge READMEs of current Git repository
  • provide "skinning" instructions
  • provide "for back-end / for front-end" info
  • communicate the back-end / build flow
  • visual aid for the workflow
• presentation
  • make the whitelabel itself the documentation, the appeal, and the instruction
• update the TBB
  • workflow improvement
  • two options: sources, front-end zip
  • Gulp build, Gulp package / npm package
  • remove requirement that Tridion executes any Node.js
  • positioning:
    • source build is for more discrete control (it's individual CSS/JS/... no HTML)
    • zip build is for quick deployment (contains CSS/JS in single file)
  • communicate workflow for adding modules

I'll go into further details on the opportunities in a next blog post, but let me highlight a few of them here.

Documentation

The current DXA whitelabel HTML design contains quite a lot of documentation, but it seems to miss the most important part, which is how it is intended to be used. There is information on how it can be built and updated, but we missed describing what we expected front-end developers to do with it exactly, which is style it by adjusting only CSS and JavaScript, without modifying the HTML.

Workflow improvement

Currently the DXA whitelabel HTML design is build at publish time using Node.js and Grunt. This results in a rather complex package structure, because we didn't want the Bower components and required npm packages to be downloaded each time when the design was published. This type of magic is what confuses the seasoned developers, and makes them decide to ditch it, while the current workflow for a front-end designer was actually quite good. So if we can clarify the workflow, start using Gulp instead of Grunt (since that seems to be more widely accepted these days) and remove the magic around the HTML design build process, we hope it will be more widely accepted.

Going forward

I have noticed that the basic styling of the existing whitelabel HTML design seems to not resonate with the community. The idea behind the current (lack of) styling was that the implementer would see the need for restyling, instead it seems to have encouraged ditching it completely. So going forward I think it makes sense to deliver two or three versions of the whitelabel HTML design, each with the exact same HTML, but styled differently. This allows for nicer demos and shows the viability of (re)styling.

We decided it would be a good idea to have the whitelabel HTML design available as an npm package, seeing as it is common practice to use Node.js and its package manager to build HTML designs. When you look at the next screenshot, you can see that it is fairly easy to get a package in npm.

The rest is history, but watch this space, since there is more to come.