SoD - is not solely Moodle's responsibility, in fact in my coaching experience, SoD is the often the result of building / growing a course, rather than designing with the end in mind, and then constructing a learning journey. The remedy more time investment. This is where, IMHO, the grid and onetopic formats are more effective than expanding and collapsing topics. How can the course creation "flow" enable improved course design?

Have I missed Moodle's ability to connect or condition courses together. I can not see if this point has been raised in the notes/discussion pages. Is the answer smaller but connectable courses? Is this indeed what the new format offers?

I apologise in advance if it is answers your seeking rather than more questions.

Sod - A section of grass-covered surface soil held together by matted roots; turf.

SoD - a poorly designed course that presents too many matted resources requires significant scrolling.

IMO, any proposal which preserves two separate week/topic formats is still halfbaked and should not be rushed into 2.3. But the proposed proposal is lacking in other respects too.

In a few days work I've created a course format with the following features and no core changes:

• Current indicator- can be set to either one of the following
  • manual (as in the Topics format)
  • daily (from course startdate)
  • weekly (from course startdate; as in the Week format)
  • monthly (from course startdate)
  • custom interval (from course startdate)
• Current per user - all current indicator intervals start from the user's enrollment date.
• Default section- the section that is displayed on first open (or no stored user preferences). Default section may be set to:
  • * Current section
  • All sections (all sections will be shown by default)
  • Any of the available sections
• Force default section - The page will always open on the default section (e.g. if the default section is set to the current section then the page will always open on the current section and will not allow other sections).
• Show Navigation bar - either to show or not show a navigation bar which defaults to the familiar jump menu + prev/next links. The setting allows to position this navigation bar top/left/right/bottom/top and bottom.
• Custom navigation bar - select a navigation bar format from available subplugins.
• Sticky sections - Selected sections persist on every course view page. This could be used for interesting effects. For instance if the first and last sections are set to stick each page will show a main section wrapped by a (sticky) "header" section and a (sticky) "footer" section.
• Delete sections - if you don't need it, delete it (from course_sections).

If I was able to do all that in a few days surely anyone in HQ could do it even better and faster, right?

Other concerns are with persisting usablility issues which seem to be constantly neglected in favor of ajax fireworks, in a system that is principled on "everything should work without javascript". It works alright but not really or not effectively usable. To take one example, the arrows for non-js changing sections order. When was the last time you tried to move a section 10 places up or down without ajax? I can jaggle the url to do that but how many other users can? A jump menu or even a clipboard approach would probably be more effective and that's just a minor code change.  

There are plenty of other things that could be improved but if we want to rush it, I think the above is feasible and could be a significant improvement.

I especially like the changes that simplify the UI and therefore believe strongly that the chosen course section should always be displayed (saving loads of clicks).  Essentially this would amount to an accordian format except the editing controls would be off the center column (an excellent idea).  Itamar's remarks are well conceived and hopefully will receive due consideration.

A note on the new course settings such as mdl_course.coursedisplay.

Format settings are not course settings and should reside in their own designated table. In some cases these settings in the course level (rather than the format level) are an unnecessary constraint. Thus for instance, there is no good reason for the constraint of one section on the frontpage, other than the fact that the frontpage doesn't have course adminstration ui.

Since I let my format manage the course sections (ignoring the numsections course setting) I can have more than one section on the front page! (by adding a few lines to index.php to check for the existence of the format and activate it if exists).

As a Moodle admin/trainer as well as a teacher who uses Moodle every day to design and deliver learning, I am really excited by the newly proposed Paged course formats spec.  As discussed this week in another forum, a work around to the "scroll of death" that some of us in the trenches have been using employs what is in effect a poor-man's version of 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)" feature the new spec proposes.  Having Moodle auto-build navigation links that display only one course section at a time (rather than having to create and link them by hand for each course as we have been doing) will make us very, very happy.  Thanks; we can't wait!

I would, however, respectfully like to suggest an additional core tweak that would further reduce the "scroll of death" and give teachers the opportunity to deliver learning in a more functionally and aesthetically pleasing way.

The "scroll of death" arises not only from the visibility of multiple course sections (the problem which the new spec address), but also from the fact that resource and activity links must appear in a single column list layout - the "Moodle laundry list" if you will.  The MML is not only aesthetically displeasing (the kiss of death in a world of users who expect Web 2.0 styling); it also limits the work flow functionality of Moodle.

