[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Teachers
First, I disagree that votes should affect anything in the interface. The objects should be displayed as the author of the course designed.
Second, eBay voting doesn't work. Every time when you have a good transaction, you vote positive. However, if you have a bad experience, you vote negative, and always receive a negative vote yourself. So, if you buying rarely, not hundreds of items a year, it's easy to have low rating. That's the reason I stopped using eBay.
And third, in eBay voting, people are under pressure. They must think of consequences of their vote. The votes are public - you can always see who said what about the person. The votes are moderated - you can't insult people. Are we going to implement similar system?
2006/12/18, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
The only thing that may be change in interface based on DL
(and here it is irrelevant which DL we'd use) is order in which
UMOs are displayed.
Regarding all the considerations you are bringing up about voting
system validity, well - yes, they are there. It's hard to fight them.
I don't know if we really need to worry about them, and if we do if
we need to find mechanical/technological solutions to them.
If we look at eBay as an example, they don't have the problem.
Their solution is simple: all votes are reciprocal, and only those who
participated in transaction can vote. In addition there is aboard that
allows explanations of any mishaps, so when you are buying, you can
see any negative votes and reasons behind them. Overall it works very
well.
I am not saying we should be (or even could) going the same way - we
have different situation, that makes impossible to do reciprocal voting.
However, we could think in this direction.
Alexey Parshin wrote:
> 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
> <mailto:sergey@total-knowledge.com> <sergey@total-knowledge.com
> <mailto:
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
> <http://gateway.total-knowledge.com/%7Esergey/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
> <mailto:sergey@total-knowledge.com> <sergey@total-knowledge.com
> <mailto:
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
> <mailto:sergey@total-knowledge.com> <
sergey@total-knowledge.com
> <mailto: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 <http://www.sptk.net
>
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Alexey Parshin,
> >>> http://www.sptk.net <http://www.sptk.net>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com
--
Alexey Parshin,
http://www.sptk.net