Re: Teachers

["Alexey Parshin" <alexeyp@gmail.com>]

I'm totally confused at that point. The current implementation allows to define a difficulty level per UMO. It means - DL may be defined for any topic, not just for TLT.
BTW, if we want to switch anything in the interface based on the difficulty level, I suggest that community part of the difficulty level should not be considered for this.

I still don't understand how we can change anything in the interface based on the optional community votes. For some people, for instance, a Molecular Psychics is something extremely difficult, but for a few it is not. The community DL would, in such situation, depend on who voted. If the advanced students vote more often - then we have lower DL. Consider, also, a possibility to kid the system when a group of people decides to vote for some UMO as 'extremely difficult' or 'extremely easy'  - just because they are having fun.. The value of such vote is, practically, zero.

2006/12/16, sergey@total-knowledge.com <sergey@total-knowledge.com>:

Alexey, nevemind this question

> Let me clarify.
> TLT may have different sets of subtopics based on difficulty level, since,
> as we agreed finally, that difficulty level will be bound to a TLT.
> Please take a look at this page:
> http://gateway.total-knowledge.com/~sergey/UU/CourseView1.html
> User can choose dificulty level from dropdown and see different list of
> subtopics that linked to the chosen difficulty level. It may look
> different on UI in life version, but the idea is the same.
> I may be wrong, but I can't see how this functionality handled in your DB
> schema. Am I missing something?
>
>
>> Well, I meant TLT, not a Course as an administrative unit.
>> I may miss something in your schema, but imho you should have something
>> like topic_to_tlt relation table containing "difficulty" column that has
>> relation with difficulty_level table in similar way as it's orginized
>> for
>> problems, for example.
>> Regarding the name, I think it maybe changed since users can study
>> course,
>> not UMO Course.
>>
>>
>>> I'm not sure if we are talking of the same thing. Study_course is an
>>> administrative object, currently for course-wide permissions and
>>> payments.
>>> It refers to top-level-topic (TLT) that is a course. Now, TLT has the
>>> difficulty level, content, etc.. May be, study_course isn't the best
>>> name
>>> for the object?
>>>
>>> 2006/12/16, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>>>
>>>> If i understood it correctly, we agreed that difficulty level should
>>>> be
>>>> bound to a Course. Imho it's reflected in the latest DB schema.
>>>>
>>>>
>>>> > I have added study_course, study_course_acl, and
>>>> study_course_payment
>>>> to
>>>> > support our discussion results.
>>>> > However - I'm not really sure if the relation between topic (TLT)
>>>> and
>>>> > study_course is right. Currently, top-level-topic owns course. The
>>>> > alternative is - course owns all the topics inside.
>>>> > Also, I'm not sure yet how to control access to payments.
>>>> >
>>>> > 2006/12/14, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>>> >>
>>>> >>
>>>> >> >>
>>>> >> >>> 3. Assign Course or any other UMO within a Course to a Student.
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> What that means? Recommendation or administration? If latter -
>>>> see
>>>> >> >> above.
>>>> >> > I'd like to know that too :)
>>>> >>
>>>> >> For example, assign a Problem to a Student
>>>> >>
>>>> >> >>
>>>> >> >>> 4. Set grades(ratings) to a Student.
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> Same story. We don't have grades in specs.
>>>> >> > We do have some ideas at least as far as grading problem solving
>>>> goes.
>>>> >> > Most of it is automatic, but at least some is human-controlled. I
>>>> >> don't
>>>> >> > care too much about grading abilities, but we'll need it
>>>> eventually.
>>>> >> We
>>>> >> > need better definition though. Or at least some definition, since
>>>> >> there
>>>> >> > really isn't anything specific in the spec.
>>>> >> >>
>>>> >> >>> 5. Assign Students to certain difficulty levels within a
>>>> >> >>> Course.(Student
>>>> >> >>> will be able to see only UMOs of certain difficulty level)
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> All the same. It is all for student's discretion as of today.
>>>> We
>>>> can
>>>> >> >> probably think about some specific channels where students can
>>>> find
>>>> >> >> recommendations not from teacher only. I am not sure there is
>>>> need
>>>> >> for
>>>> >> >> this. We can discuss it though.
>>>> >> >>
>>>> >> >>> 6. Ability to change any UMO difficulty level within a
>>>> Course(No
>>>> new
>>>> >> >>> version should be created)
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> np
>>>> >> > No. Difficulty levels are author's responsibility.
>>>> >> >>
>>>> >> >>> 7. Sets the price for a Course
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> It is necessary feature. I believe we have it in specs.
>>>> >> > Teacher or Author?
>>>> >>
>>>> >> Teacher sets the price, students buy it. Author? I don't know how
>>>> >> authors
>>>> >> make money, maybe teachers buy courses from authors then sell it to
>>>> >> students? No need to teach anything, just make a couple of
>>>> transactions.
>>>> >>
>>>> >> >>
>>>> >> >>> 8. Chooses his prefered language(s) for the Course from the
>>>> list
>>>> of
>>>> >> >>> available languages for this Course.
>>>> >> > Preferred for what? Expand on this please.
>>>> >>
>>>> >> I mean his language(pl_preferred_language column in person_list
>>>> table).
>>>> >> Course may have several languages available, Author selects the one
>>>> he
>>>> >> speaks. You don't want, for example, students send an Author
>>>> problems
>>>> >> solutions in language different from the one he speaks.
>>>> >>
>>>> >> >>>
>>>> >> >>> 9. Ability to hide(not update) from Student certain UMOs in the
>>>> >> Course
>>>> >> >>> that he teaches.
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> Don't need it. Actually, there is one more issue here postponed
>>>> for
>>>> >> >> future versions: work flow. It relates to administration, but
>>>> not
>>>> >> >> entirely.
>>>> >> >
>>>> >> > --
>>>> >> > Ilya A. Volynets-Evenbakh
>>>> >> > Total Knowledge. CTO
>>>> >> > http://www.total-knowledge.com
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Alexey Parshin,
>>>> > http://www.sptk.net
>>>> >
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Alexey Parshin,
>>> http://www.sptk.net
>>>
>>
>>
>>
>
>
>

-- 
Alexey Parshin,
http://www.sptk.net