learningequality / kolibri-ecosystem

A repository for tracking issues and new features for the Kolibri Ecosystem
MIT License
0 stars 0 forks source link

Improve completion criteria for content #18

Closed rtibbles closed 2 years ago

rtibbles commented 3 years ago

Outcomes

indirectlylit commented 3 years ago

General UX questions

  1. How will we communicate completion criteria to coaches and learners?
  2. Which aspects of completion criteria can be customized by coaches in the context of lessons?
  3. Do we really want raw times to be entered, or should we instead provide abstractions which might map to times as an implementation detail?

Some of these are elaborated on in-context below.

Terminology and existing behaviors

This isn't quite "custom resource duration". More like "custom time needed for completion".

Some details:

Specific questions

In Studio, users should be able to set custom resource duration

Studio should automatically set this to a default value for video and audio files on upload ... ricecooker uploaded video and audio files should also have their duration explicitly set

Allowing for user flagging of completion as sufficient for 100% progress recording

Would it make more sense for this to be set in coach lesson management than in Studio? (or possibly both)

Resolve extant issues around progress updating code

Needs references and clarification

rtibbles commented 3 years ago

How will we communicate completion criteria to coaches and learners?

No change as yet, consistent with existing behaviour. Additional work in https://github.com/learningequality/kolibri-ecosystem/issues/8 will start to display the resource duration information.

Which aspects of completion criteria can be customized by coaches in the context of lessons?

None - but this could be in scope in future work.

Do we really want raw times to be entered, or should we instead provide abstractions which might map to times as an implementation detail?

I don't think we have a good basis for these abstractions and would then require us to explain further. However, I think just asking for a whole number of minutes is probably the best medium.

rtibbles commented 3 years ago

This isn't quite "custom resource duration". More like "custom time needed for completion".

We are making this do double duty, as both the time displayed to the user for how long something should take, and also for estimating completion absent other measures.

Should users specify the time needed for completion directly, the multiplying factor (e.g. "minutes per page"), or some more abstract measure ("slideshow", "book", etc)? Making the selection more abstract might users choose reasonably time-frames.

Yes, directly. A whole number of minutes, any more finegrained and it is meaningless precision. Alternatively we could use some sort of expanding interval set: 1, 2, 3, 5, 10, 15, 30, 60 minutes.

Shouldn't we allow this to be overridden in the Learning Platform because time for completion is contextual to the lesson in which a resource is used, not absolute? (Granted that setting in Studio is a good first step.)

A good idea, but out of scope for this.

Why would we set a default value rather than continuing to use the built-in default behavior of the Learning Platform?

Because we want to additionally display this as metadata to learners to help them select appropriate materials.

Does this mean we need to back-fill all previously-published resources with default values?

Yes, eventually, although we should keep the fallback behaviour for now - see above for why setting these values is helpful.

Would it make more sense for this to be set in coach lesson management than in Studio? (or possibly both)

Both is definitely desirable, but the former is out of scope for now.

Needs references and clarification

See https://github.com/learningequality/kolibri/issues/2355 and https://github.com/learningequality/kolibri-design-system/issues/214 (for the latter, the timeSpent prop definition would allow us to stop making direct references to vuex state inside the renderers, which should be unaware of this).