User:Akash Agarwal/GSOCideas

From WikiEducator
Jump to: navigation, search
  • Improvements in the Course Registration Flow : Currently the course registration scheme used is a widget which gives the user to optionally enter his Google plus id, twitter id and blog url. The Wikipedia Educator Programme on the other hand provides a single click registration without giving the user the option to enter details about his social connections. There are advantages and disadvantages of both schemes.
    • The WikiPedia Education programme offers a single click enrollment into a course and has a very good GUI. This is very convenient for the learner but then he may have to enter his blog url and other required stuff later.
    • The WikiEducator scheme asks the user to optionally enter his Google plus id, twitter id and blog url. This may not be required for most courses and would be a waste for time for users to add this information. But in some courses a blog url may be very essential, but it is not compulsory for the learner to enter the same.
  • The plan is to build a scheme where for each course the information that has to be compulsorily entered and the optional information can be customized. For a course which requires no input from the user in terms of microblog, blog, forum posts,etc one click registration using information already present in the WikiEducator user account would be the way to go. But, where there is a credit system and the learners need to write posts they course can opt for a requirement that a learners enters a url where he would write the posts. Also, the learners will be able to update the links to the blogs and microblogs whenever they want to.This is a requirement as frequently users enter the wrong url for the blog. For example, they enter the url for editing posts rather than the url for the published version. Or some of their initial posts may be in a different blog and they switched the platform while the course is in progress.
  • The following components will be added to the already existing flow.
    • A MW extension or a widget where the instructor can add some emails directly or upload a csv file. An email will be send to those on these list. If they have already registered with WikiEducator, they will be automatically registered for the course. Otherwise, they will be given a link where they can register for WikiEducator and the course quickly. This will respect the assigned roles within mediaWiki to prevent span. Only the users with the administrative rights (instructors in most cases) will be able to invite people to the course by adding emails or uploading a csv file. This will be done by using and updating the wgGroupPermissions array which is already available.
    • A simple and user friendly widget from where the educators can send an email to all the registered users of the course.
    • Pages which have E-activity register such as http://wikieducator.org/Open_content_licensing_for_educators/E-Activity_register are updated manually.This page will have an option to set it to automatic update mode in which the blog posts will be automatically added based on the url of the blog specified during registration. Users will also have the option of manually adding posts.
    • In the first phase of the project this will be done using using tags for specific activities. Users will have to specify unique tags for specific activities, for example, OCL4Ed1.1 for the first activity of the OCL4Ed1 course. The posts with the tags will be added to the list of posts for an activity.
    • In the second phase of the project this process will be fully automated using simple natural language processing techniques. Content from the blog posts for the blogs specified in the links by the learners, will be automatically parsed to predict the activity to which they are related. These posts from the blogs will then automatically appear in the posts related to that activity. This will be done by a WikiEducator bot user. It will eliminate the need to verify that the blog post relates to the intended question. Of course, the users will also have the option of manually doing it.
    • A consolidated view of the posts written by the learners. It will be an extension to the previous bot and will try to figure out what are the things that most users are writing about and show excerpts from them. This may also take input from the peer evaluation.
    • The instructor may set some more additional requirements for the course for example a word limit for a designated activity, the minimum number of blog posts required for an activity or a course. These processes will be automated and the course will have the option of adding these requirements and modifying them as per the requirement.
  • A course dashboard for the instructors:
    • A page where the instructor can see the feed from microblog, twitter, google plus as well as other activities undertaken by learners. Currently there is a microblog feed in some course but it needs to be optimized and other features built up into it.
    • A page with the consolidated report of the course. It will contain information like the number of people involved, the percentage of them active in the past week, the number of microblog,forum, blog posts by an average learner, highlights of some of these posts, etc.
  • Peer evaluation : A plugin, perhaps a MW extension which allows the peer evaluation of the various posts and gives credits to the learners.
    • There is a credit system in place where learners are given some form of credit for writing various kinds of posts.
    • They will also be given some credit for evaluating deliverance by other learners.
    • An activity will have a page where the posts can be peer evaluated. There will be an option to display the posts which have not yet been evaluated. The learners can then select a post they want to evaluate from this list and complete it.
    • The course can set the number of peer evaluations required for an activity. For example, an activity may require 2 learners to evaluate every post. The posts which have not yet been evaluated at least twice will then be displayed in the option in previous point.


Feedback and ideas

  • Currently, as far as I know, the Wikieducator scheme for registration is not packaged as a Mediawiki extension which restricts reuse across other MW installations. Packaging GSOC outputs as extensions would enhance reuse and strength of the proposal imo. --Mackiwg 23:38, 27 February 2014 (UTC)
  • I think it would useful to build in a step to review/compare the advantages and disadvantages between the WikiEducator registration scheme compared with the Wikipedia Education Programme to identify useful features and options for customising among different wiki projects. --Mackiwg 23:46, 27 February 2014 (UTC)
    • I have tried to do so --Akash Agarwal 23:36, 28 February 2014 (UTC)
  • More info on the blog harvesting during course: Rss of the posts tagged with the course code are automatically harvested for the feed - that is automated. The manual registration process is to identify / associate posts with designated activities. (One solution to consider for automation is to require learners to apply a unique tag for specific learning activities - eg OCL4Ed1.1). A simple validation process is need to ensure that the post relates to the Activity question (i.e. we do not require automated grading - but some scalable way to verify that the blog post relates to the intended question. I think we could automate some aspects - -eg a word count where a minimum word count is specified in the activity. It would also be useful to think about ways to scale peer validation. For example having 2 learners validate a blog post and some mechanism for assigning or notifying the blog posts that should be verified and what to do when a valid blog post is not peer validated.) --Mackiwg 23:58, 27 February 2014 (UTC)
    • I have improved on these aspects of my ideas --Akash Agarwal 11:43, 1 March 2014 (UTC)
  • I like the idea of a consolidated view of course activity - -useful for both learners and educators. --Mackiwg 00:08, 28 February 2014 (UTC)
  • The ability to populate a course with a csv file would be a great improvement to supplement self registration. We'll need to think about security issues (eg spam) possibly restricting mass enrolment features to assigned/trusted roles within Mediawiki. --Mackiwg 00:12, 28 February 2014 (UTC)
    • I have given a bit of thought into the security issues. One possible implementation is using the assigned roles already available in MediaWiki as a part of the wgGroupPermissions array --Akash Agarwal 10:54, 1 March 2014 (UTC)
  • I like the idea of incorporating rudimentary learning analytics -- that will take our project forward in the right direction. --Mackiwg 00:20, 28 February 2014 (UTC)
  • In courses which use blogs and micro blogs, users should be able to edit the urls they provide - frequently users enter the wrong url for example the url for editing posts rather than the url for the published version. --Mackiwg 23:47, 28 February 2014 (UTC)
    • And the course author has the option to select which fields of the registration form are required, preventing the problem This may not be required for most courses and would be a waste for time for users to add this information. JimTittsler 14:00, 2 March 2014 (UTC)
Retrieved from "https://wikieducator.org/index.php?title=User:Akash_Agarwal/GSOCideas&oldid=916013"