Thanks for you comments! My responses to each:
1.Do we really need a separate admin setting for course completion, as opposed to activity completion?
I considered this quite a bit. I thought there might be a case in which an admin might not want both features turned off or on. For example, an admin might want to allow tracking of activity completion within a course, but does not want course completion enabled because the course final grade (relative to the course passing grade) is sufficient for the organisation's specific needs. To me, that's not a very strong case. The more I think about it, it makes sense to use one "Enable completion tracking" setting on the site level.
If they are going to be separate, I suggest "Enable tracking of which activities in a course have been completed" and "Enable tracking of which courses have been completed". Longer, but clearer, I think.
I think these would be perfect for the setting descriptions, which appear along with the more brief settings names on the "Advanced features" site admin UI. We would still need setting names though, and "Course completion tracking" and "Activity completion tracking" might need to be it.
I'm curious about what non-developers Moodle users/admins think about two settings versus one setting.
2. I don't think a single big form is the best UI for 'Course completion settings'. Instead, have a page that displays an (initially empty) list of criteria. That is, a list of Each criterion has an edit and delete icon next to it, and then have an "Add new criterion" button at the bottom. Add and edit could pop-up a little form (like adding a random question to a quiz in Moodle 2.0). Actually the same page could be used for both teachers configuring, and students viewing their progress. Just show the appropriate things based on capabilities. I know you want a block for students, but I think a block should be an additional UI option for viewing completion, in addition to a separate page.
I agree, the proposed UI is too overloaded.
Last week I mocked up a "criteria builder" much like what you describe. It needs a bit more work. It is based on Thunderbird's Message Filter UI, which--as you describe--"starts empty" (actually it starts with an example filter) and let's you "add new criterion". When I pitched the "criteria builder" concept to Matt Clarkson (showing him the message filter), he kindly reminded me that I'm a developer, and these kinds of builder interfaces
appeal to developers. I think there might be some middle ground, however, and the builder interface
concept could work with enough contextual guidance. I'll finish up my mock up of the builder UI and perhaps we can get some input/votes from some non-developers teachers and admins on the two UI options.
My proposal works better if you want to allow 'course completion rule' plugins. Of course, you need the choice of aggregation rule somewhere on the page too. It would also let you have the notifications information on the same page, rather than a separate tab.
I like the idea of allowing 'course completion rule' plugins! I hadn't considered that, and go about adding that to the code structure proposal.
I struggled a bit with how to add in the aggregation rules to the UI, and visually represent the aggregation scheme across the enabled criteria. I'll put more thought into it, and when I've got the mockup done, I'm sure a lot input from the community will help.
3. "Units" is not a good name for that aggregation rule. "Set number" might be better. And it could be "Proportion" instead of "Fraction".
Those are actually aggregation terms in the proposed Draft Standard for Learning Technology - Simple Reusable Competency Map, which is of course still a draft standard. They might make sense for use within the schema, but--I agree--not for the UI. Perhaps "Percentage" is better than "Fraction."
Do you mean let the UI directly set the 'moodle/course:markotherscomplete' capability for each listed role? That would make it easier for a course creator. Otherwise, s/he would need to go to the course role overrides page to set the capability for each of the roles in the course.
4. "Manual completion by" should not have a list of roles with checkboxes. It should use a 'moodle/course:markotherscomplete" capability.
I agree "Manual completion by" should be a capability and not a separate setting. I was thinking that the checkbox would set the capability, but--agreeing with you--it would probably be much better to make the actual function being performed explicitly clear in the UI.
Setting a capability in a UI other than existing role UIs seems unprecedented to me. If we were to go that route, I think it would be best to make UI for that fieldset are look/feel consistent with the current roles UIs.
5. Using the user context to let people outside the course mark someone as complete seems unprecedented to me. I'm not saying it is bad. Actually it is good. Just need to think if it opens a can of worms ... no. I don't think it does.
I can't yet think of a case where it would cause an issue either.
6. Why does the screenshot under "Completion progress report" seem to show some course completion columns on the left and some on the right?
Good point. They should probably really be all on the right of "Activity completion". There weren't any great reasons why any of the course completion criteria be set before all activities. I've updated the screenshot to show the new positions.
I think it might also make sense to remove the "Mark complete" column, and add the checkboxes under the column heading of the role of the user viewing the report (if obviously there is a "Manual completion by" criteria for that role. For example, when a teacher views the report, the "Teacher" column heading would appear as "Teacher (mark complete)" and the column would contain either a checkbox or a check icon (the checkbox if the student hasn't been marked complete by a teacher in the course/group; the check if the student has already been marked complete by a teacher in the course/group.
Just a side note: I also added a "Select all" and "Deselect all" buttons (consistent with other Moodle UIs) to the screenshot.
I'll update the spec with details about code structure asap.
7. Also, I would like to see some details of how you will structure the code, will completion criteria be modular in some way? Making them full plugins might be overkill, but will, say, each type of criterion be a separate subclass of a course_completion_criterion base class? What will that classes API be like? Will it be easy to add another one?