It is currently possible to overcome the MLL by placing topic area content into a label and using tables within the label to define editable spaces.  Below is an example of using a label this way to shorten what would normally be a one column list. Note that all the links to resources/activities are really manually created links to the resources/activities because the resource/activity links generated by Moodle cannot be placed in a label.  The layout could, of course, contain graphics and narratives - all arranged in a layout (with or without table borders)  that the teacher feels will best speak to the student.

A downside to this approach is that to keep resource/activity links from appearing twice in a topic area, the original resource/activity links generated by Moodle must be moved to a different topic area (often at the bottom of the course's topic areas, or in an orphaned topic area).  Of course, handling the location of resources and activities in this manner creates problems (e.g. loss of student Profile report sequence accuracy, loss of Resources block report sequence accuracy). 

These problems would be eliminted if Moodle were modified to allow teachers to hide the displaying of resource and activiey links while at the same time keeping the resources and activities available to students via shortcut linking.  They could then leave the actual resource and activity links in their appropriate course flow locations hidden from student view, and provide links to them as they choose in the label layout they deem most functional and appealing.

All the best, and thanks to those who make Moodle possible,

Doug

First off, any change to the course format is a good thing. If the proposal got in as outlined in the screenshots, I'd pretty much happy. But it does not go far enough:

1. The distinction between topics and weeks should be removed. Some topics should be timed and other wouldn't. These things should be called pages or sections.
2. There needs to be a concept of a subsection so that a number of resources, labels can be tied together.
3. Within the subsections or at least a page, there needs to be some layout option. Kind of like the Panels module in Drupal. 
4. There should be more navigation options. Ideally, there should be a new course navigation menu that appears on the top of the normal navigation so that the section content is easy to navigate to.

 I blogged about it recently in these posts but there's been lots of other blogs about this (many linked to here and Talk page on the Wiki). 

• http://techczech.net/2012/04/10/5-moodle-2-features-that-waste-admin-time/
• http://techczech.net/2012/04/12/5-ux-improvements-moodle-needs-desperately/

Regarding AJAX, the consideration that has not been raised so far is accessibility. There needs to a good alternative for screen reader users. Either an option to turn off AJAX or use WAI-ARIA. We also still run into lots of IE6 and IE7 users in the UK - some schools and government institutions like prisons. But that will eventually go away.

Hi Martin,

Back in 2009-2010 at Sussex we ran an extensive usability review of moodle (1.9 at the time), and some of the changes your document outlines our the very ones we have implemented, so it’s great to see them making it into core, and hopefully we can help by sharing some of the challenges we faced.

1. Implement paged sections

One of the solutions to our users (students, admin & tutors) usability issues with moodle was a paged format which we developed and deployed - it has been incredibly popular with users, so be great to see it as part of core.

Some tutors still prefer to have all their content on one long page, and that's fine - they use a single section with headings and horizontal rules to semantically divide content.

This summer break we plan to turn off all the scroll based formats (for consistency of user experience).

Pages was a huge win with our students.

We user tested the hell out of wireframes & clickable prototypes before developing it in moodle code, and from looking at your wireframes i can see you might be about to hit some of the same issues we found with our users, mainly :

1.1 Navigation between sections

This wireframe seems to indicate the only navigation would be through pagination pattern <previous next> (with section titles, which is great) and an extra course title bit in the middle to take you back to the list of sections.

When we user tested something similar the outcome was that users wanted a simple ‘click a section title to get to a section’ navigation visible at all times.

I’m aware the current moodle2 navigation does not support this, and its not indicated as a work package in the doc, but it’s something you may run into when testing with users, so probably need to consider.

2. Update core formats: Weekly and Topics

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

Add a section & delete are big win with our content creators -

3. 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.

Again - big win for content creators.

3.1 Adding activities and resources

Giving our users pedagogical information about why using a resource or activity could aid their teaching was important. Many were unfamiliar with wiki, glossary and other common web cms tools that ‘digital natives’ (for want of a better term) could simply understand and choose to use. Moodle specific mods like the database or lesson needed this info for all users. With a large user base, and small team building this info into the interface rather than relying on training or documentation made a lot of sense.

http://tracker.moodle.org/browse/MDL-30615 looks like a big step in the right direction.

You’ll have some interesting discussions about what is the right default pedagogical info to provide for activities and how to provide it in 140 characters or less, i’m still not convinced we have the text or UI right, so the fact this has been acknowledged as a problem and that more people are working on this is great news.

3.2 Action icons

Interviews with our content curators told us the ‘editing clutter’ could be a barrier for them. We tried the hover approach, a ‘gear’ icon to show editing and lots of other patterns.

There is a forum discussion on the editing clutter we posted our users prefered solution on http://moodle.org/mod/forum/discuss.php?d=197470&parent=864943

Video -

Would this design pattern be something others would like to see in moodle?

Overall there are quite a few mentions in the proposal of javascript, and reliance on it for certain functionality.

From our own lessons learned it’s important not to over-speck and rely on js, when good old fashioned html/css will do the job and often produce better, simpler interaction. Sometimes the infinite possibilities of shiny js interaction can distract from what you need - a great, simple user experience pattern. Less reliance also keeps page load times down, decrease complexity for developers, aids accessibility and makes it all more future proof.

Keep it simple, and keep tommorow in mind when developing now http://futurefriend.ly/thinking.html

So yeh, great work all round really looking forward to seeing some of this in future moodles, hope sharing our experience with some of this proves useful to you!

Cheers
Stuart Lamour
E-learning team @ sussex

p.s. on a technical note It’s been interesting for us developing with html5 to see the browser landscape move from ie8 and below to chrome, firefox4+, ie9, tablet and mobile becoming the predominant methods of accessing our moodle. I’d recomend using the latest html web standards for interaction (data-target, details/summary, draggable may all be relevant to your spec) and polyfills/shims as fallbacks https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills

Not quite the course format but very closely related as it pertains to displaying activities/resources in sections. Currently, standard activities are displayed as icon + linked. A recent addition 'show description' allows for displaying the activity summary after the link.

Why not inside the link and/or instead the name?

If I can hide the activity name and icon and have the summary inside the link I can put there a nice image and make the link an image button rather than a dull text link with (usually annoying) small icon. Furthermore, if I can hide the activity name and icon I can have activities on the course/front page which I can link to from somewhere else without cluttering the course/front page.

It's a fairly simple hack which would be an appreciated addition to core.

course/moodleform_mod.php
-------------------------------------------
-- line 725
-- replace with:
    $options = array(0 => get_string('choosedots'),
        1 => get_string('descriptionafterlink'),   // description after link
        2 => get_string('descriptioninsidelink'), // description inside link
        3 => get_string('descriptioninsidelinknameless');  // description inside link, no name
    $mform->addElement('select', 'showdescription', get_string('showdescription'), $options);

Then, print_sections

course/lib.php
--------------------
-- lines 1603 - 1633
-- replace with:
                    // If specified, display extra content
                    if ($content) {
                        $contentpart = '<div class="contentafterlink' .
                                trim($textclasses) . '">' . $content . '</div>';
                    }
                    
                    $activityiconhide = '';
                    $activitynamehide = '';

                    // show name and description inside link
                    if ($mod->showdescription == 2) {
                        $linkcontentpart = $contentpart;
                        $contentpart = '';
                    }

                    // show only description inside link
                    if ($mod->showdescription == 3) {
                        $activityiconhide = ' hide';
                        $activitynamehide = ' hide';
                        $linkcontentpart = $contentpart;
                        $contentpart = '';
                    }

                   // Display link itself
                    echo '<a '. $linkcss. $mod->extra. $onclick. ' href="' . $url . '">'.
                                '<img src="' . $mod->get_icon_url() .
                                '" class="activityicon'. $activityiconclass. '" alt="' .
                                $modulename . '" /> ' .
                                $accesstext . '<span class="instancename'. $activitynameclass. '">' .
                                $instancename . $altname . '</span>'. $linkcontentpart.
                        '</a>';

The main problem I see with the UI is that "The General Section is Always Open". 

The problem is the user's focus is in the top center of the page. When they click to go to a page, they then have to look down (and maybe scroll down) to see the content they have attempted to navigate to. This ends up being frustrating.

Imagine looking at a course with many pages and having to look down from the general section each time you go from one page to another. At some point you start asking yourself why that general section is there when you've looked at it a dozen times. This distracts focus from the page you are currently on.

It's ideal from a cognitive perspective to avoid this - the learner's visual channel should be full of the current' page's content and not have to do work to filter out the already seen content in the general section .

I suggest this be optional, and/or treat the General Section simply as page 1 - when I click to go to Page 2, I don't need to see the General section anymore, I've already seen it.

This is looking very good.  One thing we're looking for as we try to find a replacement for FlexPage is the ability to reference Resources in multiple sections without making mutiple copies.  Will this address that, or did I already miss it?