Preparing for the Future of Aikau

Showing results for 
Search instead for 
Did you mean: 

Preparing for the Future of Aikau

Intermediate II
6 3 2,296


With the 1.0.96 release of Aikau we've introduced a new AMD package (simply called "aikau") that will give you a sneak peak of where things are going to be heading. This post is going to explain why we've made this addition, what it will do for you and how you can contribute to its success.

Future Directions

If you watched my recent Tech Talk Live presentation you'll have a good idea about the history of Aikau and you'll also have been given a brief overview of where we want to take it. The first couple of items on the road map were performance improvements and the introduction of Material Design styled widgets. Alfresco has decided to adopt Material Design and this means that at some point in the future we may want to update Share to use this "visual language" (Google's terminology, not mine). 

The simplest approach to achieving this aim is to convert more of Share to use Aikau, and then either update the styling of the widgets used to define the pages to use Material Design or swap them out with dedicated Material Designed widgets. 

At the same time we also want to apply the lessons that have been learned over the last 4 years to this new suite of widgets. One of our most valuable Community members (Axel Faust‌) provided us with some great analysis of how Aikau performs and we know that there is room for improvement. 

Right and Wrong

Some things we got right... Fine grained components that follow the "Single Responsibility Principle" (having learned our lesson from the coarse grained YUI2 components) being one and another being decoupling over a publication / subscription model (whilst adding complexity) to provide clean customization, easy enhancement and promote reuse. I did however initially imagine that a widget would only ever have one set of child widgets... and this proved to be incorrect and I also didn't focus enough on the performance of generating child widget at large scale. 

New Package, New Rules

Aikau is released on a weekly basis and every release is guaranteed to be backwards compatible with the last. We also try to avoid removing functions or changing their signatures to ensure that 3rd party widgets that rely on them don't break. This makes working on something as complex as performance quite an interesting challenge.

Therefore we've introduced a new package called "aikau" (the original package is called "alfresco") in which we're going to create our new Material Design style widgets that inherit from from new, performance enhanced modules. In order to make it easier to collaborate with the Alfresco Community the new "aikau" package will not be subject to the same stringent, backwards compatibility rules as the original "alfresco" package.

This means that we will be able to make breaking changes between releases should it be necessary and therefore you shouldn't start using these in production yet. Ultimately we want the "aikau" package to be a safe collaboration space that will eventually form a 1.1 release of Aikau. At which point the original "alfresco" package will be deprecated (but not removed) as there will be a full complement of Material Design widgets and production applications (such as Share) can begin to transition to using them. 

What This Means

This gives us the best of both worlds - the "alfresco" package will continue to be developed, new widgets will be added, bugs will be fixed and weekly releases will continue... but we will open up the contribution process of the "aikau" package to encourage more active participation without needing to worry about backwards compatibility or regression testing until we're confident that we've got the implementation right. 

If you have an interest in the future direction of Aikau and Share then now is the time to get involved. In my next post I'll showcase the new Material Design widgets and discuss what we've done so far and the other areas where we're looking to improve performance. If you have additional ideas of where you'd like to see Aikau go then we'd love to hear about them.

Video Link : 1083


First of all: Very much looking forward to seeing some core issues being addressed and not being restricted by regression tests for obvious (and personal) reasons...

I haven't looked to intensely at the code state of the package yet after you merged it on Friday, so I am not sure how much the following does apply.

One significant concern I have after the blog post, the video and looking at some of the code is that the new package will end up extremely entwined with "Matieral Design" stuff, potentially making it a pain to re-theme for devs. If it isn't separate / separable right now, I hope it can be one of the first priorities to extricate behavioral functionality from global styling concerns, or properly delegate the styling concerns. Ideally we would not need a "MdlDialogService" and could instead do with a "DialogService" that - via some to-be-designed mechanism - gets passed a "MdlWidgetStyler"/"MdlServiceStyler" to "upgrade" a bare widget/service to a "Material Design"-one. As far as I can see, most "Material Design" stuff is just about applying proper CSS classes (though in the case of the aikau/dialog/Dialog apparently also require experimental / poly-filled HTML elements).

Intermediate II

Thanks for the feedback as ever Axel Faust‌ !

The main reason for using the new Material Design widgets to demonstrate the new capabilities is simply because it is completely separable from the existing Aikau widgets. In the longer term I'd like to move the existing widgets to the new "aikau" package and take advantage of the new capabilities, but for the time being didn't want to create added confusion between the two packages. The Material Design widgets can be a vehicle to improve many things about Aikau (performance, templating, pub/sub, etc) and when we feel that we have a stable base we can take the "good" widgets (or ones that we want to keep) and move them to the new package.

As part of this process we will almost certainly want to abstract more of the common code (such as that in the DialogService) into common reusable modules. This would then make it much easier for different styles to be applied to common function.

I absolutely agree that we don't want to force Material Design style on anyone. We also want to be prepared that at some point in the future we may want to move to a different style (whatever happens to be popular at that point in the future) and want to ensure that this process is as easy as it can be.

Think of the Material Design widgets as a means to improve the core of Aikau and not as the ultimate end goal. This is likely to be the first step in a relatively long process. 

Senior Member

Axel, one of the things to bear in mind with Material Design is that it doesn't just cover visual appearance of widgets, it's more than a style layer; MD, when taken in its entirety covers behaviours, location of components, etc.