Current version of BIM

BIM is an activity module for Moodle that helps teachers manage and mark student use of personal feeds (produced by blogs, twitter, whatever). See the main BIM page for more information.

Below you should find how to access the code and some initial documentation for BIM. (Eventually this will/may be moved to the main Moodle site when/if BIM is contributed.

The code

The most up to date version of BIM is available from github. To download a copy to your site, click on the “Download Source” button.

BIM is currently being used at CQUniversity and University of Canberra.

The documentation

DISCLAIMER: The following documentation is intended primarily for technical folk at Netspot who will be evaluating the BIM code real soon now. Documentation and other resources aimed for use by students and teachers, will be available in the next week or so.

Currently there are three main sections to the documentation on this page:

  1. What does BIM do?;
    A general overview of what BIM allows you to do.
  2. Installing BIM
    Basic steps about how to install and get going with BIM.
  3. Using BIM; and
    Simple overview of how to use BIM.
  4. Understanding BIM technically.

Other online resources include:

What does BIM do?

There are two ways to describe what BIM does: a concrete and an abstract description.

Abstract description

BIM stands for BAM into Moodle. BAM stands for Blog Aggregation Management. BAM was a system integrated into CQUniversity’s e-learning systems. In 2010, CQUni is moving to Moodle. BIM is a translation of BAM into Moodle.

BIM is a Moodle module that supports an activity where:

    Each student registers an individual external web feed.
    The feed might be generated by a blog, twitter or any other tool that produces a web feed. It’s the student’s choice what they use.
  • Each student uses that external feed to respond to a set of questions.
    Currently, those questions usually encourage the student in reflecting on their learning, often in the form of a reflective journal. However, there is no need to have a set of questions.
  • BIM mantains a copy of the posts that appear in the students’ web feed, and attempts to automatically allocate student posts to the questions.
  • Different teachers track, manage and mark posts for different groups of students.
  • A coordinating teacher allocates teaching staff to different groups, tracks their marking progress and the progress/activity of all students.
  • The overall mark students receive, can be sent to the Moodle gradebook.

Concrete description

BIM – starting life as BAM at CQUniversity – arose because a course had a problem and BAM was the solution.

The course was offered 3 times a year; usually with 100+ students in each offering; taught by 10+ staff; distributed across multiple campuses and distance education; and had issues with large failure rates, significant levels of plagiarism, limited quality and quantity of feedback to student progress, and little or knowledge of how students were going.

The problem was that one assignment required students to maintain a reflective journal of their learning experience. The assignment was worth 10% of the final mark and students were given a series of questions to guide their reflection. The assignment was submitted at the end of term as a Word document.

Students treated the assignment as a creative writing exercise to be commenced just before the submission date. There were problems with plagiarism and staff could not give feedback to students.

The solution was to move the student reflective journals from a Word document to a personal web blog. The aim was that the students could be visibly seen contributing to (or not) their reflective journal during the term. The teaching staff could look at these contributions and give feedback. The hope was to increase ownership and visibility of the task. To increase student engagement.

With 100s students and 10s of staff, a tool was needed to manage the process. That tool was BAM. BIM is a translation of BAM into Moodle with some improvements.

By late 2009, use of BAM at CQUniversity included:

  • 26 offerings of 7 different courses.
  • 2790+ students.
  • 20,000+ blog posts.

This concrete example of BAM is described further in this paper

Installing BIM

You install BIM into your Moodle instance using the standard process:

  1. Unpack the archive from github into the mod directory of your moodle installation.
  2. Re-name the directory github created (e.g. djplaner-BIM-36784f5) to bim
  3. Login to your Moodle site as administrator
  4. Click on Notifications
  5. Moodle should install BIM

At this stage, you should be able to add BIM activities just like you would any other activity. i.e. when you click on the “Add an activity..” drop box (when “editing” is turned on) you should see something like this.

When you have added your activity, your course should show something like this.

Theoretically, you may be able to get going with BIM from there. BIM includes some documentation within the module, but you may wish to read more below.

Using BIM

BIM allocates to all users one of three capabilities. Which capability a user is assigned governs what they can do with BIM. The following table summarises the three capabilities, the Moodle roles automatically assigned the capability and what each capability allows the user to do.

Capability Moodle role What they can do
Coordinator editingteacher
Configure the activity, manage questions, allocate markers to groups of student, view marking progress of all markers, release marked posts, mark posts.
Marker teacher View details and mark posts for an allocated group of students.
Student student Register a feed and view details about what BIM knows about the feed, its posts and any marks.

When you use BIM, what you can do, depends on what type of capability you have. The following list of tasks you can do with BIM are divided into those capabilities (and mirror what’s in the table above):

  • Student
    • Register a feed.
      When a student first clicks on a BIM activity, they will not have a registered feed. BIM will show the feed registration page. The first part of the description on this page is the description entered by the coordinator when they configure this BIM activity.

      At this stage the student has to enter the URL for the blog or feed. BIM will perform checks and report errors. Once successfully registered, BIM will show details about the student’s blog/feed, including a success message.

    • View details.
      After registration, any subsequent visits to the BIM activity will show the details of the student’s blog, posts and any marking. As the student’s posts are created, allocated, marked and released the details on this page will change. When posts are released, students will be able to see the marks and comments by the markers on this page.
  • Marker
    • View student details.
      Provides an overview of the markers’ students. Including whether or not they have registered, links to email students, to register blogs and to see how long since they last posted. The page is more useful when there are registered students.

    • Mark students posts.
      Show’s details of the markers students in a way that supports the marking of posts. When there are no students registered yet, this can be a fairly empty page. However, when students have registered, it is much more interesting.
    • Mark a single post.
      Markers come to this page from the “Mark student posts” page. This page allows the marker to: comment, award a numeric mark, suspend and re-allocate an individual post to another question.
    • Allocate posts.
      Also accessed via the “Mark student posts” page, this page shows all of the posts from a single student. Normally, BIM tries to automatically allocate student posts to a question, but it sometimes fails. This page allows the marker to manually allocate posts to a question.
  • Coordinator
    • Create/Configure BIM.
      Where you provide the name and description of the activity. As well as choosing whether or not students can register their feed, whether the students posts are being copied/mirrored by BIM and whether the results of this activity will be added to the gradebook.

      There are two parts to this task: traditional Moodle activity configuration page and another that allows the coordinator to view the configuration.

    • Manage questions
      Where you add, modify and delete the list of questions the students should respond to by making posts to their feed.

      Each question has a title, description and a minimum and maximum mark. This image shows the manage questions page with an existing question.

    • Allocate markers.
      Where you configure which groups of students each marker will be responsible for. You have to use standard Moodle tools to create the groups and add the markers. This page is used to connect markers to groups just for a particular BIM activity.
    • Manage marking.
      Where you can view the marking progress of each of the markers. The initial image shows a simple version of this page when there are no markers allocated.

      This page is most useful when there are markers allocated and questions added to the activity. For example, in this image you can see how each marker’s progress is shown against each question (titled “Week 2” and “Week 4”).

    • Find students.
      Allows you to search for the details of a specific student by entering part of their username, name or email address.
    • Mark a group of students.
      Allows a coordinator to mark any students they have been allocated to.

Understanding BIM technically

In late 2009 when the development of BIM commenced, I knew nothing of Moodle development. I now know a bit more, however, it’s still patchy and some of the sections of the BIM code – especially those written earlier – are a bit rougher than others.

Structure of the code

Apart from the standard Moodle activity module directories and files (lang, db, mod_form.php, version.php etc.) the BIM code is divided up as follows (all paths below assume you are in the bim directory):

  • view.php – the standard PHP script run when visiting an activity. In BIM this script:
    • Get’s information about the course module, activity instance.
    • requires a login
    • Determines which capability the user has (student, marker or coordinator) and then passes execution to one of “show_coordinator”, “show_student” or “show_marker” (described below)
  • lib – contains a range of support functions/libraries. Includes a copy of the SimplePie PHP syndication class/library. SimplePie is used to handle the registration, caching and parsing of student feeds. The other files in this directory are:

    • bim_rss.php – most of the functions for manipulating and processing student feeds.
    • groups.php – functions for managing groups of students and their markers.
    • locallib.php – a collection of other functions.
  • student – contains all of the code used to implement the core student services. Contents include:
    • view.php – collection of functions to implement student functionality. Starts with “show_student” which acts as a case statement
      • If no registered feed for this student, show the register form and process it.
      • If there is a registered feed, show details of the feed.
    • register_form.php – defines the form used by students to register their feed.
  • marker – implement pages for the marker. Contains
    • view.php – starts with “show_marker” which is case statement, based on a parameter in the URL called “screen”, if screen equals
    • lib.php – support functions specific to the marker tasks
    • allocation_form.php – form for allocate posts
    • change_blog_form.php – form for changing blog
    • marking_form.php – form for marking a post
  • coordinator – implement pages for the coordinator. Contains
    • view.php – implements show_coordinator, the big case statement. A little more complex than that for marker because the coordinator has their own set of tasks (specified using the URL parameter tab) as well as being able to call the basic marking tasks of the coordinator (URL parameter screen). Further complication arises because one of the activities has 3 sub-parts (parameter op)

      If “tab” is equal to one of config – configure BIM, markers – manage markers, questions – manage questions, or find – find student. Then the appropriate function is called.

      If tab = “manage” then there are 3 functions that might be called, which one is based on the value of op: op is nothing – then straight manage marking screen; op is “release” then we want to release a list of posts; op is “view” we want to drill down and see some details of students.

      If tab is details, then the coordinator gets to perform the tasks outlined for a marker (see above).

    • manage_questions.php – functions to manage the questions
    • question_form.php – the form for managing questions
    • allocate_markers.php – functions for allocating markers
    • marker_allocation_form.php – the form
    • manage_marking.php – functions to manage marking (no form)
    • find_student.php – functions to find a studnet
    • find_student_form.php – the form

Structure of the database

BIM adds 5 tables to the moodle database:

  • bim – holds configuration information
  • bim_questions – the list of questions associated with each bim
  • bim_group_allocation – the list of groups a marker has been allocated to for each bim activity
  • bim_student_feeds – detail about which feeds each student has registered for each bim
  • bim_marking – holds a copy of all posts made to the student feeds and also the marking information (mark, comments, marker etc.)

    STATES: A student post can be in one of 5 states represented by the “status” field in bim_marking. The 5 states are:

    • Unallocated – the post has been copied, but it wasn’t allocated to a question.
    • Submitted – the post has been allocated to a question, but not marked.
    • Marked – the post has been marked, but not released to the student.
    • Suspended – the post cannot be released to the student.
    • Released – the post has been released to the student who can see the details of marks and comments.

Use of the file system

BIM, through the use of SimplePie, will keep a cache of each student’s feed in a directory on the file system. The directory path is

$CFG->dataroot/CourseID/moddata/BIM ID

Processing of student feeds

Student feeds (RSS, ATOM, whatever is supported by SimplePie) are cached locally and processed. The processing will:

  • Attempt to allocate new posts to one of the set questions; and
  • Examine existing posts to see if they can be allocated.

Currently, allocation occurs only if the post title contains the entirety of the question title (case insensitive and white space characters in the question title can match any character) – e.g. if the question title = Week 5 then a post with the title My week 5 post will be matched.

This processing occurs at 3 different times:

  • When the student first registers their blog.
  • Any time the student views the details of their feed on BIM.
  • Once every 60 minutes (or whenever BIM’s cron variable is set to).

Gradebook integration

BIM’s integration with gradebook is simple.

Individual BIM activities can be configured to save results to the gradebook, or not.

As soon as BIM is configured to work with the gradebook, a field for the BIM activity is created in the gradebook.

After that, every time the coordinator releases some posts, BIM will, for each student, add up the marks for all their released posts, and modify the student’s gradebook entry for this activity to be the that value.

4 Replies to “Current version of BIM”

  1. Pingback: moodlepedagogik

Leave a Reply

Your email address will not be published. Required fields are marked *