[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Difficulty levels
Anatoly Volynets wrote:
> Once again, there are two unrelated issues in one here:
>
> 1. An UMO difficulty level (DL) in the Repository, which is set by
> community voting (probably by authors and students - this is to be
> discussed)
Let's set community votes aside from this discussion for now. They are
extremely
easy to implement, if we bind them to separate UMOs. All we need to do
is decide
what goes on a ballot, and what scale we allow for each. We may even
come up with
generic interface, that can be managed dynamically at run-time.
> 2. This same UMO DL in the course or among courses by the same Author,
> set by the Author.
It seems that common consensus is that object DL should be bound to
course. I guess
we'll go with it then.
>
> This is why I incline to have two part DL mark: n-m, say n - stands
> for the Repository DL, and m stands for the DL set by the Author.
>
> n,m are integers, starting from 0.
And ending in ... ?
Or do we let authors set arbitrary numbers? I don't think that'd be good
idea though,
since this will sort of defeat purpose of difficulty levels (as stated
in my original email).
My current inclination is to go with range of 0-10 (or 1-10, since 0
presumes it's not a
problem at all :), and no names - this will let people use somewhat more
neutral measurement,
and not force someone into solving "problem for dummies", thus
alienating them from
our application. Besides, with any range that has more then 5 options,
naming will become
difficult :)
>
> We probably need to foresee a situation when somebody discovers a
> problem, which is easier to solve then one of DL =0. Any suggestions
> about that?
This is back to voting part. Separate issue.
>
> Regarding any additional functionality (like work flow) that can be
> derived from DL, I would leave it for next UU versions.
There is no need to bind workflow to difficulty levels. There are (or
rather will be)
other ways to achieve the same functionality, without overcomplicating
our application.
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com