Timeline course format

Revision as of 11:45, 20 May 2009 by chris collman (talk | contribs) (Template)

Jump to: navigation, search

GSOC '09

Introduction

forum discussion

tracker issue

This is a project for Google Summer of Code at Moodle. I plan on adding a blog-style format for the course page as described in the project ideas wiki page, . I want to add support so that a course can have be really long if needed. The blog-style format would make it easy to teach a new class for the first time. The instructor could prepare topics 1 or 2 days ahead of time, add a topic for a specific day and list things that would be covered in a specific day. This project idea was requested by the OLPC teachers that found Moodle hard to use for their teaching style. The main audience for this module would be K-12 teachers.


Schedule of Deliverables

First trimester (20 April - 22 May)

  • Start discussion in forum to better define the scope, and requirements of the project (MEASURE: forum activity, DEADLINE: 20th April).
  • Gather information, feedback and advice from instructors and developers (MEASURE: wiki article updates, DEADLINE: 10 May).
  • Talk to Moodle developers in the mailing list to find out areas that can need to be handled with care (MEASURE: mailing list activity, DEADLINE: May 1).
  • Finalizing database changes and project plan (MEASURE: wiki articles created regarding project plan and updates on old documents, DEADLINE: 18 May).


Second trimester (23 May - 6 July)

  • Create needed database fields to handle extra long course (MEASURE: commit logs of sql code to add fields, DEADLINE: 20 May).
  • Write unit tests for the code (MEASURE: commit logs, DEADLINE: 1 July).
  • Work on course page (MEASURE: commit logs, DEADLINE: 25 June).
  • Get some users to test the course page (MEASURE: forum discussion and user tests, DEADLINE: 30 June).
  • Update documentation (MEASURE: wiki articles history, DEADLINE: 6 July).


Third trimester (7 July - 10 August)

  • Gather feedback from users (MEASURE: wiki articles created and forum discussion, DEADLINE: 8 July).
  • Work on user feedback (MEASURE: commit logs, DEADLINE: 15 July).
  • Work on testing really long courses to find bottlenecks (MEASURE: commit logs and test results, DEADLINE: 3 August).
  • Start discussion on forums regarding bottleneck issues (MEASURE: mailing list and test results, DEADLINE: 4 August).
  • Gather feedback on blog-style course page (MEASURE: wiki articles and forum discussion, DEADLINE: 6 August).
  • Work on user feedback (MEASURE: commit logs, DEADLINE: 10 August).
  • Write wiki articles and documentation on next steps and lessons learned (MEASURE: wiki articles, DEADLINE: 10 August).


Future Work

Allow archival of topics just like a blog would. Some users might find it useful to archive the parts of the course by month just like regular blog would.


Allow students to comment on proposed topics for a class. This might be useful when teachers hold study sessions or want to request student feedback on a class day.


Use more ajax to enhance the blog-style course page by reducing http requests and make the interface more responsive.

Allow students to be notified of changes in the course schedule. If the class requires a lot of hw or reading, it might be useful to notify the students when changes take place. This can save teachers and students a lot of time. The instructor doesn't need to notify students of changes to a specific day, and students get notified as soon as a change takes place and thus they have as much as notice as possible when hw are added or other things change.


Do more benchamarking. With courses that can last for a very long period of time, we need to worry about how to deal with more data. We should compare the performance of common tasks with a regular course page and a blog-style course page. If there are problems and limitations, how can we deal them without affecting performance.

More Information

For more information, please see the external links below: