To Boost or not to Boost, that is the question
Introduction
Time marches on and with that time we seek to improve upon what we have created. So has been true of the Bootstrap framework (getbootstrap.com), first finding its way to Moodle in version 2 via a contributed plugin (moodle.org/plugins/theme_bootstrap) by Bas Brands, David Scotson with contributions by others. Then it became a core base theme, ‘Bootstrapbase’ alongside the existing ‘Base’ theme with a child theme of ‘Clean’ in Moodle 2.5. In Moodle 3.2 the Boost theme arrived encapsulating an alpha version of Bootstrap V4. Between this time the contributed ‘Bootstrap’ theme was updated to Bootstrap V3 and a few themes like my Shoehorn theme (moodle.org/plugins/theme_shoehorn) depended upon it either directly or indirectly. Finally in Moodle 3.5 Bootstrap V4.0.0 stable was applied (the current stable version of the framework is 4.1.3).
This passing of time and the maintenance cost of maintaining two themes sharing the same framework at different versions has given rise to a new core plan for themes. There are Moodle trackers for this but the principle read and discussion can be found on the ‘Themes’ forum: moodle.org/mod/forum/discuss.php?d=373899 – and this is what this post is really about.
Disclaimers
Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.
Other names / logos can be trademarks of their respective owners. Please review their website for details.
I am independent from the organisations listed above and am in no way writing for or endorsed by them.
All drawings and images are my own.
Problem solving
Everyone on this planet (or who started here and is now working in space), has a view of things. That view is based upon experience which is based upon the things we do over time. Each view is slightly different because of the singular given perspective of an individual at any one moment in time. In any given specialism an individual can have more experience contributing to their view of that specialism than another individual. That view can be based upon both good and bad experiences. For any given problem in a specialism certain experiences assist in the solving of that problem. An individual may or may not have all the experiences required to form a complete view in solving that problem. It can be the case that no one individual has all the experiences required but a collective group does.
What is proposed and what there could be
Making the Bootstrap version 4 framework work as a basis for themes in Moodle is one such problem. One of my specialisms is ‘Software engineering’ which is applicable to this problem and I have a ‘view’ on its solution. This is my view underneath my interpretation of Moodle HQ’s (‘core’) view:
The current ‘core’ view is that the Bootstrap frame work should be encapsulated in a complete theme for which other themes can be child themes of it. This feels to me like the Henry Ford paraphrased statement of “You can have any color as long as it’s black.” (please see ‘Any customer can have a car painted any color that he wants so long as it is black.’ under ‘My Life and Work (1922)’ on en.wikiquote.org/wiki/Henry_Ford). That this dual encapsulation of two different entities will be restrictive because other theme developers will have to first unpick the Boost features that they do not want before adding their own. It feels like a hybrid that should not exist, like an ‘Atomic genetically modified Swan’:
but it does, just sitting there oblivious to its surroundings. Maybe we need such a creature to gather up and filter the plastic from our seas. Then such an entity would be complete and fulfil its purpose as a single object.
On the flip side I can understand for maintenance that incorporating Bootstrap V4 within Boost will be less work for core to maintain the theme, but that should not be a reason to get the architecture wrong. What about Bootstrap updates? What happens when version 5 is released? What happens if another framework is wanted? Yes, Bootstrap v4 can be kept fairly pure of Moodle changes in Boost, but that is not human nature, over time little oddities will creep in and glue the two together.
Humans perceive the world as an entity that needs to be broken down into smaller manageable encapsulated objects that have a given defined purpose and attributes. You employ your senses to analyse the world around you and process the information they provide to form understanding of the objects you perceive. All objects have a defined purpose with specified attributes that allows us to identify them and know how to interact with them if needed. Therefore Boost is two objects combined into one, which feels wrong.
With my proposed architecture you separate the distinctive elements to gain the ability to cope with external change and only incorporate in a theme what you need. It also has the same ‘design pattern’ as was previously employed with ‘Bootstrapbase’ and ‘Clean’, so I don’t understand why this is a bad thing and should not be repeated.
Summary
So, where am I going with this? It is one of those things that is screaming away in my head that the existing core proposed architecture is the wrong solution. I cannot fully justify why. It is one of those ‘gut’ reactions that you know is correct for the future but you know only time will prove you right.
By keeping the framework and core theme elements apart but loosely coupled then you will get flexibility and therefore facilitate both creativity and the ability to cope with change.
I hope, just hope that this post is read by someone who has influence, can see my point of view and make a change for the better. Moodle not only needs to function well but be marketable with a user interface that is modern and meets the high expectations of an ever demanding learner exposed to the world of apps and mobile devices.
What do you think? Is there something I have got wrong or missed? Or do you agree with what I have written? Please do comment.
- Moodle 4 Security – A Review – 16th April 2024
- A little bit #fab – 16th March 2024
- Static framework – 16th February 2024
Hi Gareth,
Thanks for the article. Terrifying swan! As you know I’m also a software developer who has been working with Moodle for a number of years. Like you, based on general software engineering principles my assumption was that the theme hierarchy in 3.6 would reflect your proposed diagram above (although I’m not 100% sure I follow your MHQ proposed architecture diagram). In fact even back when Boost was announced I had expected that it would extend a new Bootstrap 4 base theme.
Further to the issue around including Bootstrap 4 and its tight-coupling to Boost it seems counter-intuitive that to achieve a theme without the opinionated UI of Boost (e.g. because you want to implement a highly custom theme for a client) the approach is to take Boost and suppress all the additional features which it adds when compared to Classic. This is conceptually opposite to how inheritance generally works in OO programming.
Having mentored colleagues starting out with Moodle over the years I’ve found that architectural choices and APIs which do not appear to follow expected conventions also lead to frustration and disenchantment. I suspect there may well be more strategic long-term reasons for Classic inheriting from Boost but from the perspective down in the trenches it can look a bit like a kludge to save API changes to Boost which may not be feasible at this time.
Thank you for your reply Joby.
In my ‘MHQ proposed architecture diagram’ Boost has the Bootstrap V4 framework as an embedded attribute and Classic / Fordson inherits from it rather than the OO way of having Bootstrap V4 as a separate entity that Boost inherits from (as shown on my proposed architecture diagram). Thus with ‘In fact even back when Boost was announced I had expected that it would extend a new Bootstrap 4 base theme.’ then unfortunately it does not.
And exactly with ‘counter-intuitive that to achieve a theme without the opinionated UI of Boost’, I don’t want to have a theme that inherits from Boost and gets the baggage.
I things stay the way they are, then as a fallback there could be a way for a theme to ‘cherry pick’ elements from Boost to get the framework only but harder to do.
Thanks for the article Gareth. I guess the fundamental question here is encapsulation vs abstraction and what does that imply for developers (especially theme developers) and users. Just thought I might clear up these terms for readers:
Encapsulation is hiding information about the function of a thing (in this case a theme).
Abstraction is a design process by which you identify what the key features of a thing (theme) should be.
So to phrase the question in another way, is it the business of Moodle Core Developers to hide away the details of the theme implementation where they are difficult to get at or is it their business to decide what the overall user interface (ie theme) should look like? This also raises the question of direction of an open source project. Moodle is built by many contributors and, one would assume, this is to the benefit of users everywhere.
Choosing encapsulation over abstraction is moving the needle away from open source and towards proprietary, would you agree? This will make life more difficult for third-party developers. Is Moodle now too big to care about those?
Like yours, mine is just a view and is, perhaps, mis-informed but I too would welcome debate that may, or may not reach the ears of those with influence.
Hi Richard,
With respect with ‘Encapsulation’ in this context you are 100% wrong. Encapsulation in object orientated computing is about hiding things in classes (object templates) so that they are hidden and protected from the rest of the program. But you’re describing it in a human context pertaining to the decision that is made upon which licence to use, open source or otherwise. So, yes the information is ‘hidden’ but from the rest of the program not any human reading / using it.
So I totally disagree. I’m not choosing encapsulation over abstraction, in fact that is an incorrect interpretation. My concept utilises encapsulation as a facilitator to greater abstraction by placing the functionality in the places it should be and having an ‘abstract’ base ‘entity’ that is the framework that requires another entity before it becomes the ‘theme’.
Therefore your interpretation is actually confusing, and with respect, will make things less clear and much more confusing for readers and therefore does not help to clear things up but rather the opposite.
Gareth
Awesome post Gareth.
I don’t pretend to understand every complexity here, because I’m not a developer, not even a highly-skilled Theme developer, but I’ve been around Moodle long enough to have seen that sometimes we go in directions that ‘interest’ or ‘appeal’ to developers, and the general population do not have enough knowledge to challenge these changes.
A classic example being changing Home, to My Home, to Dashboard.
Dashboard was chosen because ‘it makes more sense to more people’
Really?
I think 99.9% people understand what “Home” means don’t they? 😉
Anyway, thanks for sharing your thoughts, and that diagram, which helped me increase my understanding of the current Theme situation 🙂
Hey Stu, yes, we’ve talked about arbitrary changes before (like Home to Dashboard) – really annoying for trainers. I see that in 3.4 or 3.5 the method of selecting enrolled users was changed and, as far as I can see, for no reason other than someone, somewhere could.
I would really, really like a moratorium on changes to Moodle for say, one year, so core developers could just sit down and tidy up all the anomalies that have crept in over the years, both in the UI and in the core code.
From the user point of view, such changes are frustrating and lead to dis-enchantment (as I have seen in a few organisations recently).
From the developer point of view, Mustache is a favoured technology now but you won’t find it used consistently in core activity modules and core blocks and you will find coding standards vary as well. These variations are a barrier to entry for would-be developers.
Thanks Stuart,
Now that you mention about the dashboard, I realise that I’ve never thought of it that way! Is there an MDL tracker to change it back to ‘Home’ etc? If so then there should be and get some votes!
Gareth