Paged course formats

Paged course formats
Project state
Tracker issue	TBA
Discussion
Assignee

Moodle 2.3

The following features are arranged in stages. What we can't finish for 2.3 can be done for 2.4.

1. Implement paged sections

The goal here is to avoid "scroll of death" for large courses by allowing teachers to display each section on its own page.

New course setting

A. Add a new field to the database called mdl_course.coursedisplay to store the teacher's preference.

B. Add a new setting named "Course display format" to the course setting page for this field with two settings:

Show all sections on one page

exactly as things are currently, and will be the default setting

Show one section per page

will abbreviate the course page to a list of links to individual sections

Further options can be added later, such as an "accordion-like" option.

Update core formats: Weekly and Topics

All course formats can choose to obey the new setting as they like. We'll be making sure core formats use it properly straight away, of course.

Main course page

The main course main page will show the General section (section 0) with a nicely-formatted list of sections below it with the current one highlighted. For each topic/week there is:

• the section name (as a link to the separate page, i.e. course/view.php?id=12&topic=3 or course/view.php?id=2&week=3)
• the section summary (truncated if it’s too long)
• a completion summary (if applicable, 1/3, 30%, ?)
• controls to hide/show that section, as usual
• Ajax (or arrows for non-JS) to change the order by dragging

The "zoom" boxes that control ‘Show one/all weeks/topics’ are no longer needed and will be removed.

More sections can be added by a big "plus" icon at the bottom, and old ones can be deleted if they are empty.

Section pages

The section pages should be seen as "sub" pages of the course page and can have their own blocks. (If this is too difficult initially then we can just re-use the course blocks on all section pages).

The navigation bar should show the section name as a sub page and be selected. It's easy to "go back" one level to the main course page.

There should also be nav buttons in the top and bottom of the page:

< [Previous_section_name] ^ [Course_name] [Next_section_name] >

Otherwise the section is displayed as normal, very similar to the way a one-section course displays now (except without section 0).

Other related changes to the code

Get rid of user setting for course display

There is no longer need in per-user setting to show only one section in the course (it confused people anyway). Remove the control, delete function course_get_display, course_set_display and their usage, DROP TABLE mdl_course_display

Check for regressions in modules caused by course assumptions

For example, make sure that "return to course" actually returns to the appropriate section. Forum module does something like that when you add a new post from the Latest News block. Also editing module settings has a "Save and return to course" button. etc.

2. Extend course settings with format support

Add a new form section after ‘General’ in the course settings page, named ‘Display options for Weekly Format’ (or whatever format is chosen).

If case of Javascript enabled this form section is reloaded when course format is changed. Otherwise the user will have to press a refresh button to refresh the display options for the current format.

Each course format defines which display options it needs. For the standard course formats they are:

   weeks: numsections, startdate, hiddensections, coursedisplay
   topics: numsections, hiddensections, coursedisplay
   scorm:
   social:
   default: numsections, startdate, hiddensections (current behaviour)

Each course format may override label and/or help text for the elements and specify the types and rules for the elements.

Also there is a hook allowing course format to validate the fields it's added to this form (see part 3: OOP)

3. Course format refactoring

We will refactor the course formats to support a proper object-oriented design and full support for renderers.

New classes

Course formats must be classes inheriting base class format_base instead of the current collection of callbacks. (Although some callbacks will be converted to static methods)

• Method course_get_format($course) will return an instance of the this class for the particular course. Since $course is a DB entry we can’t declare methods within it.
• Method format_base::is_setup_completed() returns boolean. If setup is not yet completed, course/view.php will redirect to course/edit.php
• Method format_base::default_blocks() is to replace config.php with $format[‘defaultblocks’]
• Method format_base::form_fields() defines fields to be used in edit course form
• Method format_base::form_validation() performs additional validation for edit course form

Base (default) implementation of functions in format_base check for existing callback functions (Moodle 2.0 - 2.2 style) and calls them (also includes format.php and/or config.php). In this case developer-level warnings are produced. But this way Moodle 2.0-2.2 course format plugins will still work in this new system.

Renderers

Course API defines two renderers:

course_renderer controls output used in course/view.php: hidden form for AJAX, functions including javascript libraries, etc.

class format_renderer_base is the base class for course format renderers. It overrides or uses the functions from course_renderer the same way as plugin_renderer_base deals with the functions from core_renderer (so each class can be overwritten independently in theme). Also it is to make sure that if method render_format_FORMATNAME() is missing, the format.php file is included (for backward compatibility)

Each course format shall define its own renderer inheriting this one. But if the renderer is not defined in plugin, the course API will use an instance of format_renderer_base

course/view.php invokes a renderer for the current course format (or if course format does not define renderer)

See also http://tracker.moodle.org/browse/MDL-10265 Javascript and AJAX YUI3 is to be used instead of YUI2.

• .init() should be called correctly with correctly passed strings

class jsportal (AJAX) should be substituted with up-to-date coding style

4. UI improvements for course editing mode

The goal is to make interface more user-friendly and get rid of ‘Editing mode’ when Javascript is enabled.

Adding activities and resources

The drop downs for adding activities and resources can be united and shown as a nice window (in the left part of it). When user hovers over the activity/resource name, they help for this action appears in the right part of the window. If JS is disabled there could be a current behaviour but a return to a better help icon containing help for all activities/resources listed.

Add a user preference controlled by link/button in UI to switch between old-style menu (for expert users) and this new-style pop up (as default, for new users).

Add support for drag and drop straight into the course page. See Course drag and drop upload and MDL-22504.

Action icons

1. Clean up the way they look. Sizes/order/position and alt tags all need to be consistent. New, larger icons.

1. With JS on, only show the icons when hovering over associated activity.

See also

• Talk:Paged course formats