I am no fan of the Blackboard Learn Content Collection. In almost 8 years of working with the product I have not seen any real improvement to the Content Collection. For many, it is virtually invisible and does its job on the back end, but for those power users who dare to wade into it’s clunky interface, it remains to be a nuisance. All web developers that try to utilize it as a web folder, without fully understanding its nuances, will no doubt be confronted with frustration and failure.
HTML Files and Information Hierarchy
The Content Collection is the back-end of the Blackboard Learn file system that allows power users the ability to manage their files without making them accessible to users. It’s common practice for a web professional to pull the direct link of a file and hand-code a link to that file from some other item that resides in the course.
Blackboard’s Content Collection is not designed to be used this way; however.
I have worked with many instructors over the years that have massive legacy websites that were developed during the early days of the internet. These are static HTML pages (sometimes numbering in the hundreds) that are updated every semester.
These users simply try to plop their web sites on the Blackboard Learn Content Collection and deliver their courses this way. I have re-built one course like this during the migration from Blackboard Vista to Blackboard Learn, which took place from 2011-2013. It was a labor intensive process, and maintenance from term to term continues to require upkeep on an ongoing basis.
Permissions
The problem is with permissions. Blackboard wants you to deploy content using their front end GUI method: go to Build Content and select Item or File and upload your documents one at a time. This is in fact how I rebuilt the course website mentioned above. One at a time uploads of HTML documents.
Even when you re-build the content like I described in the Vista-to-Learn migration, problems remain because HTML documents are referring to pictures, file attachments, and icons that are sitting in folders on the back-end (in the Content Collection). In other words, these pretty standard website elements were not “deployed” using the Build Content method.
Now, if you are going to maintain this use-case then you are also going to need to EDIT THE PERMISSIONS of each of the folders so that students can see the files, otherwise the instructor will get reports from students that they can’t see the pictures, diagrams, icons, etc… In fact, you must modify the permissions on these folders on a recurring basis, every time the course is going to be copied from term-to-term.
Future proof
It is completely reasonable and understandable that instructors want a teaching format that is future proof. The problem is, that unfortunately, too often we see fundamental changes in teaching platforms. Static HTML websites being swapped out for more robust LMSs is the perfect example.
As I continue to look forward to our next migration, it will most like be to a platform that treats HTML pages as an afterthought. Teaching and learning in a Learning Management System is less like it used to be. In the days of old, HTML pages could serve as a nice interactive learning experience with static content. Now-a-days, the online space is used more for synchronous and asynchronous interactions.
On the flip-side, a course website can be an effective tool, acting as a guide/outline for lectures, as well as a text book with embedded media and links to related current events that students may find much more engaging than reading a regular textbook on the page.
The moral of the story: One Ring (or LMS) to Rule Them All may not fit into vastly different frameworks that instructors utilize to be effective stewards of their content.