Recently I had the pleasure of traveling to Portugal for the SDL Web Most Valued Professional (MVP) retreat. While this was my first opportunity to participate in one of these events, I have seen the results of having some of the brightest and most willing-to-share minds in the SDL Web community brought together for the opportunity to collaborate. Often times in the past this event has helped to shape the future of SDL Web development, and this year was no exception.
The primary focus of this year’s event was the future of DXA and DD4T. I won’t rehash this discussion as it’s been covered extensively (check out Bart’s post here and the links he’s collected), however I would like to dive a little deeper into DXA modules, and some work I’ve been a part of to improve the experience users will have with modules today and in the future.
Under the thoughtful leadership of Alvin Reyes, I was part of a group that set out to formulate a plan for the future of the DXA module as a feature. You can read Alvin’s summary of the progress made here. As part of this discussion, Alvin laid out his core requirements for modules. A DXA module should be:
- Discoverable
- Contributable
- Manageable
While these points are all addressed today to varying degrees, I think there is room to improve across the board, particularly on 1 and 3. Along with Jonathan Williams and Robert Curlette, I’ve set out to do my share,  with a new Alchemy Plugin. The goal of this plugin is to put the configuration of modules in a single location, and to help users discover the wide range of configuration options they have for their modules. We plan to do this with a new tab added to the publication properties window.
This tab will list the currently installed modules, helping to resolve the issue many of us have faced when approaching a project with an existing implementation we’re unfamiliar with and don’t know what features are installed or enabled. In addition, it will display all settings for DXA modules, and allow you to update them in one location, instead of the scattered assortment of configuration components in use today.
As you can see, this is a work in progress. Right now, Jonathan and Robert are in the process of adding the tab and designing it’s appearance (img 1), while I work on the core service calls to retrieve and update the settings fields (img 2). We still need to combine the work we’ve done, finish the core service calls, improve the look and feel, and improve a number of features.
Why am I writing a blog post about a plugin that’s only a fraction of the way done? A couple reasons.
First, we gave a lot of thought to how this plugin should work, but as soon as we showed it to Bart Koopman and Alvin and laid out our plan they changed our mind on some of the key decisions we’d made. We know that if we share the idea with the community there will be more input that will push this plugin in directions the three of us haven’t even considered.
Second, we could use some help. This is an open source project, and we would love to have people get involved in building this with us. We’ve got a GitHub repo with our code and a Trello board with our todos. If you’re interested in getting your hands dirty with some code, please, reach out to myself, Jonathan or Robert, we’d love to help you get started, and who knows, maybe it can help send you to Portugal next year.
So, now it’s up to you the reader to help us build the plugin you want for DXA settings. Please post your feedback below. Is this something people will find useful? What features would help make configuration of your DXA modules easier? How can we improve on the plan I’ve laid out here?