(→Tools to make turning multiple courses into one) |
Current revision (00:57, 13 October 2015) (view source) m (→Business Assumptions) |
||
| (2 intermediate revisions not shown.) | |||
| Line 397: | Line 397: | ||
An UMO of the course level. It is a collection of different UMOs based on their contents and ideas they implement. Juxtaposition provides a possibility for in depth studying and understanding of fundamentals in any area of human activities. It is more a research than instructional tool. Juxtaposition provides subject for dialogue and provokes it, in the first place, while learning comes in as a side effect. | An UMO of the course level. It is a collection of different UMOs based on their contents and ideas they implement. Juxtaposition provides a possibility for in depth studying and understanding of fundamentals in any area of human activities. It is more a research than instructional tool. Juxtaposition provides subject for dialogue and provokes it, in the first place, while learning comes in as a side effect. | ||
| - | === Required | + | === Required Properties === |
*Author(s) - every person contributing to the collection. | *Author(s) - every person contributing to the collection. | ||
*Basis for collection, that is a non-empty text, a formulation of an idea. | *Basis for collection, that is a non-empty text, a formulation of an idea. | ||
| Line 881: | Line 881: | ||
= Business Assumptions = | = Business Assumptions = | ||
| - | UU is a Software as Service which is supposed to work | + | == UU is a Software as Service which is supposed to work as an Open Server == |
<OL> | <OL> | ||
| Line 901: | Line 901: | ||
== Proprietary Server == | == Proprietary Server == | ||
| + | * The role of the Proprietary server is in discussion. Our thinking was to contrast two servers in order to prove advantages of the open one. Still, we are not sure we need a proprietary server at all. For the moment it is thought to be as follows: | ||
| - | * An author can create here a "closed | + | * An author can create here a "closed" course, which means that neither course, nor any of its objects can be used by another author without the creator's permission. |
* The Proprietary Server is a paid service. | * The Proprietary Server is a paid service. | ||
| - | * If an author copies a course from the Open Server on the Proprietary one this does not affect in any way the prototype or its usage on the Open Server | + | * If an author copies a course or any other UMO from the Open Server on the Proprietary one: First, this does not affect in any way the prototype or its usage on the Open Server; Second, all proper attributions to the open prototype are enforced. |
| - | + | ||
| - | + | ||
| - | * Any object created at the | + | * Any object created at the Proprietary Server can be removed by its author at her own discretion. |
Universe University. Specifications for Web Based Educational Environment
Contents
|
Universe University (UU) aims to address the core demand to the modern education: development of independent and critical thinking, creativity and responsibility. However, the general technology of the contemporary schools go back to the 17th century and is directed to informing and skills' training only. That is so for the more than 300 years, while critical thinking is mostly up to a teacher, or better say, up to a good teacher. The question is whether personal efforts of a teacher to provide for creativity development and general educational technology to inform can work in concert?
First, knowledge and creativity as such are not one and the same. They can relate in one process and go away in another. Let's see how that works in the history and philosophy of the existing school:
It is noteworthy that in above described mechanism all elements are logical. They fit the fundamental understanding of knowledge and one another! The above described construction is essentially the same for the great majority of mainstream schools worldwide. They may differ in details but not in essence.
It is evident that objectively this construction and corresponding technology do not promote development of independent and critical thinking, creativity and responsibility. These could be, as we mentioned before, provided by a teacher, individually.
However, those up-to-a-teacher features, despite being in major demand, cannot normally work against the entire system. They can only work despite the system, against it. Worldwide experience for centuries tells us the same story all over: Educational innovations either get swallowed by the school, digested and turned into yet other forms of informing and training, or they bounce against the wall, break up and get thrown out. No other outcome of educational reforms and innovations could be observed since 19th century in any part of the world.
Hence, our understanding is that modern school has to be wholly reconstructed bottom up, so that the entire system would aim directly to bringing up independent and critical thinking, creativity and responsibility. Moreover, we believe that in such a school, knowledge will be acquired along and it will be acquired willingly, deeper and more intensively than within any current system.
There are several fundamental ideas a new school can be built on. The most promising, in our view, is dialogue. Dialogue theoretically and in practice proves to be a foundation for independent and critical thinking, creativity and responsibility.
There are two "modes" of dialogue: dialogue as inner speech, which actually is thinking (Plato: "thought is the silent and inner conversation of the soul with itself") and dialogue as free communication between humans.
In short, that works as follows: If someone has to explain something not understood by another one, that requires to find a way to overcome misunderstanding which infers creativity.
The creativity is also needed for the listener, who is trying to understand. If the listener is not just to remember what is explained but to understand, that requires to recreate the subject anew.
Creativity, in turn, requires answers to not-so-evident questions, that is, requires independent thinking. One pulls another in. And if we make a step back to the goal of the conversation when I, who tries to explain something, need to understand what exactly you do not understand in my explanation, we already in the realm of critical thinking.
What about responsibility? It is also here because if I am looking for the right argumentation that means I took upon myself responsibility for it. Another face of responsibility shows up in the very beginning, it is for my interlocutor. If I haven't taken the responsibility for her I would not even started talking! Remember, we discuss free communication.
All that said easily translates from discussion to thinking. In thinking I am responsible for myself to move from hypothesis to certainty, from fantasy to idea, from opinion to understanding. I need to be creative to come up with these starting points and very critical about them and myself so that not to be satisfied with opinions, fantasies and hypotheses but proceed to understanding of the truth and reality.
That is why we take dialogue as the central idea and the core feature of UU. In order to provide that we develop several unique features and are going to utilize many available tools developed by others and useful to this effect.
Beside many UU features we want to emphasize the following in respect of the ideas of the dialogue and whole educational technology:
UMOs are main building blocks of UU. Courses, Topics, Problems, etc. are all types of UMO. An UMO may include other, child UMOs.
To be created an UMO requires the following properties:
A published UMO has also a date of publication. A publication date is set when UMO is published that locks UMO in the published state.
Sharing within UU is to provide open source aspect of the environment. That is, different people may participate in UMO construction, bringing in different approaches, stand points, understanding of a subject, and so forth. On the other hand, all UMOs can be used by other authors and teachers for any purposes, given the proper attribution is done (the latter is technically enforced). Authors, who are not inclined to work in cooperation with others, can do it alone.
SoA says what this object is in terms of authorship:
It includes the time stamps of its creation and publication if it is published.
An UMO may exist in several versions. New version is created whenever author publishes new edition of the UMO. In this case existing UMO versions stay. The author can mark new version as minor or major edit. Users of the UMO decide whether to upgrade it or not. When linking objects to each other (e.g. adding a problem to a topic) author decides which version to use. The new version of UMO keeps the original UMO title, content records, administrators and editors groups. The user that creates a new version becomes that version's author.
Course is a UMO which represents collection of other UMOs, and which allows classes to be signed up to it. The only way to study an UMO in UU is to sign up for some class, which is signed up for a course, which contains the said UMO. What if a user wants to study a course by self and thus doesn't want to sign up to existing classes? For that case UU produces a default class for this course, actually invisible for that user. (S)He signs up for self-studies. The "self-studies class" functionally doesn't differ from regular classes. Only human (teacher) controlled problems are not guaranteed to work although UU communication environment makes needed help quite probable. [Actually, we can think of teachers for the default class too. It'd be just opposite direction of relationship: in regular class teacher looks for students, while in the default class a student looks for teachers, volunteering consultants which could differ for different problems]
Topic is main structural object of a course. It allows course authors to organize other UMOs for presentation to students. Topic can contain subtopics, explanations, tests, exercise problems, etc. Basically any UMO except for course can be linked as a child to a topic.
A topic can be published if at least one explanation is supplied by the author
Each topic can have number of explanations. In this case, each explanation has some unique number, which reflects order to show explanations in explanation list for the topic. This number (together with difficulty level of explanation) will also affect which explanation is shown to a student by default. Note that both sequence number and difficulty level of given explanation are tied to the topic that includes said explanation, not to explanation itself.
An author may write his own explanations or include chunks of classical texts. He may neatly explain some subject, ways of problem solving or make a discourse around a topic, research his subject instead of explaining. A author may make just one explanation for a topic, which is traditional way to build courses. However the app allows to build unlimited number of parallel explanations.
This feature may be used to provide:
Number is really associated with Topic, not with explanation, as an explanation can be shared between different topics.
1. Single Answer
Student is presented with a problem statement, and a single one-line field, where (s)he has to type his answer in. Student's answer should match the correct answer (match can either be case-sensitive or case-insensitive, and it could be simple text, or a regexp)
2. Multiple Choice
Student is presented with a problem statement and a set of choices. Choices can be either radio button set (in case only single answer is allowed) or a check-box set (in case more then one answer could be correct). In case of multiple correct answers, problem creator may specify whether all answers have to be checked for solution to be considered correct, or if any of them will suffice.
3. Template
Student is presented with a problem statement, and a problem solution with blanks, which (s)he has to fill in. Each blank should match.
4. Generator driven full control:
a) Semantic Model
b) Custome/Language Driven Control
5. Human controlled
A student solves a problems and passes the solution in a required form to the teacher that, in turn, passes comments to the student.
It is a number, starting with 1, incrementing by 1, but can go in opposite direction as well: 0, -1, etc.
There must be an ability for an author to implement some educational scenarios comprising instructions or procedures to folow by a student or group of students. It can be based on different psychological foundations and / or the author's experience.
5 randomly generated problems would represent a particular test. For test problems only time allowed should be specified. "PASSED" or "NON PASSED" grade should be assigned. Points for "PASSED" grade should be specified for each test. In order to get "PASSED" grade 6 times allowed to take a test. The rate score ( RT ) should be assigned to each student after successful completion of test. (based on the time deduction principle, 10 sec = 1 point) RT is a function of only time specified for the test. In the case a student has RT not equal to zero, the system will let him/her to solve the general problems to improve their regular rating.( but only within this particular topic)
A competition can be set on any collection of UMOs.
A game or exercise may be included by the author in the course or topic for different reasons. It is not controlled in any way.
An UMO of the course level. It is a collection of different UMOs based on their contents and ideas they implement. Juxtaposition provides a possibility for in depth studying and understanding of fundamentals in any area of human activities. It is more a research than instructional tool. Juxtaposition provides subject for dialogue and provokes it, in the first place, while learning comes in as a side effect.
The Points and Relationship technically forced into a syllogism like structure: <Point 1> & <Point 2> => Relationship.
A piece of text.
A user can create a custom UMO, which cannot be structured, but can have all general UMO features. Custom UMO can be included as a child in any other UMO
Universe University has to be accessible and functional on different languages. There are two important aspects of localization to consider
Locality to use when rendering objects and UI to users will be negotiatable using standard HTTP content-negotiation protocol, but will be forcable through personal user settings.
We will (probably) use gettext system for translations. .po files will be (as everything else in our Open Source application) pubic, and translations will be contributed by interested users.
There will be special role: "translator". This person will be listed as such for given object (along side with authors). Translator will have full editorial access to translations of object for his language, but will have no administrative rights. There will be standard set of tools for creating and editing tranlations of object.
Object tranlation does not constitute a separate version. When translations are added/removed/editied, they are implied to be a minor edit. Translations will have their separate "publish" flag though, to avoid making an unfinished translations visible, when working on an object which main language was already published.
When editing a translation, a separate, temporary copy is created, and that copy is the one that work is being done on. It can be saved across editing sessions. Once it's ready, translator will "publish" it, at which time this copy will replace any existing translation for given version of given object in given language.
A Host of an instance of the Universe University has tools to develop and enforce certain policies regarding contents and other features of courses and other objects created and offered to the general public at the Hosts' servers.
Access to objects in UU is granted to "ACL Groups". ACL Groups is just a group of users. Membership in ACL groups is controlled differently, depending on what the group is used for.
Class is a special object, which is used to give users ability to study courses. Class itself doesn't support versions. It has three groups associated with it:
When class is signed up for a course, class'es "Students" group gets Study access to the whole course UMO structure (that is all subtopics, explanations, problems, etc.). In order to pass the class, a student must pass all the UMOs that class is connected to.
Different groups may be granted different permissions on different UMOs.
Members of a group with EDIT access to an UMO can perform following actions:
Members of a group with TRANSLATE access to an UMO can create new translations for that UMO, as long as version in unpublished state exists.
Members of a group with VIEW access to a UMO can get a preview of the UMO. What is displayed depends on type of the UMO.
Members of a group with TEACH access to a classe can "teach" it. This means following actions are allowed:
in all course-related communication tools for this class.
Members of a group with ADMIN access to a class can perform following actions:
Members of a group with STUDY access to a #Class can have following properties:
Authorship and appropriate credit concepts are extremely important. UU handles it in the following way: Each UMO has authorship info associated with it. By default author list is comprised of all people who made any modifications to an UMO. However, in some cases it is not the right thing. For example, someone may decide to publish someone elses text book as a course on UU. In such case the published is [b]not[/b] the author. To accomodate this, UU allows UMO administrator to specify author list manually (once it's done, author list has to be kept up to date by hand).
There is still access to lists of app people who did modifications to UMO, as well as separate lists for translators.
In addition, there will be "history" page, which shows UMO modification history, along with contributors to each modification.
a) An author can set up payment for a students on per course basis with a drop-off grace period. b) In this case the author has choice of payment to UU either
c) No other transactions (except for sponsorship) are possible respecting Open Server
d) Flate rate service charge is added to any author on Proprietary Server
It is the repository of all created objects ever. UMO gets automatically from a course into the Repository or can be created specifically for the Repository.
All of above repositories will be presented to a user as catalogues. Catalogues themselves are browse-able tree-like sets of categories [1] based around subject matter and also based on UMO authors. While browsing, user is allowed to filter out visible objects based on following criteria:
User will also be able to specify any combination of the following sort criteria (both increasing and decreasing):
Administration of catalogue categories is performed by users from a special "catalogue administrators" groups. Each category in catalogue has such an administrative group associated with it. Members of group controlling higher-level category are automatically allowed to any category in the sub-tree.
Example:
Math (user1) | +-Algebra (user2) +-Geometry (user3)
Following administrative tasks will be allowed:
This will hide the category from catalogue and from UMO author UIs for association of UMO with categories. Any sub-categories of the hidden category are also hidden, recursively.
Any sub-categories are also unhidden, recursively.
This one is for moderating categories (e.g. if UMO is being spammed to too manu categories in catalog, which it doesn't belong to)
Category search by the parent category also includes any sub-categories for this category. For instance, in the example above, search results for search by the category Math would also include UMOs from Algebra and Geometry categories.
There will also be an external tool (probably command-line) for permanent removal of categories from the database. It's intended for use by UU instance administrators, in cases where a category was created erroneously.
This is repository of shared objects with high ratings. Formulae for object ratings are TBD. Following categories to be provided, each may having a different rating formula.
Items from the General Storage move up into the Featured storage by getting rated.
Stores submissions disapproved by the Masters Board
It is a wikipedia-type board comprised from authors and experts to determine where a UMO belongs. Reviews automated submissions and special submissions.
Each entity in course can be included into any other course or linked to some other places, subject to attribution to authors and sources.
May include tools for analyzing tree structures, and pointing out similarities to authors, etc.
Simple features to make sure no conflicts are created during simultaneous work on courses.
Every object will have versioning history. Version is created every time an author indicates that this text is ready for inclusion. Until that time any changes are saved, but are not visible to anyone but authors.
Other users of the object get notified the object has changed. They can choose to upgrade the object or leave it as is.
If a user of a object edits the object or builds a new one upon the used one it is up to this user to consider himself an author or an editor. In any case everyone using the original object gets notified and the new or edited object bears its history: which object it is built upon.
1. Voting: on courses, problems, authors, messages, etc.
2. Functional: on people, chess mastership type rating
It is a function of:
1. Fact of growing
2. Level of difficulty of problems
3. Frequency of participation
4. A single problem solving time
5. Rating of courses taken
6. Other factors
It is a function of:
1. Should be around 50 for every topic in the course.
2. Points for the problem - N (m, k, l, p), where m - the level of the course ( 0 < m < 3); k - the number of the theme within the course; l - the level of the problem ( 0 < l < 4 ); p - the number of the problem within the course ( 0 < p < 50).
3. Correspondence: 0 < N ( m, k, 1, p) < 40; 40 < N (m, k, 2, p) < 65; 65 < N ( m, k, 3, p) < 90; 90 < N ( m, k, 4, p ) < 100.
4. Rating RG is a function of average amount of:
5. Points of the last five problems chosen,
6. Overall points,
7. Deductible points,
8. Levels of courses and problems taken,
9. Communication,
10. Activity.exercise
E-Bay style rating of any UMO
Each entity in course can have set of publically viewable notes attached to it, that anyone can add to.
?The notes are moderated by?
Each UMO bears publically accessible statistics of:
1. Visiting
2. Attendance
3. Revenues
4. Rating
5. Participations/Results in/of within/out UU contests
6. Usage in other courses
7. Usage out of UU
TBD
1. All items in the lists below go with related "demographics"
2. All lists are cross referred
3. Lists