Hi. If I understood what I heard at the UK Moot this week, there are plans to remove blocks from Moodle by the 3.2 release. Can someone point me to the details on this? Mike
Mike,
I think what Martin clarified, during a Twitter discussion, was that this was a single theme that would be without blocks (I believe he said as the default theme, but I sincerely hope not - maybe as one of the core themes?).
Martin's tweet to me referenced a tracker item https://tracker.moodle.org/browse/MDL-52973 which seems to go very speedily from the title of 'Convert all the nav block and settings links into contextual lists on each page.' to 'Blocks in general are seen by practically all web designers I've ever met as "old school" and something we should get rid of' to implementing a new core blockless theme. ('Practically all web designers' obviously doesn't include those who design Twitter, LinkedIn and Facebook - although not perhaps for navigation and settings - which all seem to have 'blocks' for additional content on their pages)
I think the idea of totally reworking the nav and settings blocks and even removing the default config of blocks added to pages/courses by default (Calendar, latest news etc) is definitely a good thing (start with a clean page, sure). But removing blocks/block regions entirely is not IMHO something that should be done with out a way to replace the functionality they provide.
The dock and the zoom all features provide a way to hide blocks for individuals or sessions, teachers and admins are free to remove all the blocks anyway (not put any on their courses in the first place - and remove the default ones), so 'removing blocks' per se seems like a bad idea to me, while removing the enforced startup blocks and improving control over where those blocks can be used and positioned would seem a better option.
Bad use of blocks can make a course page cluttered and un-intuitive and can harm the learning, but removing them entirely would be preventing the good practice too. But conflating the idea that Nav and Settings badly need a reworking with the idea that 'blocks are bad', is I think missing the point.
Personally, I'm hoping the intention is a clean page with no default blocks, but retaining block regions to allow blocks to be added as appropriate.
Richard
PS - I note that the theme currently linked to in that tracker item does not appear to be blockless or at least it does have pre and post regions in both its config.php and its layout files, so I'm hoping we will be looking at the option of removing default blocks, but not removing block regions? Surely that could be resolved through a change in where the default blocks are set up as part of moodle config though, rather than a new theme?
Thanks for the followup Richard, and the link to the issue.
Could be just be talking about semantics here? Maybe "blocks" in this discussion is referring to the way they were implemented in the past, as rectangles on one side or the other. But certainly "blocks" as a Moodle plugin have a huge amount of display flexibility in today's Moodle. I look at them as containers for information and functionality that can be inserted in a variety of ways on any page to facilitate the way a Moodle site wishes to manage its information.
There are currently 278 blocks in the plugins database. I'm guessing we won't abandon those, right? Anyone from HQ? Make us feel better? Please?
mike
I think what Martin is envisaging is a mobile first model, where things like 'blocks' will take on a new guise, as will 'themes' to a greater or lesser extent.
Just some of my personal views.
Whatever the end result it will mean that thankfully we will be moving away from some very old methods of working and using some state of the arts thinking.
Bring it on...
Cheers
Mary
MoodleRooms' Snap theme does away with the idea of box-like blocks in a realistic and very usable manner.
Not really - they are just in a region which is set below the main content (And are styled without borders, etc)
<aside id="block-region-side-pre" class="block-region yui3-dd-drop" data-droptarget="1" data-blockregion="side-pre">
That said, the way Snap handles the admin block and the 'pop up' navigation page are a great development and way of handling those particular blocks, links and content. It certainly seems a major usability improvement and something to look at in moving forward with the kind of changes to navigation and admin control being considered
Blocks in snap should be appearing only in the course tools area of the table of contents in a course. They should not be appearing below the content except on the site main page.
The only reason for this is that we have yet to determine a usable way to display blocks to admins on the front page without displaying them below the content and because or usability improvements for snap have focused on learners and educators over admins.
Thanks for that Jason - I was in the process of reinstalling my laptop at the time and hadn't got around to rebuilding any courses on my test server.
I love the way Snap handles blocks on a separate page for the course, rather than as part of the main course display - but would still say that snap doesn't 'do away with the idea of box-like blocks' - it does have a great way of displaying them separately and managing the actual course page itself. Blocks are still there to provide the functionality where its needed (e.g. if I wanted to add a Progress Bar, or a link to Panopto - video capture that comes as a block providing the integration link) then I still can, but without impacting the main course content display
I think its an ideal compromise with the way Moodle currently works, providing a much better interface, but still allowing the functionality when needed
I am happy you like Snap. Snaps interface is a compromise because I agree right now blocks provide a lot of functionality that teachers require. Course tools however as a term doesn't encompass all the various tasks blocks are created to do.
My perspective is that it isn't some much that a theme needs to be created that removes blocks as blocks as a plugin need to go away. Blocks have been historically used in Moodle as a catch all for features and tasks that couldn't be performed by other plugins.
You mentioned progress bar which to me is an excellent example. This block has a visual display for the user on their progress ( similar to snaps table of contents showing completion information per section of the course). The block also has a report that you can view. In my opinion these features should have been split up. Progress is a theme display and reporting should be in a reporting engine. Putting the two together in a block provides a usability issue because now if I want to find my students progress I have to find this block rather than looking at the course reports. And I need to make sure the block is in a prominent place for students to see. Not only that some courses might show the progress blocks in different locations on the page based on other blocks used, which will cause confusion for the student.
To me the better process is to figure out if blocks as a plugin should exist or if there are enough plugin types to now support the features blocks are created for in a better way.
"Progress is a theme display"
Hmm not sure I agree with that - to me there is already too much functionality being built into themes which should concentrate on the look and feel, simply because its the best/easiest way to make that functionality happen. Maybe Progress is a sub-plugin for activity completion? not sure - maybe you are right, its already there really in activity completion it is just finding a way to display it, so possibly it is a theme issue - different ways to get to the same aim
That said - I'm not disagreeing with your principle. My point at UK/IE Moot at the table with Mike and in other conversations and here is not so much that we must retain blocks at all costs, but that we shouldn't be theming them away until such time as the functionality that they provide is made available in other ways - such as alternative plugin forms perhaps, or enabling existing plugin types to do some of the things blocks do.
I don't mind if they are called tiles and moodle allows them to be built into main content, headers or wherever (although that may simply be because I'd like to see more control over that main content layout and not have to use html blocks for some of it to get it where I want it ), or if the functionality is rolled in with activities and local plugins - given that some of the key ones need much more urgent action than that (such as the navigation and settings and so on that I know are already being worked on).
Yes, lets move on from blocks if thats what HQ feel is the right way to go (I'm not 100% sure myself but that's more related to the functionality than the display as blocks), lets provide other ways to do it - but lets look at it the way you have with Snap in the meantime - an unobtrusive way to include block functionality, a compromise, until we have the ability to provide those functions in another way. Once we have that 'other way' embedded and in practice, then would be the time to create themes that do away with blocks.
I simply feel that doing it now (for 3.2) is jumping the theme ahead of where the functionality is - not that its not the right way to go, just the timing and application of it - And that's one of the reasons I like Snap so much. It (for me) does a great job of addressing that balance, providing a clean user interface, but still allowing the functionality of the blocks on a linked page.
[Or to give the TL;DR short version - completely agree with you. But lets get that functionality into alternative plugin types before removing blocks from themes entirely ]
I can agree with waiting till the functionality is moved into another plugin type and new ones are created.
I also agree with Erica idea of a plugin in the middle of the course. We actually had to create a hack to produce that effect to display analytics data to teachers that is important when viewing the course. It is part of our X-ray product.
I would have been much happier if we could have just created a plugin that interacted with the before course content or after course content variables that are part of the course format.
To me, saying a feature (progress bar) is a theme design item is all wrong, and shows a lack in the current plugin capability. That is coupling a feature and display.
To me, what is missing is a plugin that can display content in a row that is occupied by a module currently. Right now label is the only one that really inserts special content there. IMO there should be a plugin type that is simpler than mod that can display specialized content there. That way you can have more dynamic inline content, like the progress bar (and place it where you want).
For progress that to me is to limiting. The reason I was saying theme is because of the way snap works. Progress is displayed all over the place. It starts in the menu with the list of courses. It continues to display progress in the course at the section level and then finally when displaying the completion check boxes next to each resource and activity.
Progress also needs to be extended to learning paths and competencies as well. A theme has the most control over all locations that progress should appear along with a congestive look and feel. The other option is for progress to be built in every where in the product.
I'm pretty much in agreement with Richard and Eric on this statement - "Progress is a theme display".
If we rename blocks to, or create a new plugin called, "Theme display", that defines areas of the screen to drop them in, then sure. But otherwise, I don't think the theme should decide what functions and/or content get displayed.
I am unconvinced that we can do away with blocks as plugins. If we want to rename them as "widgets" or "tiles", fine. But they provide a way of creating add-on functional and content features to Moodle that I don't see any other way to provide. I am sure there are some blocks now that could be suitably replaced by one or more other plugin types, but not all of them.
Without the ability of customizing Moodle "pages" with block add-ons, Moodle would be a "one-size fits all" solution like Canvas. One of Moodle's primary strengths is the ability to customize and tailor it to specific needs.
mike
Breaking down the distinction between blocks and modules (activities/resources) would be an advantage, from my point of view. We switched to the Flexibase theme because we needed to be able to place "blocks" (especially the Latest News block) in the center area of the course. Then again, that put the block EVERYWHERE on all pages of Moodle, which wasn't really what we wanted.
Right now we have "things that appear only on one page in Moodle, in the center content area" and "things that can appear in multiple pages, in a hierarchical manner, but only in the sidebar areas." I'd like to see that distinction broken down. I don't, however, want to get rid of the ability to place something into the site level of Moodle and have it available hierarchically to users everywhere within the site, whether it appears in a sidebar block, a pulldown menu, or in the central content area. There are good reasons to want to do all of these things, in the right circumstances.
Hi Elizabeth,
I'm glad you like flexibase - if we take that specific discussion away from this thread (only so I don't take the thread off topic ), could you post what you are trying to achieve and why it isn't working in the flexibase issues page on github please (hopefully with some testing instructions to help me replicate) and I will do my best to see if I can fix it and improve flexibase for you
Richard