Building Blocks in Blackboard

What is a building block?
  • Mini-application that runs within Blackboard (usually third-party integration)
  • Interface is designed to look like the rest of Blackboard
  • Can be found in certain places in the UI – e.g. course tool building blocks, group tool building block, system tool building block, content type building block, module building block
 
Why use building blocks?
  • To extend the functionality of Blackboard (LEARN@PolyU (理學網) at PolyU
  • To customize Blackboard to meet the different needs of departments
 
Examples of building blocks at PolyU:
  • Bb extension (developed by Bb or Third Party and approved by Blackboard) – SoftChalk (used by ELC); MathJax (used by AMA), TurningPoint (used by the Clickers project)
  • PolyU developed – User Group (developed by ITS and tested by EDC)
  • PolyU redeveloped – Primo (developed and used by the Library), Originally developed by North Western University in USA
  • BeeNet developed – ELC R&W module (Phase 1), Library Resources Link, Outcomes Assessment (for Computer Science)
 
Pros and Cons:
 
building_block_image1
 
Building Block guidelines:    
 
   1. Building Block policies
  • Obtain approval from senior departmental management (ensure that it meets the university’s initiatives)
  • Identify the reliability of the source of the building block
  • Ensure the availability of the contact point of the developer of the building block
  • Define the testing plan for each building block deployment
  • Define the rollback plan
  • Ensure resources are available for maintaining the operation of the building block
  • Define the review period
 
   2. Process for deploying Building Blocks
  • A workflow should be developed for building blocks request (request > first system test > user acceptance test > system acceptance test)
  • Users (Requesters) will need to provide their User Requirements when requesting installation of building block
  • The system can only handle one building block request at any time
  • Extra resources are needed for the operation of building block installation service
 
4-Stage Process for staff to seek building block development:
 
building_block_image2
 
After successfully completing the 4 stages, details of the Building block will be made available to staff as a form (with notes) in the eTeaching section of Blackboard.
 
Note:
ITS/EDC can provide assistance before formal request is submitted to them. It is recommended that consultations take place before request is submitted.  Consultations will focus on the 4 stages.
 
 
Stage 1 – Pre building block request
  • It is the responsibility of the owner to ensure that the building block addresses the learning and teaching rational for the department and university in general. Approval needs to be sought from senior departmental management
 
Stage 2 – User requesting building block
In most cases the “owner” of the building block will be the department. The LMS team (responsible for building blocks) will help each owner as much as it can in terms of providing the environment to build and test the building block; help with the testing plan; and with the programming if developed at PolyU.  However, to ensure sustainability and a more effective process for updates each department will be encouraged to take responsibility for the programming (if developed in-house). This could involve training for technical staff within the departments. Key points to note are:
  • It is the responsibility of the owner to identify the reliability of the source of the building block
  • It is the responsibility of the owner to obtain contact details of the developer of the building block
  • It is the responsibility of the owner to maintain and update their building blocks
  • It is the responsibility of the owner to define the testing plan for each building block deployment (and rollback plan)
  • It is the responsibility of the owner to ensure that the building block is compatible with different versions of Blackboard (i.e. in SP8, SP13 etc.)
 
Stage 3 – Criteria to judge requests
  • The LMS team has the responsibility to safeguard the LMS in terms of security and compatibility issues
  • The LMS team will look at the potential usefulness of the building block on the user
  • The LMS team will look at the impact of the building block on the institution
 
Key Question: Who will decide if the building block is deemed not feasible/unsuitable for the live environment?
 
Stage 4 – Testing
  • The LMS team will carry out comprehensive testing
 
Stage 5 – Maintenance including upgrades
  • The “owner” has the responsibility for ongoing maintenance of the building block (but with support from LMS team if required)
  • The “owner” has the responsibility for developing, researching and testing the building block (but with support from LMS team if required) in new Blackboard upgrades
 
Additional Resources:
  • EduGarage – edugarage.com
  • OSCELOT  – oscelot.org (Open Source Community for Educational Learning Objects and Tools)