Hi all,
Which 3 plugins in moodle.org/plugins would you like to see added to core (unofficial survey)?
Michael
Which 3 plugins in moodle.org/plugins would you like to see added to core (unofficial survey)?
Michael
Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Michael Milette -
Number of replies: 19
- Group Choice
- Multi-Language Content (v2)
- Subcourse
- Enrolment upon approval
Thanks Germán! SurveyPro looks very interesting. I had not come across that one before.
I used SurveyPro in my test server with university students and it worked very well.
I suggested a few changes to the author and he kindly incorporated them in the GitHub code.
This plugin has been maintained and is vastly superior to anything currently available in core or additional plugins.
You can add it to your server very easily by downloading a ZIP file from GitHub and following the described procedure.
I suggested a few changes to the author and he kindly incorporated them in the GitHub code.
This plugin has been maintained and is vastly superior to anything currently available in core or additional plugins.
You can add it to your server very easily by downloading a ZIP file from GitHub and following the described procedure.
FilterCodes! 😁
That, or a more user friendly way of adding automated content to text via ATTO, like an ATTO button that would work similarly to Generico, but with a standardized set of automated content strings that can be added.
In reply to Michael Milette
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Germán Valero -
There is a Moodle Docs page that list many Third party plugins developed by universities and many of those would be VERY useful for many schools that are currently restricted to using Moodle core as is.
You can list additional plugins sorted by the number of installs in registered Moodle servers at https://moodle.org/plugins/?q=sort-by:sites
I think I recall that Moodle 4.0 was supposed to incorporate many third party plugins (considered useful by many users) in the core, but I could not find the exact place where I read this.
In reply to Michael Milette
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Melanie Scott -
Face to Face
Auto Enroll and/or Course completed enrollments
Adminer and/or merge users
Auto Enroll and/or Course completed enrollments
Adminer and/or merge users
In reply to Michael Milette
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Joost Elshoff -
To properly answer this question, it would be nice to have some insight into the added value of having a plugin (of any kind) in the core distribution, as opposed to having it maintained by the original developer(s).
What would be the advantages of this? And would those advantages outweigh the time and resources required from Moodle HQ to maintain these plugins?
What would be the advantages of this? And would those advantages outweigh the time and resources required from Moodle HQ to maintain these plugins?
In reply to Joost Elshoff
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Shirley Gregorczyk -
Course Recompletion
Monitoring of Learning Plans https://moodle.org/plugins/report_lpmonitointring
Grades (custom menu - student overview report)
Face to Face
Merge users
Monitoring of Learning Plans https://moodle.org/plugins/report_lpmonitointring
Grades (custom menu - student overview report)
Face to Face
Merge users
In reply to Shirley Gregorczyk
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Randy Thornton -
+1 and +1 for
Course Recompletion
Monitoring of Learning Plans https://moodle.org/plugins/report_lpmonitointring
Also, several of the Availability restrictions should be in core, such as Restriction by Cohort, by Relative Date, by Course completion, by Previous course completion, by Course role.
And most importantly (pace what is in 4.0) the Boost navigation fumbling plugin.
And last but not least in my heart: Configurable Reports.
Long ago, I was promised a flying car and a reporting engine in Moodle. I still have neither, sadly.
Course Recompletion
Monitoring of Learning Plans https://moodle.org/plugins/report_lpmonitointring
Also, several of the Availability restrictions should be in core, such as Restriction by Cohort, by Relative Date, by Course completion, by Previous course completion, by Course role.
And most importantly (pace what is in 4.0) the Boost navigation fumbling plugin.
And last but not least in my heart: Configurable Reports.
Long ago, I was promised a flying car and a reporting engine in Moodle. I still have neither, sadly.
In reply to Randy Thornton
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Marcus Green -
"And last but not least in my heart: Configurable Reports."
Might this change your mind?
https://tracker.moodle.org/browse/MDL-70343
Might this change your mind?
https://tracker.moodle.org/browse/MDL-70343
In reply to Marcus Green
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Randy Thornton -
No, I am familiar with the Workplace report, which is clearly modeled on the one that has been in Totara for at least five years now.
It does a decent job at what it does, which is let someone with no coding experience pick and choose from a limited set of table and fields into a spreadsheet style report. It will be useful for basic reports missing for two decades now, such as reports across courses, Enrolment details, Course Completions, etc. But it is basically a limited sort of report builder we have been able to find in apps like MS Access since back in the early 1990s.
But you can't do anything really interesting with it and nothing custom at all if you want things like calculations, have interesting questions (for example: how many suspended users still have both grades and badges but no certificates? What's the average enrolment size of child meta courses compared to the number of teaching assistants assigned to them via groups? Show me the Assignment marking guide comments from teachers newly employed in the last six months for countries other than their own...) And it can't handle third party plugins, either. If you depend on a Certificate mod, as in companies, that won't help you much (because Workplace certificates are core and work entirely differently than in Moodle).
Of course, that stuff may come along in time with some api calls.
I doubt that either the permissions for the reports - which are planned but there's no indication of progress on them yet - will be able to match the flexibility of the many ways that CR can allow reports to be seen and by whom. There's only going to be four types according to the tracker:
It does a decent job at what it does, which is let someone with no coding experience pick and choose from a limited set of table and fields into a spreadsheet style report. It will be useful for basic reports missing for two decades now, such as reports across courses, Enrolment details, Course Completions, etc. But it is basically a limited sort of report builder we have been able to find in apps like MS Access since back in the early 1990s.
But you can't do anything really interesting with it and nothing custom at all if you want things like calculations, have interesting questions (for example: how many suspended users still have both grades and badges but no certificates? What's the average enrolment size of child meta courses compared to the number of teaching assistants assigned to them via groups? Show me the Assignment marking guide comments from teachers newly employed in the last six months for countries other than their own...) And it can't handle third party plugins, either. If you depend on a Certificate mod, as in companies, that won't help you much (because Workplace certificates are core and work entirely differently than in Moodle).
Of course, that stuff may come along in time with some api calls.
I doubt that either the permissions for the reports - which are planned but there's no indication of progress on them yet - will be able to match the flexibility of the many ways that CR can allow reports to be seen and by whom. There's only going to be four types according to the tracker:
- All users
- Specific users
- Cohort members
- System role assignments
So, none of the cool features like by user profile or even course roles or multiple conditions or ? At least there will be an API that could be expanded in the future, but we already have this in CR. Why not just put it in now?
Will there be a template library? An export to xml function? A way to share reports?
If it had a SQL panel just to input code and be able to use its formatting options - as Intelliboard does - then I would be interested in it.
For those who have nothing, it will be a great improvement.
To those used to rolling their own reports, it will be useful for making easy generic reports for users who can't or won't do their own. This will be a real time saver. But for anything sophisticated or custom, you will still need to have both CR and the Ad-hoc queries plugins.
But, now you will have three tools, all of which work differently and look differently and have different features and limitations. They say, "Don't look a gift horse in the mouth." But if you don't, you might end up with a donkey, a zebra, and a water buffalo.
In reply to Randy Thornton
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Randy Thornton -
Marcus,
Apologies for my rant ;)
The good news is that Workplace's Report Builder is a good tool with ongoing improvements: corporate customers demand competent and full featured reporting and Moodle will have to constantly deliver those improvements to them or else.
The bad news is, of course, Moodle's track record of putting in a new feature and then letting it languish for years with little or no improvement. If this is a one time port from Workplace, then that would be disappointing, but not surprising.
Meanwhile, if Report Builder could have as a counterpart a combination plugin of CR and Ad-hoc dq features combined into one plugin for the development and sharing of custom code, that would be an ideal one-two combination.
In reply to Randy Thornton
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Marcus Green -
"Apologies for my rant ;)"
As someone who spent 1995-96 using MS Access2 and creating reports with Crystal reports (and loving it) consider it a top quality rant. I suspect it will not be a one time port.
As someone who spent 1995-96 using MS Access2 and creating reports with Crystal reports (and loving it) consider it a top quality rant. I suspect it will not be a one time port.
"which is let someone with no coding experience ...."
That's most people, and I am very keen that Moodle provides tools for them.
In reply to Marcus Green
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Randy Thornton -
I agree and I certainly hope it is an ongoing and active transfer of features from the Workplace version to Moodle.
In reply to Michael Milette
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by David Mudrák -
None. In fact, I would prefer if Moodle had no plugin at all by default. Instead, the mix of plugins best suited for the given target deployment would be chosen during the download / in the installer. And it would make use of the community crowd experience, provide some suggestions, reviews etc. And plugins maintained by the Moodle HQ would be on the same transparent market as anybody else's ones.
In reply to David Mudrák
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Richard Oelmann -
I'd potentially take a different approach to a similar outcome.
I'd quite like to see a wider range of plugins included in the code base - but have them all disabled by default. That would allow a site admin to add those features simply by enabling the plugin through a UI, without having to concern themselves with uploading/downloading/installing additional code. Those features would be maintained as part of the core code base, so version compatability concerns would be removed, but being disabled by default means they wouldn't add to the initial 'feature bloat/creep' that sometimes leads to the concerns that Moodle can be too complex.
I'd quite like to see a wider range of plugins included in the code base - but have them all disabled by default. That would allow a site admin to add those features simply by enabling the plugin through a UI, without having to concern themselves with uploading/downloading/installing additional code. Those features would be maintained as part of the core code base, so version compatability concerns would be removed, but being disabled by default means they wouldn't add to the initial 'feature bloat/creep' that sometimes leads to the concerns that Moodle can be too complex.
In reply to Richard Oelmann
Re: Which additional plugins would you like in core? (was Re: Moodle core plugins review)
by Randy Thornton -
David and Richard,
Those are interesting ideas. My thoughts on this, pro and con are similar. It sounds rather a lot like the model that Wordpress has: a small(er) core with many, many plugins. It has a lot of advantages.
Having a slimmer Moodle core set of tools would certainly be useful in many ways. There's any number of core plugins I would happily rip out if I could but every time I suggest this, I always get push back saying, "We want that in core." Well, if I don't want that in core, I am stuck with it and have to then deal with that. So, not only would it be useful to add in core tools later, but right now we can't even remove most of those: next update, it will give you a headache and try to reinstall them. Making core plugins truly pluggable like third party plugins would a definite improvement.
Another advantage might be it would promote a bit more the abstraction of certain tools from core (eg Quiz and Gradebook) to allow them to have more potential competitors
I know there's a lot of interdependence between certain features, but encouraging more tools to be pluggable is good.
On the other hand....
having managed Wordpress sites, I can say that admins will end up spending much of their time and most of their frustrations managing plugins with the slim core model.
To get a Wordpress site to do pretty much anything at all other than simple blog posts & pages, you have to spend a lot of time hunting for plugins, paying for plugins, and managing plugins. All those plugins have to play well together: that is sometimes a difficult challenge. It takes a lot more work to do that than the current Moodle approach.
Right now, I think there's a couple challenges to getting this to work with Moodle:
- The only thing that makes this tolerable in the Wordpress world is the ease with which updates and upgrades can happen. We only have part of that in Moodle. Updating plugins is light years better than it used to be - thanks in large part to the work of David.
But we can't update Moodle itself this way and if we could, we would need a lot of logic to make sure versioning was good. Having all this info right on on admin panel like the one that WP has would be very useful: we don't really have a central place for this in Moodle due to the "our big core" versus other's plugins approach. Consolidating the Notifications page with the Plugins overview page would be needed too.
- There's a lot of incentive in the WP world for plugin devs to build alternate versions of plugins: partly because it is easy to pay for them. We would really need a payment system for plugin developers so that we can avoid the common problem of orphaned plugins. I think the only successful place in Moodle where this sort of works now is with themes. An official plugin Marketplace is needed.
- A recommendation system would be needed. I recall some time ago there was a project to get experienced Moodler users to write up reviews of plugins, but I don't recall it went very far. You would need something like that - and a way to prevent abuse of it (which is yet another frustration of the WP world: useless and fake and paid reviews for plugins are legion.)
- For new sites, you need some sort of addition to the install process which lets new site admins pick from a set of key tools. First time installs by new admins can be a problem since they may not really know what plugins they should add, pedagogically. Having a couple of predefined packages of common plugins would be very useful, or even an install wizard that would lead them through choosing common plugins.
I think this could give you both a slim core, but also have the ability to do an initial install of plugin sets at install type, disabled to start with, disabled to start with as Richard suggests.
- A related issue is that we all know how this works in the real world: having made an initial choice, it means other tools that teachers may want to explore and try out will not be in the site at all. Teachers might just use what they have and not know there are other possibilities. For example, now many users would try out Lesson or Glossary or Badges if they were not already just sitting there to try? Being able to experiment and trying out new activities is important for teachers and course designers too.
That would be gone and replaced by some sort of request to the admin to install something just to look at it. Having to install plugins instead of simply enable them does add friction to the process: neither admins nor teachers like friction. And installing a plugin is a lot more friction for admins - and an interruption for all users - than simply enabling one already installed.
- Security is an concern too: installing a new plugin is much more potentially dangerous process that simply enabling an already installed plugin: right now there's some very important security that has to be be in place for the code. I can't just install a plugin without going to the server to open up some permissions temporarily. Again, you can say admins should know how to do that, but it is another raising of the bar for new adoptions. While in WP with its integrated admin panel, this is taken care of so there is a lot less interruption to users than Moodle has.
I have to say that personally, I find the Moodle approach a lot less headache than the Wordpress approach to plugins: I mean, almost NO Wordpress is usable these days out of the box. You always have to add plugins to to get anything useful. Back in the day, when blogging was new, this approach made sense: the only core tool you had posts. Of course, this is also true of Drupal (and to some extent Joomla) but that is the nature of those tools.
Those are interesting ideas. My thoughts on this, pro and con are similar. It sounds rather a lot like the model that Wordpress has: a small(er) core with many, many plugins. It has a lot of advantages.
Having a slimmer Moodle core set of tools would certainly be useful in many ways. There's any number of core plugins I would happily rip out if I could but every time I suggest this, I always get push back saying, "We want that in core." Well, if I don't want that in core, I am stuck with it and have to then deal with that. So, not only would it be useful to add in core tools later, but right now we can't even remove most of those: next update, it will give you a headache and try to reinstall them. Making core plugins truly pluggable like third party plugins would a definite improvement.
Another advantage might be it would promote a bit more the abstraction of certain tools from core (eg Quiz and Gradebook) to allow them to have more potential competitors
On the other hand....
having managed Wordpress sites, I can say that admins will end up spending much of their time and most of their frustrations managing plugins with the slim core model.
To get a Wordpress site to do pretty much anything at all other than simple blog posts & pages, you have to spend a lot of time hunting for plugins, paying for plugins, and managing plugins. All those plugins have to play well together: that is sometimes a difficult challenge. It takes a lot more work to do that than the current Moodle approach.
Right now, I think there's a couple challenges to getting this to work with Moodle:
- The only thing that makes this tolerable in the Wordpress world is the ease with which updates and upgrades can happen. We only have part of that in Moodle. Updating plugins is light years better than it used to be - thanks in large part to the work of David.
But we can't update Moodle itself this way and if we could, we would need a lot of logic to make sure versioning was good. Having all this info right on on admin panel like the one that WP has would be very useful: we don't really have a central place for this in Moodle due to the "our big core" versus other's plugins approach. Consolidating the Notifications page with the Plugins overview page would be needed too.
- There's a lot of incentive in the WP world for plugin devs to build alternate versions of plugins: partly because it is easy to pay for them. We would really need a payment system for plugin developers so that we can avoid the common problem of orphaned plugins. I think the only successful place in Moodle where this sort of works now is with themes. An official plugin Marketplace is needed.
- A recommendation system would be needed. I recall some time ago there was a project to get experienced Moodler users to write up reviews of plugins, but I don't recall it went very far. You would need something like that - and a way to prevent abuse of it (which is yet another frustration of the WP world: useless and fake and paid reviews for plugins are legion.)
- For new sites, you need some sort of addition to the install process which lets new site admins pick from a set of key tools. First time installs by new admins can be a problem since they may not really know what plugins they should add, pedagogically. Having a couple of predefined packages of common plugins would be very useful, or even an install wizard that would lead them through choosing common plugins.
I think this could give you both a slim core, but also have the ability to do an initial install of plugin sets at install type, disabled to start with, disabled to start with as Richard suggests.
- A related issue is that we all know how this works in the real world: having made an initial choice, it means other tools that teachers may want to explore and try out will not be in the site at all. Teachers might just use what they have and not know there are other possibilities. For example, now many users would try out Lesson or Glossary or Badges if they were not already just sitting there to try? Being able to experiment and trying out new activities is important for teachers and course designers too.
That would be gone and replaced by some sort of request to the admin to install something just to look at it. Having to install plugins instead of simply enable them does add friction to the process: neither admins nor teachers like friction. And installing a plugin is a lot more friction for admins - and an interruption for all users - than simply enabling one already installed.
- Security is an concern too: installing a new plugin is much more potentially dangerous process that simply enabling an already installed plugin: right now there's some very important security that has to be be in place for the code. I can't just install a plugin without going to the server to open up some permissions temporarily. Again, you can say admins should know how to do that, but it is another raising of the bar for new adoptions. While in WP with its integrated admin panel, this is taken care of so there is a lot less interruption to users than Moodle has.
I have to say that personally, I find the Moodle approach a lot less headache than the Wordpress approach to plugins: I mean, almost NO Wordpress is usable these days out of the box. You always have to add plugins to to get anything useful. Back in the day, when blogging was new, this approach made sense: the only core tool you had posts. Of course, this is also true of Drupal (and to some extent Joomla) but that is the nature of those tools.
However, in Moodle, I would certainly like to be able to remove certain core features and plugins and never have them in the site at all. So, perhaps these new approaches could encourage more of a fully pluggable architecture for core. And we could have our cake and eat it too