Apart from the very significant stuff going on under the hood with respect to the frameworks, you'll notice a number of basic new concepts in the UI:
- Reduced reliance on blocks. Navigation and Settings blocks can be deleted completely (and would be in vanilla install). There is still a block region over on the right if you really need it for critical content (but we advise trying to avoid them, because remember, these don't show on the Mobile app).
- New "Flat nav" menu on the left with key navigation points (designed to converge with the main menu of Moodle Mobile over time).
- "Gear icons" on Site, Course, Activity and User pages with a drop down menu that presents the key things from the old Settings block.
If, as a themer, you don't like these, you can easily override them in any child theme and still benefit totally from Bootstrap 4, but I am pushing for these UI features as defaults in Boost to give Moodle a refreshed and modern default appearance that feels more like the many web and mobile interfaces around us, and to raise the baseline for themers.
Any help we can get from you in polishing this concept to make it good enough to be default in our 3.2 release (slated for late November) would be very welcome.
Something I just thought of...
If the settings blocks are being removed, plugins that use the "[plugin]_extend_settings_navigation" hook function (https://docs.moodle.org/dev/Local_plugins#Adding_an_element_to_the_settings_menu) will need a new method to insert items into settings areas. Has that been considered?
Just a quick question, If blocks are to be phased out (idealy) what will be replacing them, as there are some very useful ones, for instance the Progress Bar or Twitter Feed. Will these become some other 'new' module, or still blocks but displayed differently?
There is still a block region for other things that you might find necessary, however there are no plans to bring blocks to the mobile app EXCEPT on a dashboard page there.
While progress bar may be work that is coming for the dashboard, that is a specific use case - and a one size fits all solution - many places may need progress bar to be there or not on a per course basis. There are lots of use cases, heck - core ships with over 40 blocks(!), that really aren't covered yet.
And while the current stance is "blocks are still there, they aren't going away", the clean subtext from HQ is "yet".
My personal opinion is that to truly replace blocks, we should allow modules to have the ability to direct their display on the course page.
That would mean more formalizing how mod_label hijacks its display, and allowing more flexibility in the caching behavior of that display. That way something like progress bar can be placed in-line in the course as a mod.
Moving to that type of structure would allow a lot more flexibility in course design, and unify the development side.
I agree, thats why I asked whether blocks would become (in the future, not in 3.2) some other module, where they could be positioned in course pages. I'm concerned and our institution is not even a big user of blocks, but there are some which I believe offer great functionality and need to be accessed via course page.
I totally get where you're coming from, and can see how developers would love to be able to insert anything they like into any part of the page.
- that is at odds with pretty much every major interface around. Quite a lot of the work I've seen designers focussing on even just in Moodle are about how to just present one simple chunk at a time.
- even if page chock-full of data and widgets is something people want, it would require a huge design process to make that kind of shift and prevent the overall UX becoming a mess for users
I agree that you want designs to be simple information, but you are actually losing a lot of that by moving to a block-less design.
The use case that I think is not well covered with this new direction is at-a-glance information at a course level. Maybe an unread message count in our course specific email system, progress within the course, course events calendar, etc.
Yes, some of those things will be done on the dashboard, but some don't make sense at that level, and also it doesn't always make sense to be pulling people back to the main dashboard when they are working in a course (i.e. I have 6 course, and I'm currently doing work in course B, why do I need to go back to the main dashboard, and find course B there to get pertinent info), or shouldn't always be mashed up between courses.
The other problem with the centralized dashboard is that not all institutions work in a holistic way. Teachers want (and expect) to be able to largely control their students course experience, and that can vary wildly from instructor to instructor.
The mod idea was simply what I view as the least painful way to get that functionality back.
One idea I've had is you could have a sort of course level dashboard that the teacher could configure with 'tiles' (think block, but a defined size and much more constrained focus). Basically there would be something like 3 side-by-side slots at the very top of those course where they could be located. With the right sort of design guidelines, that something like that could work and be cohesive.
And yes, that would be *a lot* of work, I don't deny that. But I don't think blocks will go anywhere until some of those use cases are addressed.
Well, first a question - where does that image come from? I know we still see a large majority of our traffic come from desktop, and I bet in the educational setting that isn't abnormal.
But even so, I agree that mobile dev is a worthwhile goal, but all the current solution has done is (mostly) caused content to be buried behind more clicks, which makes a slower experience and more data transfer.
I just think their should be a way to display pertinent (and dynamic) information in the course view, even if we (plugin devs) were very constrained in what that content can be. There is no inherent reason why that idea is incompatible with mobile access.
I totally understand where Martin is coming from. We need to future proof moodle and make it accessible to audiences and their expectations.
Research does indicate mobile devices are more popular for general browsing, I don't think this is quite the case for TEL due to varying degrees of adoption of BYOD etc in educational institutions particularly in the UK, but mobile usage is growing. I for one have seen over double the amount of mobile sessions in September 2016 compared to 2015 in our environment - but still only makes up 20% of our sessions.
Perhaps block placement in course area content regions is something that could be put forward in the Moodle Users Association for work after 3.2 or indeed be carried out by partners, or community developers. I will definitely be keeping a close eye and looking into the feasibility of this.
Block placement in course areas (though not between course sections) is already possible in current themes - custom block regions can be added surrounding the main-content region (although not within the $OUTPUT->main-content itself) such as in Flexibase. This is not intended to give teachers carte-blanche to fill a page with data and widgets, but to give teachers the flexibility to position the ones they do want/need where they want them to go and to ensure that content/functionality that the teachers deem to be important is available whatever the device used. At least the existing block region isn't totally disappearing on small screens anymore.
Now, how to go about adding such custom block regions with the new templating structure is something I still can't get my head around (yet).
Well while boost has some nice aspects, but I have some points against it and this trend of completely removing blocks.
It is true that most of Internet traffic is via mobile but the statement of "70% of internet traffic" looks more journalistic to me rather than a scientific statistic. What is that 70% used for? A random observation of people sitting around me on buss or train shows me that they're just watching YouTube, checking Facebook, or video chatting with their families abroad. Of course the traffic that is used for watching a 30 minutes video can be multiple times more than the traffic that is required to study a typical Moodle course from the beginning to the end. The message that is there for us is that we should take mobile support serious and put some effort on mobile support. That's it. We should not let these statistics to mesmerise us and inculcate the idea of being left behind while everything else has moved to mobile apps.
It is really good and actually a must to consider Moodle app users while designing courses. We should remember that they don't see blocks and they view course modules on a 7 inch display. Being limited to a 7 inch display means that only essential elements could be displayed in a single view and some taps are required to see additional stuff. But why should we deprive those who access Moodle on a 20 inch display from blocks? Blocks can be used to display additional info to students without the need to leaving the page they are in. An excellent example is the calendar block. It is fine if mobile users don't see it but it presents helpful visual information to desktop users. Another example is the upcoming events block. Another example is the recent activities block. As an ex Moodle student, I can say that the recent activities block is a must to have for each course. It is impossible for a student to check all sections of their course to see if their teacher has changed something or has added something to the course or not. I completely take my words back if someone tells me that it would still be possible to present all these information on the course page, without the need to do several clicks, without blocks. but at the moment I just don't understand why we should deprive desktop users from seeing these additional, useful information (yet none essential for app users) which could be right in front of their eyes on each course's main page and only present them with a list of activities and a lot of wasted areas which could be filled with blocks.
I attached how the administration block looked like in Moodle 1.9 when an admin was in a course. It only displayed options that were related to the course. If you wanted to change a site config, you had to go back to site home page to be able to see site-level administration options. I remember when the new administration block was introduced in 2.0 I was super happy that I didn't have to do so many redundant clicks and wait for many redundant page loads anymore. I could easily access all administration settings wherever I was. Now the administration block is removed from the vanilla install and this trend of removing blocks suggests me that it is only the matter of time before Moodle HQ stops maintaining it. The new gear icon only provides what the old administration block were offering. This is like going one step forward an many steps backward!
I understand that some of the concerns can be addressed with a custom course format or a custom theme but means the institutions who could do their stuff with standard install would have to go through the path of plugin developing or if they're lucky, ending up with using 3rd party plugins.
"But why should we deprive those who access Moodle on a 20 inch display from blocks?"
Boost is certainly not doing this. It has a fixed block region that is always there.
What I was saying was that it should be for EXTRA or helpful info or shortcuts, and not things that are critical for students to finish the course (because of the possibility they will be on the mobile app).
If you like the deep-menu administration block you can keep it on for your site, no problems. But it's just not a good direction to be the MAIN direction in the future, given the trends in interfaces everywhere all around us.
I'm looking forward to the user testing we'll be doing on Boost with 3.2 to see what comes out of it.
My students do use their smartphones, not exclusively, but they do use them, more and more. (The graph is fundamentally correct.)
I think that we are missing a very important point about the mobile learning environment. Yes, when students can dedicate a chuck of time to study they are probably better off working behind their computer. But the mobile environment gives us an opportunity to grab a student's mind when they are on the go! This is exactly what I want: I want students to be in my course whenever they have a spare moment. This is how I pump more knowledge into their brains. Also, students seem to be more "on the go" than they are stationary these days.
What I find interesting is that the other LMSs are still struggling with responsive design. Sure, apps can fill the gap, but why not give students the entire course as they (pretty much) see it behind their computers? When my student do comment on their mobile access to my moodle courses, they are doing it behind their smartphone's browser, not from the moodle app. Moodle is already at least 3 years ahead of the other competitors. I am glad to see that Moodle is already giving its responsive design the next boost!
To me the question here that needs to be answered by Moodle and institutions a like is what Eric brought up with the progress bar use case. That is:
What is useful information on the course page for user's in your institution?
When I look at what we did with Snap as a theme I see a lot of the core blocks as being not useful on the course page, but more informative in a indicator manner in a menu or alert area. Things like, latest news, recent updates, recent forum posts. All of these are useful if i want to look at them as a user, but distracting otherwise.
Blocks also have a history in Moodle as being the default plugin developers used to create some new functionality, usually without any thought to usability of the functionality. Some of them are administrative others are informative. I think that what needs to happen is that the blocks need to be reviewed and someone should determine how the usability of the functionality should appear to the user.
I like Eric's ideas on the modules although for different reasons. I want all activities to display data on the course page and be interactive there rather than through a click into the activity. I want a student to never have to leave the course page to engage with learning objects. I want them to leave the course page if they or the teacher wants to dig deeper into information about the activity, such as reports or statistics. My ideal is that a student should be able to scroll the course page, know what they have completed, what grade they received, due dates for activities and if feedback exists. They should click in to read more about feedback or comments on a grade, but otherwise they should be able to gloss over the information and move to the next activity they need to complete to further their education.
That graph reminds me of a mathematical model I derived twenty years ago, as a assignment in a maths class when I was studying for my degree. I used differential equations to map the 1914-19 flu epidemic using an ancient computer program called DERIVE. The graph itself ended up looking like a wine glass. Half full or half empty...take your pick.
New ideas like viruses can grow at an experiential rate and then peter out and leave devastation in its wake. Some people love that feeling of cold fear when they are on the cutting edge of discovery, others hide from it seeking comfort in familiar things. At the end of the day ideas like viruses can kill. So Martin, do be careful what you do with Moodle.
So in my best Yorkshire accent...
"...If tha brexit tha mon fix it!..."
The concern I have here and the reason that Moodle often times is so hard for students to use is that variability in course design.
I like the idea of removing blocks and moving dynamic and transactional data that is out side the learning materials into a more consistent place (I like the course dashboard idea).
I don't like the idea of teachers controlling navigation in the system or where progress and completion data show. The teacher or instructional designer should be in charge of the flow of information to a student and timing. How and when they should be assessed on their understanding.
In our discussions with students at Moodlerooms we have found that inconsistent course design, progress information placement and most especially navigation have a negative impact on the student's satisfaction with a course. If it is not easy for a student to find their course and what they need to do next then they get frustrated. Multiple navigational elements on a course page also confuses students when they are trying to access course materials and assessments.
IMO we need to be thoughtful about how we display data and what flexibility teachers have to impact a student's ability to understand how to access data in the system and understand the learning environment. User experience design and usability should be the concepts we support over teacher flexibility.
you could have a sort of course level dashboard that the teacher could configure with 'tiles' (think block, but a defined size and much more constrained focus). Basically there would be something like 3 side-by-side slots at the very top of those course where they could be located.
Just for the record, not fully what Eric describes, but not far from it: https://moodle.org/plugins/mod_poster
I was thinking about the comment above on MUA-26 which mentions integrating progress bar functionality on the dashboard. I appreciate the value of progress bar, but also believe blocks like Level Up and Ranking provide similar functionality. Sites should have a choice in what or how information is reported.
That is a simple rule to state. However, it is not clear to me that it leads to the best user experience.
For example, when you are on the Edit quiz page, it is natural to want to start a preview of the quiz. That link is in the Quiz administration menu.
Or, when you are looking at one quiz report, it is natural to want to switch to one of the other reports. Those links are also in the menu.
Really, in the past, having exactly the same settings menu (previously in the settings block) on almost every page of the quiz was really convenient. I think, without that, we aer losing something.
I completely agree about forms. Form pages can easily be completely plain, but then interacting with a form is a thing. You go to the form, change some things, then Save or Cancel. There is a single clear next action (click one of the buttons at the bottom). Therefore, you don't need general navigation there. However, on other pages, there is not a single clear 'next' place to go, and I think pages without a single clear Next are good candidates for having all the settings available.
I imagine similar logic could apply to the manage enrolments or manage permissions pages for the course. I expect those could benefit from having the settings present.
I know these usability questions are not hard to resolve, but I would encourage you to coninue to consider this one further. (Has this been subject to any testing by real users, rather than by developers who are really familiar with the old interface? )
Putting the settings link in a deliberate top-level place is very common on mobile apps (which is where the action is these days).
Yes, we've had quite of bit of user testing these past few months, but there's a limit to what that can achieve.
To get the most useful feedback, I'm convinced you need
- a really functional interface,
- people who really want to use it to do real things, and
- some time for them to get used to it so they really understand the pinch points.
However, this means you also need to build something. So please consider Boost in 3.2 that first functional version, a usable preview, that our community and UX team will do detailed user testing with so we can keep improving Moodle along these lines.
We've deliberately kept away from changing Clean and core pages in 3.2 (so there is no effect on existing themes), but detailed testing may (and I would guess WILL) require deeper changes that will start affecting all themes.
That's when the REAL commitment to a new UI begins (in 3.3 and beyond) - the point where we need a consensus that it makes sense to start deprecating older ways of doing things.
"So please consider Boost in 3.2 that first functional version, a usable preview, that our community and UX team will do detailed user testing with so we can keep improving Moodle along these lines."
That makes a lot of sense. I believe it was originally intended that Boost would be the default theme with new installs of 3.2. Should that be reconsidered as well then? Perhaps make it a "development" option, or at least not the default theme?
(I can see advantages either way)
I created a very short php file that generates an mform.
I saved it as mform_code.php in moodle root and I called it using both:
What is really not acceptable, IMO, is that the two rendered html sources ARE DIFFERENT even if they comes from the same file.
The one rendered by "clean" uses the tag frameset. The one using the "boost" theme don't.
Let's suppose I am writing a module using mform_code.php and, in the frame of this module, I also use style.css to assign some mandatory cosmetic roles. My style.css MUST PROVIDE ROLES THAT ARE INDEPENDENT FROM THE USER THEME.
But, in spite of this, my style.css may work differently in those two themes because... boost theme changes the html source code!!!!!
This actually negates that styles describe the aspect of
the web pages ONLY while the html take care of the structure of web
pages ONLY. I find this details really dangerous, as misleading, and incorrect.
"You do have to be careful with what you put in style.css yes (hopefully nothing!)."
So, is the goal that Boost replaces all of the module "style.css" files as well? If that is the case, will the core modules be dropping their "styles.css" files as well? Currently, they still have these files.
Or is it that we need the "styles.css" files for all of the non-Boost themes?
We have removed many many unnecessary styles from plugins in 3.2 - but not all as we have did not have time to re-write all of the output for all of the plugins in 1 release.
I see in mform the structure of a table raw is something like:
<div class="form-group row fitem ">
<span class="pull-xs-right text-nowrap">
<label class="col-form-label d-inline " for="id_textname">
<div class="col-md-9 form-inline felement" data-fieldtype="text">
<input type="text" class="form-control " name="textname" id="id_textname" value="" size="" type="text">
<div class="form-control-feedback" id="id_error_textname" style="display: none;">
Are the classes "form-group", "col-md-3" and "col-md-9" ALWAYS used (in each mform div)?
What is the meaning of "col-md-3" and "col-md-9"?
Thanks in advance
col-md-3 and col-md-9 are the bootstrap grid and mean on medium devices and up - make this div span 3 columns and 9 columns respectively. On sizes less than this they will be 100% wide.
Damyon, that position sounds fine in the abstract, but it is untenable. Suppose you add a new feature to mod_assign, or I add one to mod_quiz, or more seriously third-party plugin creator is making a plugin.
Unless you add enough style rules to styles.css, then the feature will look bad in most themes, and we don't want that.
Therefore, as a responsible developer, you add what is needed to styles.css (and I have never had any push-back from integrators about what I have done in that regard.)
But then, when someone wants to do a very different styling, the then have to add lots of custom CSS in their theme to override the core styles, and that is a pain. (I have been there too, with the quiz, styling it for the OU.)
I would be really happy to have a proper discussion about this, indeed, I have tried in the past, but without getting any useful outcomes:
I set up two sites from scratch, and used default settings. One was in 3.1 (Clean theme) and one was in 3.2 (Boost theme). In the 3.2 site, I disabled (hid) all of the blocks. I then accessed each site from a desktop to see if there are any obvious problems.
Presently, as a teacher or student, the 3.2 dashboard doesn't have any real information without blocks. All you can really see is the Boost site navigation menu the same as on any other page. On 3.1, the dashboard shows the navigation menu as well as:
- Course overview with key information on courses I am enrolled in.
- Private files area.
- Online users.
- Latest badges.
- Upcoming events.
These are all blocks in 3.1 and are available in 3.2 if they are enabled.
In 3.2, "Private files" and "Calendar" can be accessed from the navigation menu, rather than an extra block. The only place I could access my badges is in the "Preferences" section of my account menu ("Preferences -> Manage badges"), so this might need some work. "Course overview" and "Upcoming events", which I think would be key dashboard information, require the blocks at this point. "Online users" likewise would need a block at the moment, although the importance of this may not be so great.
One thing to note as well is that without blocks, the "Customize this page" for the dashboard really does nothing.
On the course page, information provided by blocks that are standard in 3.1 that would be missing in 3.2 are:
- Forum search.
- Latest announcements.
- Upcoming events.
- Recent activity.
I don't think there are replacements in the Boost theme for these function as of yet. I re-enabled those blocks to get that experience back.
There are likely sites who don't care if that information is displayed, but there are probably more that would like this information available. Adding it to Boost would also require the ability to choose whether or not to display these bits. Blocks makes that easier now.
There was a comment above about "developers [wanting] to be able to insert anything they like into any part of the page", but I don't think that's what the key issue is. Its more about learning program administrators being able to ensure that the key information they require for their stakeholders is displayed at the proper places. If its not blocks, then its something else that allows information fragments in the page.
It is very important that the design makes the mobile experience better. But it shouldn't make the desktop experience lesser to achieve this. I just don't see how we can do that without blocks or a functionally similar replacement.
Mike, I don't know why you are talking about removing blocks from dashboard - and also why you keep suggesting that Moodle will remove all blocks at some point in future. In Boost we have made it clear that content is prioritised over the blocks - but blocks are still there and still work like they always did.
Blocks on dashboard makes perfect sense. The blocks ARE the content on this page and putting them in prime position in the middle of the page is logical and good.
I also like the idea of a course dashboard with blocks on it.
Hi Damyon -
I removed the blocks as per the testing discussion above. I asked, "for testing purposes, is it recommended to disable or hide all blocks?" The response was "yes". So, that post was the result of testing in that way. I was identifying the things that might still need blocks even with Boost.
The reason I and others are discussing Moodle without blocks is that it was stated (at least to our understanding) that Moodle is trying to do away with blocks, and that Boost would be the first test of this. And it was definitely stated that blocks would not be displayed in the Mobile app in the opening post of this discussion.
Maybe myself and others have fixated on the wrong message then? Is the intent for Moodle to continue to use and depend on blocks for function and information outside of the main theme displays? I feel that is necessary and would be glad to know that is true.
Yes I think removing blocks from the dashboard makes no sense because the dashboard is just a page of blocks.
Course formats now come with no default blocks (except the social format which requires the social activities block) - you can add some if you want to and they will function as well as they always have. Martin has commented about the mobile app and is 100% correct in that the mobile app does not display blocks - so if you design your course in a way that is relies on the information presented by the blocks, users on the mobile app will get only a "partial" experience of the course.
The navigation and settings blocks are 2 that have been prominently displayed on all pages, at the expense of room for the content and I am very glad that these 2 blocks are no longer required on every page in Boost.
That said there are many great blocks that provide quick access to information or new ways to interact with a course (level up or progress bar blocks for example). These blocks continue to work and are providing the kind of supplementary information that I think enhances a course without breaking it when that information is not available. We are recommending that course designers should think hard about the blocks they add to a course and only add blocks that will enhance the course instead of sticking with the 5 standard blocks that came by default in previous versions. There is a negative impact on the amount of space available for course content when blocks present.
We will continue to refine boost and improve the experience in Moodle over time and welcome everyones opinions and feedback.
In my current 3.2 w/Boost, the right blocks seem to not provide the ability to be "collapsed." For example, using CLEAN the Calendar block provides controls so that it can be collapsed, but not with Boost (I am just using the Calendar block as an example, all right blocks in my Boost cannot be collapsed.) Is this a setting somewhere? Also, in Boost, the month heading is on the bottom of the Calendar. This seems odd to me. Every calendar that I know about puts the Month on the top.
(In my figure, CLEAN is on the left and BOOST is on the right.)
MDL-56018 seems to refer to the dock (or not having a dock in Boost ) Not sure what the 'something new' is in relation to a dock - docking is very differnet functionality to the new drawer, which only really applies to the admin/navigation rather than the ability to dock blocks. In Clean, though, we can minimise/hide the blocks in place too and that option doesn't seem to be available in Boost.
Thanks Mary. I do see that the calendar month heading is now in the right spot, per MDL-56776.
As Richard noted, the "block thing" in MDL-56018 is something different. I think it is still important to be able to collapse a block (vertically, with the minus icon.) I have some blocks that students might not necessarily want to see, so it is good to give them the ability to collapse a block (to its heading.) For example, maybe some students rely on the Calendar and now on Upcoming Events, so they might want to collapse Upcoming Events, which could be taking up real estate in their browser.
No, I am not interested myself in moving a block to a collapsed edit.
Daymon (and others), is there any easy way yet to customize the items that are in the new "drawer"? For example, I don't want students to have "Private Files." So I have not provided this when I use the MORE theme. But with Boost, even though I have disabled the private file block, "Private files" still show in the drawer.
When a student is in a course, I don't want to show "Badges" or "Competencies" because I am not using these.
If we cannot customize the drawer yet, is it on the list of "feature requests" yet? Is this something that one needs to build into a Boost theme preset? Are there any docs for this yet?
Making the change that Daniel suggested worked. (Thanks Daniel.)
Two follow-up questions:
1) Do I need to disable these for both authenticated her and "student"? I use self-registration, but sometimes I add students manually. I am never sure if an student added manually is an "authenticated user."
2) For badges and competencies, might you provide the exact settings as Daniel did? I am having a problem finding these. I made a few changes, but a student, when in a course, is still seeing these.
Authenticated user is anyone logged in with a username and password, anything, but guest. This is system rather than and course role used for site pages like profile, site blog, private files etc. It should not matter whether a user is a student or instructor in a course because private files belong to the user and not the course.
If you liked you could give the permission to managers or to course creators as these are also system roles.
Badges are disabled under Site administration -> Advanced features and competencies under Site administration -> Competencies -> Competency settings.
Is there a way to remove Calendar from navigation pane too?
I think blocks provide a good functionality and we should avoid getting rid of them. However in their current use with their assigned regions they are just outdated. I fantasise about a future where we will still have blocks as a plugin type. But they are small bits of html templates that can be inserted just about anywhere we want it. They do provide awesome functionality but they lack the flexibility that we need in the age of the modern web.
I think in the future we should be able to let a theme fetch a block with the new requireJS framework and decide whether it wants to put it in an oldschool blockregion, or even in the place of a course section. The theme is the controller. The plug-ins are the views and the models.
The Boost theme is based on the Bootstrap 4, which is still in alpha version. As is written on bootstrap blog "We still have a lot of work to do, but we’re closing the gap and getting more stable with each release."
Do you really want to force using Boost on vanilla installs with alpha version of Bootstrap?
I'm excited to try out the new theme! Any word on how accessible it is for screenreaders like JAWS?
We have an HTML block that we use on our site to announce system maintenance. In it, we have a little image. That image is usually centered and still is in themes other than Boost. When I inspect it and disable the "display: block;" the image centers. I'm curious what's going on and why.
Thank you for all your hard work.
I'm on the Teaching for Moodle course and I have to say (so far) I love the look and feel of BOOST. It seems to be quite a change though, so I wonder what impact its use will have for people currently using other themes. I have the moodle.school School theme installed, and am considering using BOOST, but I'm worried it will break some of the current functionality the School theme has. Is there any comparison infographic of the most themes and their functionality out there?
Great to hear you are enjoying the new Boost theme.
There are certainly differences in functionality between the MoodleCloud School and Boost themes and using Boost will likely impact on the functionality currently available in the School theme. I’m unaware of a comparison resource between the two themes, however, I can say we have plans to incorporate Boost features into the School theme in a future update to MoodleCloud. In the meantime, switching to use Boost is possible, however, be aware the user experience will change. If you have any specific questions about your Moodle for School site contact the MoodleCloud team - email@example.com
Product Manager - MoodleCloud
I'm a new member here. I'm currently testing the boost theme for my institution's moodle and so far all seem fine except for one issue: i cannot navigate back to a course page from the Turnitin assignment submissions page. I don't know if this is due to the moodle ugrade from 2.9 to 3.2 or if its the boost theme. In moodle 2.9, we had links to the dashboard, course category page, course page etc at the top of the turnitin assignment submission page but none of these is available in 3.2 using the boost theme.
Can you please help?
I am using the Boost theme with the preset-colorfunction.scss. The problem that I am having is when changing the dimension of the window, it is truncating the content region but the background seems to be padding a consistent 1.5" . Is there a setting I can use to make the padding adjustable with the change in the dimension, I would rather see the background area minimize instead of the content area.
The prototype link for the Boost theme is broken- can someone provide a link please?