Hello All,
I am currently starting development projects for the Moodle 3.2 release and one of the projects selected is a new core theme.
As you might know, our current default theme is based on a CSS framework which is no longer supported. We would like to build a new theme based on a supported CSS framework and would like feedback / help / suggestions from the community.
We would also like to see an obvious difference in the visual design of the theme. We would like it to look “uncluttered” and “fresh”.
Finally - we would like to make some big changes to the navigation in Moodle. These changes are listed on https://tracker.moodle.org/browse/MDL-52973 - but include:
changing design of the nav block and simplifying it to a flat list (not a tree)
adding navigation into the navbar
consistent “gear icon” for accessing settings pages
moving the “block region” out of the “content” of the page
If you have advice, suggestions or are willing to help with the design and/or code please reply to this post.
Thanks - Damyon
One of the questions we need to answer is which CSS framework to base the new theme on. Bootstrap 3 and Bootstrap 4 are the most obvious choices but I'm open to other suggestions. We need evaluate the CSS framework against our requirements, which are:
* How do we support accessibility
* Does it support RTL
* How long will the CSS framework be supported
* How many devs already know how to use this framework
Bootstrap has only limited accessibility out of the box - there are plugins from paypal that add a lot of accessibility features on top - but they are only available for Bootstrap 3 (not 4). We can always add accessibility to the framework ourselves and contribute it back upstream if they are willing to accept the changes.
* How do we support accessibility
* Does it support RTL
* How long will the CSS framework be supported
* How many devs already know how to use this framework
Bootstrap has only limited accessibility out of the box - there are plugins from paypal that add a lot of accessibility features on top - but they are only available for Bootstrap 3 (not 4). We can always add accessibility to the framework ourselves and contribute it back upstream if they are willing to accept the changes.
How would support for clean/more (current Bootstrapbase theme) be handled? I assume this new theme would not replace those (at least not at the moment)?
This new theme would not replace clean/more/boostrapbase but would be a newer more modern base theme that can be extended.
Hi Damyon,
Interesting.
My thoughts:
- Should be BS4 if certain to be stable at the point of release. If not then you could go with BS3 as there are a few BS3 themes already by which to get a head start from - quite a few devs (including myself) know this version. Also BS4 is SASS not LESS, so more work for a PHP SASS compiler if that is the direction taken. However BS3 will go out of date sooner.
- The framework should be confined to the 'themes' folder (or '$CFG->themedir'). Any framework code placed outside of that (i.e. notification templates, 'span' classes in JS etc.) should be removed and moved as an overridden entity to the theme files. Then can be truly framework independent.
- Consider auto-flipping for RTL, whereby there is an 'all-ltr' and an 'all-rtl' cached CSS bundle served depending on language direction.
- Examine current trends in web design and the simplicity of the Wordpress user interface from an administration point of view. Then from that standpoint consider what will be the next thing and implement it so that Moodle is a trend setter rather than a trend follower.
- Concentrate on cleaning up the UI beyond the scope of the theme or at least make it overrideable such that 'less becomes more'.
- Solve long term confusions of the same concept, i.e. 'iconsmall' / 'smallicon' where the icons can be 12px or 16px (I think) but not consistently within and between them.
- Clean, crisp, elegant and functional.
Cheers,
Gareth
Well said Gareth. 100%
Hi Mary,
Got your message a few days earlier. To answer you question, yes we could indeed look at moving the ATBar to the bottom of the page for anyone using the navbar-fixed-top style navgiation in their theme. Can you please raise a github issue here and I'll assign it to myself : https://github.com/marxjohnson/moodle-block_accessibility/issues
Thanks,
Hittesh Ahuja
"Consider auto-flipping for RTL, whereby there is an 'all-ltr' and an 'all-rtl' cached CSS bundle served depending on language direction."
Please
+ Being able to put "do not flip comment commands" in the LTR pre-compiled-about-to-be-flipped version.
+ Being able to add some custom RTL fixes on top of the flipped RTL css code before it is published as "all-rtl"
+ Also, maybe consider HTTP2 that could enable us to rethink the current aggregations of LESS/CSS styles files from each module, and only send to the user the ones that are needed on the current viewed page (See MDL-52751). It would save a lot of processing time to mobile browsers and give a better UX to the mobile users.
It strikes me as odd that paypal created a bootstrap 3 plugin to fix accessibility limitations as opposed to contributing the fixes back to bootstrap instead.
Might be worth using the paypal bs 3 plugin as a basis for a bs4 AX fix.
Hi Damyon,
I know I have said this a good few times before today, there is nothing stopping Moodle having it's own CSS framework. One that can be built on and one that can be tailor made to suit Moodle.
Why try to build someone else's framework around Moodle. I suspect that the main problems with Moodle is how people using it, so if anything, it needs to be simple and not complex like it appears to be getting.
At the end of the day the method of delivery that people want is set by trend. So what we have today may not be what we will need in the future.
Anyway I am not technical enough to say more, so I'll leave it at that.
I love change...it keeps the mind active and I need that to survive.
Thanks Damyon you are doing a grand job.
Cheers
Mary
The paypal accessability additions are out of date, since Bootstrap core has massively upgraded their accessability during the Bootstrap 3 cycle after they recruited an accessability expert to work on it. This probably also explains why it does not exist for 4 too.
For more info:
https://github.com/paypal/bootstrap-accessibility-plugin/issues/74
https://github.com/paypal/bootstrap-accessibility-plugin/issues/81
I'm sure Bootstrap would welcome any accessability improvements we can offer, as many other projects also return their suggestions and improvements to be shared by other Bootstrap users, but I think we should be up-to-date on what the actual problems are. The open issues tagged with accesability are here:
https://github.com/twbs/bootstrap/issues?q=is%3Aissue+is%3Aopen+label%3Aaccessibility
And their lead AX dev has some issues assigned to him that seems like accessability but aren't tagged as such:
I looked through the bootstrap 4 examples. They have not followed the aria spec, and the examples test poorly with a screen-reader/keyboard.
Could you be more specific about the issues you found? There are multiple uses of aria in the Bootstrap docs, they even have a bug open about removing some of their uses of aria because real world screen-reader users find them sub-optimal:
https://github.com/twbs/bootstrap/issues/19738
So, if they're using aria, and following the topic enough to be aware of problems with the aria spec, and have a Senior Accessibility Engineer from the famous Paciello Group on board (presumably because many of their clients want to use Bootstrap and need it to be accessible), then I'd say that's not a bad start. I'd expect a more in-depth critique than writing off a public alpha with a single sentence. Things like, do they already have an open bug about the issue? If so, how are they (planning on) dealing with it? And so on.
Regarding RTL, here is the Bootstrap 4 plan for that:
https://github.com/twbs/bootstrap/issues/19555#issuecomment-197549158
I would highly recommend this "tool-assisted" approach. One such tool they mention that I like is this one:
https://github.com/MohammadYounes/rtlcss
And here is a post-css plugin that uses it to create Moodle-style combined RTL & LTR CSS. (Note, I don't think that's a good idea or best practice, better to send RTL or LTR depending on the current page direction, but since we already do it, I thought it would be interesting to note that it can be partly-generated).
I've implemented an earlier version of this in a Bootstrap 3 theme and the big blocker was core Moodle's requiremnet to send both LTR and RTL to every page, but this newer tool could work around that if it really needed to. But ideally only the CSS required for the current page would be sent, and this could have a dramatic impact on Moodle's total CSS download size, so that's an important co-benefit.
https://github.com/twbs/bootstrap/issues/19555#issuecomment-197549158
I would highly recommend this "tool-assisted" approach. One such tool they mention that I like is this one:
https://github.com/MohammadYounes/rtlcss
And here is a post-css plugin that uses it to create Moodle-style combined RTL & LTR CSS. (Note, I don't think that's a good idea or best practice, better to send RTL or LTR depending on the current page direction, but since we already do it, I thought it would be interesting to note that it can be partly-generated).
I've implemented an earlier version of this in a Bootstrap 3 theme and the big blocker was core Moodle's requiremnet to send both LTR and RTL to every page, but this newer tool could work around that if it really needed to. But ideally only the CSS required for the current page would be sent, and this could have a dramatic impact on Moodle's total CSS download size, so that's an important co-benefit.
This approach is not the correct way to apply RTL. RTL does not require EVERY rule be swapped - it depends on the context.
E.g. IP address input fields are shown in LTR - even on an RTL page.
It might be still better than the current approach if it can allow for exceptions.
Also - RTL needs to be built into the javascript as well - e.g. keyboard shortcuts for left and right.
E.g. IP address input fields are shown in LTR - even on an RTL page.
It might be still better than the current approach if it can allow for exceptions.
Also - RTL needs to be built into the javascript as well - e.g. keyboard shortcuts for left and right.
The README on the github gives multiple examples of how to encode exceptions like this in the Supported Directives section:
https://github.com/MohammadYounes/rtlcss#supported-directives
This allows those with RTL language skills to maximise the impact of their contributions, as the boring donkey work has already been done by the computer, they just have to spot and fix the exceptions.
Also, I forgot to include the link to the other tool I mentioned (which spits out a single combined file rather than the ideal two separate files):
Hi Damyon,
To prevent flipping there is the '@noflip' directive: https://github.com/gjb2048/moodle-theme_essential/blob/MOODLE_30/less/bootstrap-override/carousel.less#L39.
G
Hi Damyon,
RE: Themers and devs need to learn both the separation layer and bootstrap.
This is true of today only with more coupling. Devs still need to learn Bootstrap as well as all the ways that Moodle works.
G
Thanks - I think this would be enough to make this workable.
If doing automatic flipping, than we should definitely try to flip as much as we can, but also be able to control what should not be flipped.
Here is a list of most exceptions in which LTR should not be flipped: MDL-51948
If Javascript uses inline CSS it might be migrated to mustache templates, and maybe we could decouple CSS from Javascript? as they can be used for both PHP and Javascript. (as far as I understand)
And cases where Javascript need to handle keyboard events differently for LTR and LTR keyboard layouts (like MDL-53349), they need to be solved regardless of theme considerations. (as far as I can tell)
Hi Damyon,
I would suggest making a clear distinction between working on the CSS framework and a Core theme. The CSS framework should only focus on the UI parts for grids, UI components, layouts etc. The Theme should provide the visual identity.
An obvious choice for the framework would be to continue using Bootstrap and upgrade to Bootstrap version 3 or even 4 on which Andrew Davidson made some progress. The effort to upgrade Bootstrap would be relatively small compared to introducing a new framework. The theme developer community has been maintaining the bootstrap theme for some years now. That theme has been kept as clean and simple as possible so it can be adopted in Moodle core and can be use as a parent theme for community themes.
A focus on really making use of Bootstrap components in creating Moodle UI's could help unclutter Moodle and clean up the interface. I think the Mahara project did a great job at this for the 15.10 release and it is a delight doing frontent work for Mahara now.
The work on the Theme building on the CSS framework would be the fun project. Creating a visual identity for a widely used tool is challenging and could take a lot of time. Especially since it is used globally and opinions on good design vary a lot around the globe. I would say looking into the work done by Google for Material Design (with a focus on the Material and Motion, not the full framework) is worth exploring (https://getmdl.io).
Hi Bas,
I agree with you in that Moodle needs to seperate the CSS Framework of the Main Content, as in Moodle Core, from the design elements from which we can base all our themes from.
I like the Google Material idea...although I suspect it could become dated in the future.
However, there is nothing stopping us starting a Moodle Theme Development Group to develop our own 'Brand' (forgive the pun) that we can build on and modify to suit the common 'trend' dictated by technology and in some respects 'society' in general.
What do you think?
Mary
A separation between the CSS framework and the html generated in moodle sounds like a good idea initially - and makes it easier to switch between frameworks in the future. But there are some downsides.
* Unless the separation layer supports all the features of the framework you end up restricting devs to only use some of the features of the framework
* The HTML generated becomes targeted to the separation layer - so it doesn't look like HTML that a bootstrap themer would expect.
* Themers and devs need to learn both the separation layer and bootstrap.
We discussed this a while ago in a policy issue and the decision then was to allow bootstrap classes directly in html generated by Moodle as long as the HTML is still semantic.
Mahara seems to have benefited by choosing a framework and trying to use it to the fullest - instead of "hedging bets".
We will be in the situation where we need to support bootstrap 2 and the new thing at the same time - so we will need to have some sort of solution.
* Unless the separation layer supports all the features of the framework you end up restricting devs to only use some of the features of the framework
* The HTML generated becomes targeted to the separation layer - so it doesn't look like HTML that a bootstrap themer would expect.
* Themers and devs need to learn both the separation layer and bootstrap.
We discussed this a while ago in a policy issue and the decision then was to allow bootstrap classes directly in html generated by Moodle as long as the HTML is still semantic.
Mahara seems to have benefited by choosing a framework and trying to use it to the fullest - instead of "hedging bets".
We will be in the situation where we need to support bootstrap 2 and the new thing at the same time - so we will need to have some sort of solution.
Is the idea to create a new theme within the current limits of the theming system, or to use the experience of building a new theme to help fix/expand the themeing system to better support theme work?
The existing Bootstrap 2 & 3 themes push the boundaries of the current system and are much harder to work on than they should be as a result. Something as simple as every standard form button in Moodle consistently having a ".btn" class (and removing it from anything that isn't a standard button!) so that you could change a few Bootstrap variables and see the change reflected in all buttons across Moodle would be nice.
Several people have commented about Mahara's adoption of Bootstrap making it very pleasant to do theme work, since it adopted Bootstrap wholeheartedly. Moodle has always avoided making any long term commitment to Bootstrap and this has slowed progress in themes by forcing a series of elaborate workaounds to fake standard Bootstrap behaviour via theme code, while core code continues to do it's own thing(s) when it comes to choosing classnames or standard web patterns.
I would suggest the first step, assuming you actually choose Bootstrap for this new theme, would be to add some bootstrap classes to core code that is not yet in a renderer or template. This would avoid you having to repeat the complicated and annoying work to shim Bootstrap so that it is compatible with the existing HTML, and avoid any designers brought in to work on this complaining "that's not Bootstrap" when they get to see the Moodle HTML they have to work with.
Hi David,
RE: I would suggest the first step, assuming you actually choose Bootstrap for this new theme, would be to add some bootstrap classes to core code that is not yet in a renderer or template. This would avoid you having to repeat the complicated and annoying work to shim Bootstrap so that it is compatible with the existing HTML, and avoid any designers brought in to work on this complaining "that's not Bootstrap" when they get to see the Moodle HTML they have to work with.
I disagree. I believe that the core code should be framework independent. Bootstrap is not the only framework and who knows what is around the corner. We should not go down the 'global variables' route but instead move to more 'encapsulation', thus there should be renders in core that produce the template basics that the functionality is responsible for. If there needs to be framework specific 'hooks' then so be it, just like creating classes with abstract methods, you provide most of the functionality but leave a few methods to be implemented by the child class. Thus here the theme code in the themes' folder.
If there is too much coupling between Bootstrap and core code then will be harder to untangle the mess when you want to use something other than Bootstrap. Thus there needs to be clear separation between framework code and Moodle code - CSS / JS etc.
Cheers,
Gareth
"I disagree. I believe that the core code should be framework independent."
Sorry, but I disagree with this!
Moodle has committed to frameworks in the past and present, I really don't see the issue with committing to Bootstrap as the base framework for markup / CSS. So long as renderers / templates are used throughout Moodle it would be easy to plug in another framework.
The thing that's good about committing to Bootstrap is that it should force developers to start thinking about markup and class names in a more consistent way. It should encourage them to use design patterns that are more standardised across the web. This is only a good thing regardless of the framework you decide to use for your theme.
Sure, you are going to have to rewrite lots of templates to make your Zurb Foundation based theme to work but at least what you are rewriting will be better laid out and more consistent.
Also, if you take the opinion that the core code should be framework independent both bootstrap AND other theme developers will end up having to override templates. It's no more or less work for the non bootstrap framework favouring theme developer either way IMO.
Hi Guy,
To disagree with your disagreement, just because in the past that something worked one way does not mean that it is good for now and the future. At the moment theme designers have to think about all aspects of the theme design anyway. And having a framework scattered all over the place instead of confined to the themes concept harks back to saying that global variables are a good thing. This is why we have OO, why there is the concept of encapsulation and single responsibility for a given element of functionality. That is why it does need to be separate and contained.
And how does using Bootstrap encourage use of design patterns? Its just a framework that can be abused badly like anything else. How you create designs and code is down to professionalism and discipline.
Cheers,
G
As an after thought...we could always go back to using HTML files...
such as header.html and footer.html
I think there are some high hopes on capturing a new "look" for moodle. A simplified and more intuitive layout/organization of what is displayed to the learner is a tall order. Good luck with this endeavor! Can't wait to see what you come up with!
Hi Damyon,
Here are a few suggestions:
- First of all, I vote for the moving of the navigation into the navbar and the consistent gear icon
- In my opinion, moving the administration block into the navbar could make sense (something like decaf / flexibase themes), since this block takes a lot of space on every page. (see attach)
- A consistent "turn edit on" button would be great as well (see attach), and even a persistent edit mode for priviledged roles.
- A show/hide blocks toggle would be interesting too (see attach)
Regards
Jean-Roch Meurisse
Please join Martin and the HQ dev team for an online meeting to discuss the new theme in development for Moodle 3.2. The meeting is scheduled for Friday, 8 July Friday, at 07:00:00 GMT. We would like this to be a collaborative development project with community involvement.
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Moodle+Dev+Community+Meeting+-+New+Theme+for+3.2&iso=20160708T07&p1=%3A
The meeting will take place on "zoom". See below for meeting details.
(Apologies for the cross posting)
Regards, Damyon
===
Moodle Meeting is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/397419685
Or iPhone one-tap (US Toll): +16465588656,397419685# or +14086380968,397419685#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 397 419 685
International numbers available: https://zoom.us/zoomconference?m=csajZB3ucB0hAy3IwvI5UaJvPMCVrlh6
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Moodle+Dev+Community+Meeting+-+New+Theme+for+3.2&iso=20160708T07&p1=%3A
The meeting will take place on "zoom". See below for meeting details.
(Apologies for the cross posting)
Regards, Damyon
===
Moodle Meeting is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/397419685
Or iPhone one-tap (US Toll): +16465588656,397419685# or +14086380968,397419685#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 397 419 685
International numbers available: https://zoom.us/zoomconference?m=csajZB3ucB0hAy3IwvI5UaJvPMCVrlh6
Was this meeting recorded?
Recording on YouTube:
Progress update!
We have started work on this new theme and setup a prototype so people can see what we have been doing. The prototype is at:
http://prototype.moodle.net/theme/
All the details needed to access the site are on the frontpage.
We have started by:
- Converting the less from bootstrapbase to sass and combining it with the sass from bootstrap4
- Adding renderers and templates, removing custom CSS rules and updating the markup to directly use bootstrap4 classes
- Integrating a sass compiler in moodle so we can re-compile the theme when settings are changed
- Support for an auto-css flipper for RTL
We are a long way from finished - but we will regularly update the prototype so you can see progress.
Looking very very good!
I opened an issue on the tracker for little tiny RTL issues: MDL-55388
Hi Damyon,
As this is a PROTOTYPE I am reluctant to start creating tracker issues for styling bugs, as no doubt they could well be caused by the changes being made and will hopefully be fixed on the way.
However this bug looks different than a simple style problem...here's an image which shows the problem.
See what I mean...?
Cheers
Mary
Yes - please don't create tracker issues for styling issues - it's way to early for that. If anyone does want to fix anything they are welcome to send pull requests here: https://github.com/damyon/moodle/tree/theme
Just found this in the new theme_notheme output in style.php:
.m-b-1 {
margin-bottom: 1rem !important;
}
It's probably top level Bootstrap 4 and has !important added so that it cannot be overridden, which in itself is bad as this encourages the !important tag in a theme in order to override it.
Thanks,
Mary
Hello,
just adding my two cents, there is this good article from MDN: https://hacks.mozilla.org/2016/05/css-coding-techniques/
Quoting:
"When you add !important to a property, the browser will ignore other rules with higher specificity. You know you are really in trouble when you !important a rule to override another rule that was marked as !important as well.
There is one legitimate use of !important —and it’s while
using the developer tools to debug something. Sometimes you need to
find which values for a property will fix your bug. Using !important in the developer tools and modifying a CSS rule on the fly lets you find these values while you ignore the cascade."
So, !important may be considered harmful ? Hehehe
Kind regards,
Daniel
In this case it is coming from bootstrap - and I don't think in this case it is bad practice at all - they provided very good ways for you to customise that by changing the sass variables. This allows you to adjust (in this example) the amount of whitespace everywhere by changing a single variable and recompiling the sass. Once you start tweaking pixels you lose the benefits of using the framework.
I'm in the process of upgrading to PHP 5.6.19 and 7.0.4 on Windows 10 using Wamp Server. That has been an interesting journey in itself.
I don't have a clue about SASS but I hope I will master it soon.
Thanks
Mary
This is exciting news. I have a request for some of the main features of the Adaptable theme. https://moodle.org/plugins/theme_adaptable. There are some great features like:
- News announcements ticker
- Favicon uploader
I think one of the most important features that Azusa Pacific would like to see is to be able to create category based versions of this theme with custom CSS for each version we create. We are currently hosted by Moodlerooms which cannot provide us with additional versions of the More Theme. We need to be able to do this on a category basis.
Hi
Is already it to late for suggesting some things to be considered?
I'm recently thinking about about the goodness of lazy-loading some contents such as images, videos, or even block contents.
Loading block contents after the main content is loaded (AJAX)
Yes this is what I always wanted to have.
I have seen it many times that a ridiculously high resolution image in an html block makes course loading very slow. It seems that the main course content is displayed after blocks (or maybe just blocks that are on the left side) are fully loaded.
Anyway, loading block contents after the page is loaded seems like a big move towards modern design in my eye. I think that the comments block is already like this. just don't know why other blocks are not.
I googled about lazy loading and it seems pretty interesting as well. "loading images only if they are within the visible area". Why would someone not love that?
So are we going with BS4?
Yes - we are going with bootstrap 4.
Hi Damyon,
I am struggling to test then new theme as a branch in my test server.
Trying to checkout branch Theme is crazy, is there a different way of using this file? What I am trying to say is that although I can clone the master branch to my theme directory I did not seem able to select/ checkout the "theme" branch. I can get to theme-js but not theme.
Hope you can help?
Thanks
Mary
Hi Mary - we cleaned up the git history and the main branch for dev work on the new theme is now:
git pull http://github.com/damyon/moodle MDL-55071-master
There should be a major push to that branch today which converts all of mforms to templates with custom templates for bootstrap 4 - when this is done I'll update the prototype site.
COOL,
excellent...thanks!
Mary
I am just cross linking this thread to the other discussion in the themes forum where I have been posting updates.
My wish: Place the theme in a separate git repository instead of including it in the moodle/moodle repository. This makes it easier for developers to work with it. This also allows making site-specific versions of the theme by forking it.
Hi Juho
I think that is a good idea, but in case it doesn't happen you can clone your own version using a sparse checkout http://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository/13738951#13738951