[
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.
>
I agree with Alexey's disagreement once again. However, I think that votes
_should_ affect how interface looks, but it's up to Author and (I
emphasize) Teacher to actually change it.
It's been enough said about Students behavior already. Authors are usually
too sensitive about their creations, tend to love them no matter what,
won't be happy if somebody forses them to change it. I recently watched
some kid on the beach throwing sand in his mom eyes, then he tried to pee
on her head. I'm sure she will still vote that he is the best child in the
world, other people(including me) who sow it would have slightly different
opinion on this little bastard. That's the main reason I agree with
Anatoly on importance of community vote. I would just kick his little ass
and stoped these disgraceful goings-on. Unfortunatly it's not up to me or
community to change this child, it's up to his mom or his
teacher/counselor(if he grow ups and continue peeing on other people
heads, then (hopefully!) a community's vote will be taken into account and
this recidivist criminal will end up in the prison).
As I mentioned in my previous emails, in my opinion a Teacher is the one
who is the most objective in the evaluation of the quality or difficulty
level of an UMO. Let him change the Course he teachs.
1. Teacher has the Author opinion on difficulty level of the UMO(he sees
how Author structured his Course originally).
2. Teacher checks Students votes/rating on the UMO.
3. Teacher has his own opinion(based on his overall expirience, based on
level of the students he teach for this perticular course, his expirience
with this particular Author, etc..)
4. Teacher checks public profile of the Author.
5. Teacher checks public profiles of Students that voted, their scores,
ratings, marital status, whatever...
6. Teacher makes _his_ decision on this particular UMO difficulty level
for the Course _he_ teaches.
7.
a) Teacher leaves this UMO DL as it is, no changes at all.
b) Teacher reassigns this UMO to different DL within a Course
c) Teacher deletes(hides) it from his Students.
Now, the question is should we give a Teacher Author's rights, new version
of the Course will be created and the Teacher will become Co-Author? I
have no strong opinion on this.
> 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.
>
I see. You don't like low ratings. Me neither.
I'm sure that oversensative author hates them too. Why help an ignorant
crowd to bash him and change his creation using their negative
unsophisticated intelligence?
UU should support geniuses, not bring them down.
Yeah.
> 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
>
- Follow-Ups:
- Re: Teachers
- From: "Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>