Future major features

MoodleRoom's proposed Outcomes changes

Picture of Kris Stokking
Re: MoodleRoom's proposed Outcomes changes
Plugin developers

Tim, thanks for all of your feedback on the proposed Outcomes system!  As Phill has stated, it is clearly a work that is still in progress.  We have lots of ideas on how we could implement certain requirements, but nothing has been fully defined enough to share yet.  We won't be breaking ground on development before the technical architecture has been drafted and generally agreed upon.  

Our primary objective is to create a system that can be powerful enough to meet the demands of the most requested features, while remaining flexible for developers to extend and implement in their own creative ways.  It is not our intention to define a white-list of plugins that can support Outcomes, and the way(s) in which they do so.  While the specification may identify a specific use case for associating outcomes to quizzes and rubrics, our technical team will need to abstract that as a way to allow outcome association at a more granular level per module and advanced grading method, using quizzes and rubrics as a specific implementation example.

Let me also try to address the questions you've raised:

1.  The DB schema will be part of the technical documentation.  It makes more sense to me to hold off on it until we've addressed the requirements further, but we can craft something if that would be helpful for the conversation.

2.  There's a balance that must be struck between creating new plugin types vs. the overhead of maintaining and configuring them. The 2 primary areas for plugins would be the reports (piggybacking off of the existing system) and the algorithm for marking whether a student has met the outcome (aka Streaks).  There may be other areas that would be useful, and they will likely come out in discussion.

3.  I would agree that Streaks should be a pluggable system - for those who attended, this would be the same system that we discussed during the Outcomes session at Hackfest.  We need a little more definition around Risk Metrics to determine whether it should be pluggable system or can be addressed through configuration.

5.  Obviously we'll defer to your judgement here, but couldn't we technically have both?  From the feedback we have received, it's pretty critical that the outcome is associated with a question in isolation, but that could simply be used to facilitate the outcomes associated with the question in a particular quiz.  I could see it being useful to allow the instructor to override that in some cases, preferably based on a capability to do so.

9.  The new Outcomes system would operate independently from the Gradebook.  I personally don't think it makes sense to mix Outcomes and Grades on the same report, especially since the Outcomes could be organized very differently in the new system.  It's possible that the Outcome Marking plugin could create a bridge in some cases, but that still needs to be defined.  


Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: MoodleRoom's proposed Outcomes changes
Core developersDocumentation writersParticularly helpful MoodlersPlugin developers

1. Yes, I get the point that DB schema comes later. But ...

I still think there is an argument for starting to develop the high-level logical data model now. What are the major entities, and how do they link to each other? For example, we know we have standards and individual outcomes, with a one-to-many relationship. Also, how to they link to existing moodle concepts like activity modules? That is many-to-many.

Another way to put it is that some people might say that UI mockups should come later in the design process, but you have included them in the spec already, and that is really helpful for understanding what is going on. I think that some high-level entity-relationship diagrams would similarly illuminate the spec, and more importantly help validate early on that what you are specifying will be possible to implement in the back-end.

2. First, creating new plugin types is not a big deal. pluginlib.php etc. do a lot of the work. Of course it should still only be done when really necessary, and for this spec most of the functionality fits into existing plugin types:

  • Any reporting uses either report_ or gradereport_.
  • 'Manage outcomes sets' could be a tool_.
  • I think we have greed that algorithms for computing whether an outcome has been met from other data should be a new plugin type. (Good luck naming that wink)
  • In theory, different import/export formats for outcomes could be a new plugin type, but in the first instance, we probably don't need to formalise that. If we ever find it necessary, we could move the code from inside tool_manageoutcomes to separate plugins.
  • For bits of the UI, particuarly student-related display, the UI might naturally work as blocks.

The core of the system will, of course, have to be added to Moodle core, as will the API that activities use to communicate with core.

5. Yes, looks like we are talking ourselves into a 'both' solution.

9. I am not suggesting that we mix grades and outcomes in the same UI. I am asking about the back-end. There are lots of similarities:

  • There is a central store of information about what students achieved on different activities.
  • For each activity, there can be multiple 'grade_items'. Those might be one or more different numerical grades, or they might be the evidence that a student has met one or more differnet outcomes from an outcome set.
  • There is an API for acitvities to push the information about which 'grade_items' correspond to it, and the value for each student for each grade item, once the student has completed the activity.
  • There is a plugable system of gradereport_s so the the data in the back-end can be displayed in different ways. There are also import and export plugins for getting the data in and out.
  • There is already code in the back-end to calculate new grade_items, and overal course summaries from other grade_items.
  • The gradebook and advanced grading plugins already play nicely together.

I think there is enough there to justify doing some serious thought about how much of the existing back-end can be re-used.

That does makes things harder initially. Certainly for you doing the design. It is much easier to design with a blank sheet of paper that to start from someone else's design where the only accurate and up-to-date documentation is the existing code. Simiarly it is harder to build on someone else's code that to write your own. Also, there are known issues with the gradebook API, but why can't we take this opportunity to fix them?

Even with all that, there may be good reasons why it is better to not build inside the gradebook back-end, but if so, I think you should be able to articulate why.

You were the one wh raised "overhead of maintaining and configuring them" (quite rightly!).

Average of ratings: -