Problem
Plugins are primarily classified by their technical type, such as activity modules, blocks, reports, or authentication plugins.
These classifications are useful to developers and system administrators, as they align with Moodle’s architecture. However, users browsing the registry may not know which plugin types are relevant to what they want to achieve, especially when they are focused on pedagogical or functional needs rather than technical structure.
Proposal
Allow plugins to be classified by one or more user-facing intents or purposes, independently of their technical plugin type.
Here are some example classifications to illustrate the intended approach. These examples are not exhaustive and are not intended to define a fixed or complete taxonomy, but to demonstrate how plugins could be grouped by user intent.
Teaching and course purposes
- Create rich learning: Create interactive content and media.
- Invite participation: Support discussion and collaboration.
- Assess and respond: Assess learners and give feedback.
- Engage and motivate: Encourage participation and persistence.
- Support inclusion: Improve accessibility and access to content.
- Make progress visible: Show completion, plans and progress.
- Organise courses: Structure and reuse course content.
Platform purposes
- Manage people and access: Manage authentication, enrolment and access.
- Connect systems and services: Exchange content or data with other systems.
- Report and analyse: Report on learning or site activity.
- Protect and govern: Support security, integrity and compliance.
- Operate and automate: Manage performance, storage and maintenance.
- Customise the experience: Change the interface or content tools.
- Develop and extend: Help developers build and test plugins.
These classifications would not need to be mutually exclusive. A plugin could serve several purposes.
Benefits
Frontends could use these classifications to present registry information differently, such as through purpose-based browsing, filters, collections, or recommendations.
This would improve plugin discovery for users who understand what they want to achieve but do not necessarily understand Moodle’s plugin architecture, while still remaining useful for administrators who benefit from an additional, complementary layer of categorisation when evaluating and managing plugins.
Problem
Plugins are primarily classified by their technical type, such as activity modules, blocks, reports, or authentication plugins.
These classifications are useful to developers and system administrators, as they align with Moodle’s architecture. However, users browsing the registry may not know which plugin types are relevant to what they want to achieve, especially when they are focused on pedagogical or functional needs rather than technical structure.
Proposal
Allow plugins to be classified by one or more user-facing intents or purposes, independently of their technical plugin type.
Here are some example classifications to illustrate the intended approach. These examples are not exhaustive and are not intended to define a fixed or complete taxonomy, but to demonstrate how plugins could be grouped by user intent.
Teaching and course purposes
Platform purposes
These classifications would not need to be mutually exclusive. A plugin could serve several purposes.
Benefits
Frontends could use these classifications to present registry information differently, such as through purpose-based browsing, filters, collections, or recommendations.
This would improve plugin discovery for users who understand what they want to achieve but do not necessarily understand Moodle’s plugin architecture, while still remaining useful for administrators who benefit from an additional, complementary layer of categorisation when evaluating and managing plugins.