In Moodle 3.2 we introduced theme Boost (based on Bootstrap 4alpha) with the aim of continually progressing the look and feel of Moodle and providing increased consistency across the different platforms (web, desktop, mobile).
In Moodle 3.5 we upgraded Boost to Bootstrap 4 stable allowing us to take advantage of the improvements in the Bootstrap framework.
Currently, we still support the Clean and More theme, which are both based on Bootstrap version 2. Supporting multiple frameworks and themes increases our development and testing efforts as all new features require development and testing across the different themes. In turn this means that less time is available to work on new features, bugs, and other user-facing functionality.
In the long term this is not sustainable and also not beneficial. We would rather focus our efforts on improving the core theme and ultimately serving our users better. Hence, we have established the following plan to phase out support for themes based on Bootstrap 2.
For Moodle 3.6:
Move Clean, More and bootstrapbase to the plugin repository; we will leave sufficient support in Moodle 3.6 core to enable users to download and use Clean and More should they require this (e.g. if they have custom themes based on Clean).
Provide a ‘Classic’ theme, based on Bootstrap 4 that is more in-line with the Clean theme, retaining the 2 and 3 column grid layout, and the classic navigation block.
This provides a solution for those users who prefer the classic style navigation and sufficient time for custom themes to be redeveloped based on Bootstrap 4.
For Moodle 3.7:
Remove the support for Clean and More from the Moodle core distribution.
Going forward all themes to be based on Bootstrap 4 based on the ‘Classic’ theme or Boost.
Open Source Development Coordinator
This is really bad.
The most popular themes in the Plugin repository with thousands of installs are built on BootstrapBase and you are giving three months notice that BootstrapBase will no longer be core?
We did consider rebasing our theme (Adaptable) off Boost some time back but didnt want to as we worried you would soon thrown Boost in the bin too so were holding out as long as possible to see if a Boost replacement came out before BootstrapBase was depricated.
We had expected a reasonable amount of notice, you could have set this plan out 12 months ago, not just dropped a note in a forum a couple of months before 3.6 is due for release.
The fact there is no sustainable plan for themes in Moodle is a real problem. IMO you should have been itteratively maintining BootstrapBase as you once did for "Base" in Moodle 1.X.
I don't recall Base being a 1,X theme, as it made its entrance in Moodle 2.0 and stopped being maintained when Bootstrapbase came on the scene in Moodle 2.5 and was depreciated in 2.6. Base theme was not updated as much as it could have been, while Bootstrapbase was being developed...there are a lot of areas that got missed off because of the timescale they had to work to. Hence the sooner they dump Bootstrapbase the quicker they can work on Bootstrap 4 and keep things neat and tidy. There must be loads of CORE files they could dump too, thus keeping things simple too!
Just my thoughts,
Jez - When boost was released - it was commonly known that the old themes would be eventually deprecated and that sites should start moving to newer themes. Theme developers have known this for quite a while now, so saying that you are getting 3 months notice isn't really completely correct IMO. As Sander mentions, 3.5 is supported until May 2021, so sites that want to continue using older themes can stay on an older supported Moodle release for quite a significant amount of time.
We have a large number of 3.1 sites that are coming up to be upgraded to 3.5 over the next 6 months and we have already been recommending that clients choose a new theme based on Boost rather than relying on an older existing theme. Some of these clients have decided to stay on an older theme but we had been making it clear that it was likely to be the last LTS release that supports their theme.
Any time spent by HQ staff on maintaining support for old custom themes is likely to decrease the amount of time those same staff are able to dedicate to UX/UI improvements on the core supported themes - If I was in charge of allocating resource I wouldn't be keen to allocate it to maintaining support for older themes - we should release the HQ team to work on improving the UI.
We were expecting this at some point so it is not a bolt from the blue. As mentioned we were holding off re-basing on Boost in case that was also replaced. If HQ had said last year 3.5 would be the last version we would have gone ahead and done that work.
Regards your last comment, I think the issue is that HQ just jump from one theme to another throwing the previous ones in the bin instead of incrementally developing a solid base theme. Maybe they will with Boost but I suspect that will get junked too in the next couple of years.
In fact we were right to hold off on re-basing on Boost as Classic looks like it will be a better option, in which case it would have been better to wait until Classic was in before pulling BootstrapBase.
As it stands now, BootstrapBase is being pulled and the best replacement for it is not finished.
I guess my issue is the of a coherant plan / roadmap.
we just assumed 3.5 would be the last LTS that supported the old themes - if it was still supported in the next LTS Moodle would be supporting legacy themes until at least 2023 which is crazy.
Personally I don't have a problem with the way HQ have decided to throw previous core themes in the bin... that needed to happen - I don't think you'll get anyone disagreeing with that. If Boost gets 'junked' in a couple of years because HQ has created a new better core UI with a better UX I don't think I'll be complaining then either. There is a lot of validity in the criticism often levelled at Moodle being ugly out of the box.
I am really glad HQ are dedicating a large amount of resource getting the core UI looking a lot better - this effort has been long overdue. I understand this makes it difficult for organisations with their own custom themes (we support a number of clients like this) - but sites get a full 36 months of support on LTS versions and don't have to upgrade every 6 months. (which is usually pretty hard for large organisations anyway.
I understand this makes it difficult for organisations with their own custom themes (we support a number of clients like this) - but sites get a full 36 months of support on LTS versions and don't have to upgrade every 6 months. (which is usually pretty hard for large organisations anyway.
Thats true if its your site and you are in control of when to upgrade and what version to be on. But if you maintain a popular theme, all the sites using your theme get affected by this. The reality is that a good number of sites won't find out about all this till they try upgrading and most probably have never even heard of bootstrapbase. Some sites will wait for the developer to get the theme rebased, which is a fair amount of pressure. Like it or not, it will cause disruption.
I don't see any need to for the 3 month time frame personally. It could just as easily be a 9 month time frame. And that would be better in my opinion.
I don't see any need to for the 3 month time frame personally. It could just as easily be a 9 month time frame. And that would be better in my opinion.
That just comes down to resourcing - HQ will need to dedicate resource to ensure support if it's in core for longer. If it's out of core they can get staff working on other things... IMO dropping it now and letting HQ staff work on improving other stuff is a win. I also wonder how many of the sites that use these older themes provide some form of indirect funding to HQ... I suspect there will be quite a few sites hosted by partners that use these custom themes and therefore provide some level of indirect funding to HQ - but are there enough to justify HQ dedicating resource to it? - I don't know...
I guess we just need to wait and see how HQ decides to dedicate their internal resources after hearing from people in this discussion!
It doesnt come down to resourcing at all, this is entirely down to Moodle HQ's shambolic "planning".
This decision / announcement could have been made 12 months ago on exactly the same timeline it is now with no extra effort.
We knew we would have to rebase that but were not sure when to do it or which parent theme to use (not knowing if Boost would be replaced).
Im not suggesting HQ maintain old themes infinitem, just give us a fighting chance to keep support for our themes going.
It does come to resourcing. But when a decision like this is made, its not just Moodle HQ resources. The 3rd party developer resources do not get enough consideration. It sounds like, "its good for HQ , so its good for Moodle, and its just tough for you lot who have to work in between classes and after work...we might give you a badge or something"
haha - did I hit a nerve? I did clarify that statement in my post above - HQ will be getting some level of indirect funding from sites running older themes - Only HQ will be able to comment on what sort of level this might be.
It's important to be aware that while many of us in the community (including myself) give our time away for free to maintain plugins/contribute code/contribute in the community forums - Development undertaken by "HQ" is mostly by paid staff* and it must be a massive challenge for HQ to balance where to direct this effort - I really have no understanding on the balance of this
If the "community" wants to maintain support for legacy stuff a bit longer then personally I think the "community" should step up and do this rather than asking for HQ to invest $$in paying for internal staff to maintain legacy code. This has been done a number of times in the past and I can think of some times when legacy code has been moved into the plugins db and HQ staff have also contributed further patches to help maintain them.
(I do also agree with some of the other issues talked about here in the forums - (roadmap/better communication etc.) - but I'll never get any real work done if I start commenting on that stuff!
*I know that some passionate long-term HQ staff spend some of their free (non paid) time on pet projects..
There are tens of thousands of sites running themes based on BootstrapBase and we want to provide continuity for those users.
Our largest site has well over 30,000 users who dont even know what a Moodle theme is. All they want is for their Moodle sites to remain consistent, to still work after being upgraded and to not have to re-learn their interface every year.
Moodle HQ make providing that continuity a lot harder than it needs to be.
So there is nothing stopping you taking on the recponcibility of maintaining it so that it's compatible with Adaptable!
While I agree this is entirely necessary, I do agree with Jez about the timescales.
I would suggest at least leaving BoostrapBase in core for 3.6, I believe Base and possibly standard were left in core when all the other pre-bootstrap themes were initially moved to the plugins database?
Personally, I'd prefer to see a bit longer period with Clean and More in the plugins database, and BootstrapBase maintained in core - maybe 3.8 perhaps.
There are huge numbers of sites using Adaptable, Essential and other popular themes.
My suggestion would be to move Clean and More to the plugins repository, signalling the future deprecation (3.6) but to leave BootstrapBase in place
BootstrapBase to be removed to the plugin repository (I'd prefer 3.8 but can understand 3.7) but ensure it is still functional.
Next LTS is 3.9, which seems to me to be an ideal time to finally drop support.
I realise that's a year longer than proposed, but given the huge number of sites using such themes, and the fact its only in 3.5 that Boost stepped up to Bootstrap4stable with the consequent significant changes in Boost itself, it doesn't seem unreasonable.
A few questions please:
- When will 'Classic' be completed so that there is time for 'Bootstrapbase' child themes to have time to upgrade before M3.6 is released?
- Why is 'Classic' not being put into M3.5 directly? I know there are 'rules' but they can be 'bent' in specific circumstances.
- When will the SCSS PHP compiler be fixed to support the full set of SCSS syntax such that BS4 elements like the carousel can operate correctly without a patch to the CSS? Or has it already? As a lot of working Bootstrapbase themes have carousels.
- What exactly will go into 'Classic'? As Clean adds a bit on top of Bootstrapbase and therefore BS2.3.2 child themes don't have to remove 'Clean' functionality because they inherit from Bootstrapbase.
- As the BS2.3.2 version of Bootstrapbase is being removed, then why is it not being updated to BS4 and then having Boost and Classic as child themes of it? Then that 'design pattern' (Loose 'Gang of four' reference) would be maintained as its an effective one. Therefore existing child themes of Bootstrapbase just have to update to BS4 and not worry about new added baggage.
- In the long terms are there plans to alter the architecture to be presentation framework independent? Therefore having a separation of styles - thus more encapsulated CSS that styles elements without framework specific references. Thus Framework styles + Moodle styles = output, but where the two are completely different sets without any intersection. Then any framework could be implemented.
- Are there plans to update FontAwesome from version 4 to 5 free? If so, when, if not, then why not?
- BS4 is now (as of the date of this post) at version 4.1.3, is the Moodle core version being updated in line with this?
P.S. I can see that you work for Moodle HQ but there is the site policy of 'Signatures in forum posts will also be deleted as they cause clutter and distract from the information and help provided.' therefore everyone needs to be aware that signatures are not normally allowed.
I can't answer all of your questions yet since some things still need discussion. I am working on the classic theme and there is an alpha version available here:
- The 1, 2 and 3 column grid.
- The settings and navigation blocks.
- Allow the use of Moodle presets.
- Adding a background image.
- Set a light or dark navbar.
- Set the site brand color.
- Use the global settings for a small and large logo.
- Adding custom Sass (pre and post).
It does not support
- css written in less
As the BS2.3.2 version of Bootstrapbase is being removed, then why is it not being updated to BS4?
Updating bootstrapbase to use Bootstrap 4 would result in something like boost without the nav drawer an settings dropdowns. All child themes would need a complete rewrite. I don't see any benefit of trying this.
When will the SCSS PHP compiler be fixed?
The issue with bootstrap carousels is caused by a bug in the Php css prefixer Sabberworm, not the scss parser. It is related to using @supports see https://github.com/sabberworm/PHP-CSS-Parser/issues/127. The fix for this MDL-61515 is waiting for peer review.
In the long terms are there plans to alter the architecture to be presentation framework independent?
The web version of Moodle will continue to rely on the Bootstrap framework and there will be no support for other frameworks. That said the Moodle architecture does support using another frontend like the Moodle mobile app through the addition of external / web services.
Ok, what is wrong with this (OO class diagram looking) architecture:
Seems to make sense to me as a good software architecture / design solution to the problem, that would be robust and future proof. If everything is a child theme of Boost, then you still get the 'Boost baggage'.
So it is a 'separation of concerns' (https://en.wikipedia.org/wiki/Separation_of_concerns) between the framework and the specific style pertaining to a given theme that implements that framework.
We are both wrong - multiple inheritance - More is a child of both Clean and Bootstrapbase -> '$THEME->parents = array('clean', 'bootstrapbase');'.
I don't understand what you mean by '2'? If you mean that I've used 'Bootstrapbase' twice but with different versions of the Bootstrap framework then that is fine as it's pure configuration management version control whereby a later version of the same thing gets upgraded - and as BS V2.3.2 won't be supported then no problem with conflicts. Otherwise, logically then Moodle would need to be named differently for each release, like:
M3.4 - MoodleMcMootface
M3.5 - ManicMongoose
Thanks for the link to your Classic theme. I’m currently working on a theme for Moodle 3.6 but I have run into some problems which appear to be in Moodle master. Such as the Navbar dark setting in the Classic settings seems to have stopped working.
That said, I’m not really sure whether it’s Classic, Boost or Moodle Core? On the other hand, as I’m on a steep learning curve, it could be me creating problems although I have not made any real changes yet...and sertainly none to the Classic’s setting page.
I am not sure why the setting doesn't work for you. But maybe this helps:
In bootstrap 4 the navbar is styled using the bootstrap classes .navbar-light and .navbar-dark and the colours used depend on a number of sass variables like:
$navbar-light-active-color or $navbar-dark-active-color
In Boost the navbar-light class has been hardcoded in the mustache template. In Classic I added the .navbar-bootswatch class so themers can decide which class to use adding some sass to a preset:
Hope this helps!
I saw the preset sass and did wander if that was causing the problem, of the primary color not showing up as I had expected, it being a setting.
The Morecandy theme I made had a unique variable added, and that worked well in that theme.
So I may do something similar in my new Moodle 3.6 theme.
There are lots of other things not working now as I progress and I may end up trashing the layout you have in Classic them.
To be honest I am getting the feeling that Moodle Themes are becomming overly complicated.
I think I may rend up using a simple layout from the BS Examples in their documentation.r and stick to the simplistic ways of doing things...
If you find any issues on the Classic theme please report them here or on Github! I would be interested to see how you would like to change the layout.
Yes Moodle themes are very complicated, hopefully in future we can make Moodle presets more powerful for styling Moodle. They are the preferred way of changing fonts, rounded borders, colours and more and are a lot easier to upgrade.
As it turned out it was my fault that things were not working as they should.
The only thing that appears to be not working correctly is the Usermenu colour its white on white!
Thank you Sander for letting us know the state of Moodle 3.6,
This is excellent news and well worth hearing about. I must admit it has been on the cards a while now so it's good to hear that it will take place when we move to Moodle 3.6.
Having been through changes since Moodle 1.9 through to 3.5, and recall feeling very sad at loosing 2.0 themes, but I do appreciate that times are changing, and we need to move forward, or else we shall loose the plot completely.
The Classic theme looks like it may be the answer to a lot of Theme developers who need a theme to work in Moodle and have the 'Holy Grail' three column layout again! Yes!!! I love it already!
Times are certainly changing, the University that lead the way on many UI improvements recently dumped Moodle for Canvas and more Colleges / Universiteis are set to follow.
Moodle is ugly out of the box and Schools / Colleges / Universities tire of themes breaking every year. Im not saying themes are the only reason Moodle is getting dumped but its definitely part of it.
Whilst as a theme maintainer you may consider this excellent news for a lot of colleges / Universiiteis without their own theme developers its a nightmare.
I think Moodle is hitting a growth spurt and might have to shake things loose to achieve the desired results. If you keep looking back you can't see where you are going.
When we were looking at what direction to go with Moodle 3.2 and the introduction of Boost it was obvious to us which way Moodle was headed.
In the future, it might be nice to give the more popular themes a head's up way in advance of these changes. While not official "partners" of Moodle we are all invested. Many of your partners rely on the good will of the community to offer themes with a look and extra functionality that help entice new customers. An email to devs back when Boost was first introduced might have gone a long way in helping the transition. Many saw the writing on the wall, but some were operating on what was being communicated at the time which was "we will support the older themes".
I would not blame the devs for being upset. Overall though, I think this is the best move for Moodle. You guys are hiring a great team, you are building momentum on catching up with usability, and the layout and Boost core just keeps getting better. Full steam ahead. Moodle needs to modernize in a drastic way.
Break free the chains and make Moodle what it can be to fully realize the vision of the world's best learning platform.
I second that Roadmap comment. I went to look at the Moodle Roadmap document and I found out all about the fabulous plans that Moodle HQ has for the initial release of Moodle 3.5. That's not a roadmap any more, it's a rear-view mirror.
Moodle HQ should be publishing a 2 year (at least) plan which shows all the major changes they want to make up to and including the next Long Term Stable (LTS) release (Immediately before/after the LTS the new 2 year plan should go up). The goal isn't to guarantee what HQ will deliver but to make sure the community knows that HQ has a plan and what the basic outline of that plan is.
I spent more than a little time looking around to find out what is going on with Moodle development and there was virtually nothing about the future of Moodle. Even looking directly in Tracker doesn't help much, there are 133 unresolved Epics. Looking at the Kanban board, it looks like one of the issues on the board has been "In Progress" since 2017. The Dashboard don't seem to help much either, none of the dashboards look much like "plans for the future".
So from an outside perspective, it looks like Moodle is drifting with no plan and no future. If anyone think that's wrong, then great. Convince someone at Moodle HQ to tell the rest of us what the plan is, and then we will think that it's wrong too.
thank you Sander for inviting me to participate in this discussion. My thoughts on Moodle themes are the following.
- Supporting 2 different frameworks generates a lot of problems. So best would be to provide a single framework, and move the older technology to the plugins repo as soon as possible. It is a pain for the really excellent themes based on BS2.3.2, but change is the only constant needed to have an excellent learning management system. I understand that theme developers might be angry about that, but moving on is necessary.
- New standard/classic theme: Great idea, but I fear it will be as ugly (sorry for this harsh statement, but that is all about the theme designing: make it more beautiful) as all other standard themes have been. Most people I work with do not like Moodle because it is so ugly. The standard themes were driven by technical aspects coming from developers and accessibility needs (which is excellent). But there must also be an aesthetic approach. If I install a new Moodle, then people must say: Wow, that looks great! If you have that in mind for the classic theme, then yeah! Maybe there could be a contest and a poll concerning the look of the new theme or at least someone involved who loves beautiful things. (By the way, making Moodle beautiful is a great way to motivate learners )
- Any technical approaches, that support easier creation of custom/child themes would be great. Maybe collecting ideas for that would be good.
- Another vague idea: Create the possibility of customizing parts of Moodle with "presets". Or something like a built in Mustache-Customizer, Or Mustache-Preset-Editor in order to minimize the need of child-themes. That would be a great feature of a classic theme.
- Also maybe provide more kind of global-mustache templates, kind of a mustache-library. I do not think every button or form needs its own mustache template....
- Users generate so much ugly content in Moodle. If there is a possibility to make it easier for users to create appealing content, then that would be a real great asset.
These have been interesting comments about Moodle being "ugly" out of the box. I tried to do my best to show how Moodle, D2L (branded by my university, and no longer used), Canvas, Blackboard 9, and Blackboard Ultra look when I first start them. Quite honestly, I really cannot say that one looks better than the other "out of the box." It is not until one starts adding content, maybe CSS, and more settings that any of these products start looking "pretty."
A few of my students have commented that my Moodle site doesn't look a pretty as their Facebook, but we are talking about two different functions.
So I am not sure if I accept the comments that Moodle is "ugly" out of the boxes. (Beauty is in the eyes of the beholder, it is said.)
In my own case, I am using Moodle 3.5, Boost, and some CSS to color my moodle. I don't run custom themes because they would take up too my of my time making my moodle "pretty," and I am more concerned about using my time on educational components that help my students learn.
Having said this, I can appreciate those who do want to make their moodles "pretty." At least with moodle, one has some flexibility to do this. This might be why there are so many custom themes being developed that one can add, but then you rely on the theme developer to keep a theme current and bug-free. Some theme developers are really good at this, and some maybe not so good. Yep, I have seen some really attractive moodle sites that make my moodle look a little blah, but my courses receive some of the best student reviews, so I must be doing something that is okay.
My attachment shows some screen captures of these various other LMSs (out of the box.)
I like the idea of getting more community engagement for theme development. The contest is also a pretty good idea. I would add the following criteria:
1. The theme should be as close as possible to being WCAG 2.0 level AA compliant (accessibility guidelines). In fact, someone should take a look at Boost and focus on making it compliant in the first place.
2. In order to make it worthwhile for developers to invest, there needs to be more than just prestige of claiming that their theme is part of Moodle core. I think developers want to see their name or their company's name in the listed somewhere in the theme behind the scenes like in the info box that appears after you first activate the theme. Either that or Moodle needs to make a big deal of who created the theme.
It takes many many hours of labour to create a theme and either Moodle HQ shells out the cash or they offer some kind of worthwhile reward.
An alternative to this approach might be to have designs submitted instead of themes. It takes a lot less investment of effort to design a good theme than it does to actually code it. The designer/developer would submit the design as well as the cost to create it. The winner of the design contest would be awarded a contract to develop the theme.
I also agree that every LTS release should include a new core (not necessarily base) theme to keep UI and UX things current so that Moodle doesn't end up lagging in the area of design again down the road. It might also motivate people to upgrade to the next LTS release if they like what they see.
No one disputes the need to progress and keep with the times but I am not sure leaving one base theme to rot then bringing in another, then another is the best approach.
I think Gareths comment / diagram referring to a properly maintained abstract theme would be a better approach. Had that been done it may have been easier to transition from BS2 > BS3 > BS4 > BS5.
I remember not long after BS2 was implemented there were people pushing for BS3. Martin quashed that saying "we have done enough for now" or something to that effect putting BS Base out to pasture very soon after it became stable.
Boost will also be left to rot which is the reason we have not already rebased our theme. I kind of hoped that BS Base may live long enough for us to skip a rewrite and go straight to the Boost replacement.
You are right about Moodle being ugly out of the box. I saw a Moodle partner pitching against Canvas recently. They gave demo.moodle.net as the reference site. I am 99% sure they will lose that tender. One of Moodles biggest strengths over Canvas is the ability to properly theme / brand it.
If you look at my examples of LMSs out of the box, I would not be able to say that Canvas looks any better than any other product. I don't use Canvas at my university because its functionality is lagging far behind Moodle. But my Course Designers seem to claim that one can drag and drop pictures into Canvas faster than other LMSs, thereby making it "prettier" faster. Canvas is still not "responsive," which puts it at least two years behind Moodle. My students claim that the only effective way to use Canvas with their smartphones is by using the Canvas mobile app, whereas my students claim that Moodle can be used from their smartphone's browsers.
In my situation, as a professor, I really can't do anything about the Canvas "theme." Since I run my own Moodle, I am free to do whatever I want.
(Sorry that this is a little off-topic from where this topic started. But when I see statements that compare Moodle against other products, and I believe that the statements might be incorrect, I just like to add my 2 cents (or euros).)
In all respect I think Martin is to blame for that as he has always maintained that the default theme should be a basic theme in the colour white with just a Moodle logo and nothing else, as he expects Theame Designers to make some fantastic themes.
Hovever, HQ devs are not Theme designers, they are experienced coders, who know Moodle and so they are more likely to complicate things for Theme designers by creating a theme that is, in itself, a mammoth programme and not an HTML document with style sheets.
In my simple mind a theme should be the icing on the cake, and NOT the cake itself, meaning Moodle should have all the various options that themes have developed over the years and make them part of the overall structure of Moodle itself.
Also, and I have said this many times before, it is time Moodle created its own CSS system and not have to be waiting for other branded products to be updated.
And if you think this is a silly suggestion, then you can say what you like, as I am now in my dotage having just turned Seventy last week! I also share my birthday with Andy Fairweather Lowe a musician of the 1960’s of Wideeyed & Legless fame.
Firstly, thank you all for this great discussion - it is obvious we have many passionate community members and themes is a hot topic!
It's been really great to read everyone's thoughts on this and we've certainly taken all the feedback into account in our internal discussions.
I appreciate the challenges with moving bootstrapbase (and child themes) out of core for the 3.6 release. In light of that we've decided to:
- Retain bootstrapbase (and child themes) in core for Moodle 3.6
- Remove bootstrapbase (and child themes) from core for Moodle 3.7
- We will make an early version of the bootstrap 4 based classic theme available in the plugin database to allow themers to commence work on rebasing their themes early
This means themers and sites using custom themes based on a bootstrapbase (or child) theme have an extra 6 months to rework their themes.
We do not plan to maintain bootstrapbase (and child themes) in the plugin database once they are removed from core as we do not have the resources to maintain this range of themes. If there is a desire for this it will have to be the community that steps in to maintain this.
I hope this strategy resolves some of the concerns raised in this discussion.
The Boost will change, we are focussing on improving its accessibility, UX and reducing the amount of Moodle css and using Bootstrap utilities and components.
I am not sure how to answer the question if the architecture will change since themes can be split up in many different types of functionality and are part of Moodle as a whole.
If Moodle, by definition, is a “Modular Object-Oriented Dynamic Learning Environment”; what kind of Object Oriented elements are missing from your point of view, as that may be considerably different from other person’s point of view, as OO can vary depending on the problem or problems that one is trying to simplify.
Boost contains both the Moodle theme attribute and the Bootstrap Framework attribute combined into one conceptual object that in effect is doing two things. The Moodle theme attribute and Framework attribute in my opinion should be separate as they are different things. Think of Boost currently as a car towing a caravan that you can't unhitch. Where the car is the Bootstrap framework and the caravan the Moodle theme attribute.
If you wish to change the look of the caravan then currently you have to add another caravan / trailer to the end. It would be better to be able to just change the caravan. Then with this concept you could keep the same caravan and change the car.... thus another framework.
Boost is a heavy lumbering object that needs to be divided. Just like in the past there was the 'base' abstract theme that was then built upon with a child theme.
I'm not proposing something new but rather to go back to the past where the architecture was correct.
Again it is a separation of concern - https://en.wikipedia.org/wiki/Separation_of_concerns. The framework is one concern and the Moodle visual element the other. If you create an architecture whereby the framework is separate then you are providing future flexibility and designing in robust mechanisms to facilitate the replacement of that framework if required for any reason. I can't predict the future (or win the lottery) but I can plan for it by putting in place mechanisms that can cope with potential change. Call it designing in failsafe / backup mechanisms for when something unpredictably changes that is outside of your control. The framework is outside of your control, therefore isolate it in its own entity and don't couple / stitch it in all over the place so that it is hard to unpick when the time comes.
In reality I do agree with an earlier statement of yours Mary where I believe that you stated that Moodle should have its own CSS framework like Wordpress. Always rely on what you can control.
Ok, purely from a 'software engineering architectural design' point of view, please 'peer review' (in the scientific context) the attached. Thus reasoned arguments based upon software engineering experience and knowledge only please.
Although I partially agree with the structure of your interpretation of what you think Moodle 3.6 will look like, I think you will find that CLASSIC is a child of BOOST, and so you will need to adjust your diagram accordingly.
Or are you suggesting that you feel CLASSIC should be a new theme in it's own right?
Which makes a lot of sense.
Hope this helps?
Well we used to have that kind of layout with bootstrap base and all usable themes like clean, essential etc were child themes of that.
Now Boost is itself a theme (not only abstract as Gareth puts it) but a grandparent.
Whilst I am glad we have been given more time to work on this I think we grandchildren (if we base off Classic which is a child of Boost) are going to be in for a rough ride trying to maintain themes going forward.It doesnt make any sense to me, aside from the fact it allowed HQ to get Boost into core more easily.
I agree strongly with Jez and also the proposed architecture in Gareth's diagram and his critique of the fraemwork problem.
If HQ is going to make "Classic" a child of Boost, then I say stop right now and throw it away as that is a waste of time.
Testing out at the alpha, what I saw was the Navigation block had the Boost NavDraw stuff hanging off it: so it combines one of the most disappointing functional elements of Moodle 2, the Navigtion block (with its limited settings that we have had to work around with css tricks for years), with the single worst "feature" of Boost, a completely unadjustable NavDrawer with no settings and no ability to work around in css. Um, no thank you. I want my classic straight.
Why not just take Clean / More and update it for BS4? Is there no HQ plan at all to create a basic theme based straight off BS4?
If Boost will be the only core theme just say that. Don't confuse things with "pseudo-Classic" which looks rather like a stop-gap to palliate those who have found Boost not usable. Make a BS4 base or don't bother.
Instead make room for theme designers to make a couple good, simple themes straight off of BS4 for the multitude of sites that have found Clean/More perfectly servicable for years.
Separating the framework for Moodle and the Theme horseshoe (top, side, bottom of a page) would REALLY simplify my theme development as I need to integrate an existing Bootstrap 3 corporate theme with the current Moodle "Boost" base theme which uses Bootstrap 4. Either that or create my own base Moodle theme and then maintain that too.
When I did this for the same client about 5 years ago, it was much simpler using Moodle's "base" theme, layering the client's theme over it and then resolving a few CSS glitches. I didn't end up with all the conflicts I have to resolve today - not to mention maintaining the mess.
With that in mind, I do understand the desire to leverage frameworks like Bootstrap to minimize code and take advantage of extensive global testing of the framework.
How much code would we be looking at for a base Moodle framework?
This has been a really interesting discussion. I will add an administrator's view as I am not a coder.
It is really easy to see what people want from a moodle theme. Just look at the theme forum over the past several years and see which themes got the most posts - this is not due necessarily to problem themes but due to the mass usage of the themes in question.
From my viewpoint, things started getting interesting in the theme world with Rocket - one of the first non-moodly themes! Then came Elegance and Essential. When Julian left, and Gareth took over Essential, it came out on top and was the subject of the forum for a long time. People liked the customizability and the many options that are all available from the GUI without the need for hacking. From Essential, we moved to BCU which then became Adaptable. This also came with the features that we all want - marketing blocks, tickers, all kinds of features built in and easy to setup and it led the forum posts for a long time. Since Boost, Fordson has now risen to the top - again, lots of front page set up options, plus teacher tools that are easy to access and all customizable from the GUI.
If you look at the theme history, you can quickly see that we want to be able to have a host of options and settings - why is this not what HQ is looking into for a builtin theme? While we have been able to overcome the built in theme with the help of some great plugins (thanks Julian, Gareth, Chris, Bas, etc..), it would be far more useful to have a fully functional and customizable theme as part of core where we do not need to worry that we are going to lose the theme we love due to a developer moving away from moodle...
thanks for remembering the history of the theme development. Let me add some aspects:
These themes concentrate on a few features mostly:
- Highly configurable start site
- Customization for course catalogue
- Custom settings for background, colors, borders etc.
- they concentrate a lot on visual effects
- the purpose and processes are not thought to an end. Did we really want to replace CMS systems (web site builder) or intranets?
- there is not as much creativity how we design the main learning area: the course and the learning content. That is the place where the users are most of the time. This will need rethinking course formats and their design.
- how can we support the teacher to create better content in an easy way within Moodle. H5P is an example how to do it, modernized courses formats will also be an option.
I totally agree with you but also disagree...you say that these themes concentrate on visual effects but we need to focus on course area. I think these themes have helped to start in that direction and do not see it as a negative that there is a lot of focus on the front page. The front page is where the student/customer/visitor starts and is extremely important because Moodle is used for many more things that just a student LMS.
However, I agree that course content and course pages need to be addressed - but I also think that that is the combined responsibility of Moodle and the teacher/teacher trainer. You can make the course page as pretty and easy to navigate as can be but if teachers are not taught about how to create relationship with their students in an online course, it does little good. But that is another discussion altogether!!
Elegance was the last theme to address the course page some with the activity tiles. I still try and replicate these on some of my sites but also have moved more towards using labels with "hidden" or as they used be called "orphaned" activities. It would be great if that was easier to do that for teachers in some way.
I think that there is actually two things going on here:
- The operation, capability and visual representation of the underlying functionality that drives Moodle as an eLearning entity that acts as an aid to the learning process. Thus the modules, blocks, course formats etc.
- The theme that adds a unique wrapper to the first but can additionally not only change the style but functionality too. It provides the consistent look and feel to a Moodle installation and thus provides individuality to each Moodle instance. Within Moodle it also can facilitate a personal learning experience whilst at the same time not detaching from the collective group.
There is a bit of a grey area between the two with not a clear boundary, and as Moodle is open source, then the power to define that boundary comes with the decisions (whomever makes them) that affect the code itself.
Therefore it is a matter of making the right decision of where to fix an issue when that issue arises. Thus decisions need to be made by those empowered to make them to fix the problems that need fixing.
So in summary, if the problem is functional at a course level then attempt to resolve it first in the course format (contributed or otherwise) / core MDL tracker issue before resorting theme modifications. For example, Collapsed Topics (CT) implements columns / rows of sections, these are organised by using the Bootstrap V2.3.2 and V4 grid CSS classes, there are methods that the theme can override in CT's renderer to use different CSS classes if desired to fit a different grid system.
Additionally I think there are comments above that pertain more to shortcomings in Moodle itself rather than the themes ability to overcome those issues.
Rightly or wrongly, decisions, architecture and designs need to be made in order to make progress.
In the same light as this thread I have written a post on eLearningWorld (run by HRDNZ, a Moodle Partner) entitled 'To Boost or not to Boost, that is the question' -> https://www.elearningworld.org/to-boost-or-not-to-boost-that-is-the-question/ - please do read and comment.
Yes, interesting discussion. I'm also a Moodle administrator, nor developper, nor theme designer. So the following is only my perception of things.
In fact, what lot of people are looking about, and is provided by the themes you talk about, are ability to easily adapt the look and feel (choose colors, add logo), but also new features (marketing blocks...).
In my opinion, these features should be provided by Moodle, and used (or not) if the administrator want to.
Themes should really focus on placing different elements and determine how they look.
We could even imagine that some of these features could be used on standard courses (if teachers have permissions for that, and/or the administrator allows this).