Below are answers to previous comments regarding levels of difficulty. > People, the issue of an UMO difficulty level is new for me, although it > sounds interestingly. We never discussed it in general terms and there > is just one spot in specs where it mentioned (as far as I remember): it > is blocks of problems within one topic can be of different difficulty > levels. > > Generally speaking, there can be different levels in one game. Surely, > exercises can be more and less difficult (one exercise on different > levels or different exercises depending on difficulty?). Courses can be > popular, say, normal, advanced, etc. Explanations are different as of > today, although they can differ on the basis of approach, but not > difficulty. Topics? - am not clear. Tests? - surely. What else? > > To sum up: we need to go through all UMOs and analyze them from this > stand point. Then we need to decide whether difficulty is a property of > the Study Object, or it is one for some objects only. From that point we > can proceed to our db and object diagrams. > > What do you think? > I think that level of difficulty should be a property of StudyObject and be available for all UMOs under a course. This is imho the simpliest and most generic way to look at proccess of study a course. For example, I 've been studying C++ for quite some time already and I have 2 C++ books right now(2 different levels of difficulty) - "C++ for Dummies" and Stroustrup's "C++ Programming". At this point I use dummy book with dummy topics(even topic titles are kind of dumn), dummy explanations, dummy problems and dummy tests. If I want an advanced level of, for example, an explanation, I'm not trying to find it in "C++ for dummies". I switch books(levels of difficulty) within the same course "Studying C++". > To this point. If we decide to have the difficulty property in general, > the very next question is criteria. My first guess is the following: an > Author can mark an UMO as one of the "next" or certain by number > difficulty level. UU is to follow up it by checking this author's UMOs > of the same type and to designate a number meaning difficulty level to > the UMO. These numbers are "relative", that is they have to be > correlated somehow with difficulty levels of the UMOs of the same type > throughout Repository. > An author creates levels of difficulty on Course basis, then for each child UMO he has an ability to create/update the UMO for any avilable level of difficulty(presented as a set of radio buttons on each create/view page in current HTML mockups). If an author wants to add an UMO from the Repository to his Course, he still we'll be asked to assign this UMO to one of the available for his Course levels of difficulty by selecting a radio button even if that UMO has it's own level of difficulty assigned to it by it's original author. > One more. Said correlation is, most probably, done by voting. Say, > community votes a problem block as difficult as "3". The author > designates it as the most easy to solve, level - 0. Its difficulty mark > then: 3-0. Something like this? > We have a UMO rating idea already, if a student thinks that the UMO belongs to a different level of difficulty, he/she gives this UMO a poor rating with comments. > Actually, the way I understood it, it supposed to be something like this: > - beginner > - intermediate > - advanced > - master > > If we keep it that way - the implementation and use are pretty simple.. > IMO authors should be able to create as many levels of difficulty as they like and be able to add/delete them at any time.
Authoright © Total Knowledge: 2001-2008