General Remote Instruction Information: Difference between revisions

From William Paterson University - Information Technology's Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
This wiki article is designed to give you general information about teaching remotely.  
This wiki article is designed to provide general information about teaching remotely.  


=menu 1 "Factoring in Bandwidth Considerations to your Distance Teaching"=
=Factoring in Bandwidth Considerations to your Distance Teaching=
==menu 2==
'''Contributed by Provost Josh Powers'''
===menu 3===
The tools of technology for remote instruction are substantial, but so are the practical implications for bandwidth and the ease with which students (and the instructor) are able to receive and engage content remotely with varying degrees of speed. The below graphic provides a visual perspective on this reality:
* bullet1
 
** bullet 2
[[File:Bandwidth.png|thumb|Bandwidth-Immediacy Matrix - click to enlarge]]
***bullet 3
 
In summary, here are a few rules of thumb:
 
Synchronous course delivery via video utilizes the highest bandwidth. Students, and you, can get frustrated when video freezes or goes pixilated, and/or audio comes through truncated or delayed. Solution: Ask that students not utilize their video unless presenting. General Q&A also doesn’t require their video, and they can virtually “raise their hand” in Blackboard with you inviting the order of comment/question. We do generally recommend that the faculty member utilize their video, however (unless you are the source of connectivity challenge) since visuals are more engaging than a blank screen. We also recommend that persons not speaking leave their mics on mute.
 
Larger PPTs or documents (ones with much color and/or high meg pictures) can utilize substantial bandwidth. Content can be more likely to freeze or go pixilated when larger files load. Solution: Obviously there are moments when learning is enhanced with powerful visuals, but if/when they aren’t required, we recommend you consider going simpler where appropriate to reduce the chances for slow loads, and by extension, frustration.
 
Asynchronous teaching can be less frustrating because it is not time dependent. The frustration of time-consuming technology challenges in a time-bounded synchronous course can be higher than in an asynchronous course because a student in the latter can view/engage content on their own time. Slower loads have less implications in an asynchronous course, and a student can re-review all content (recorded video or audio that follows a PPT for instance). This is not possible in a synchronous course unless you record it (which, btw, you are encouraged to do since it is something not possible with a regular face-to-face course). Solution: Consider shifting at least some of your course content to an asynchronous approach. Obviously there are multiple issues to consider when doing this, but we encourage experimentation (i.e., if you don’t do fully asynchronous, you can opt to do some weeks asynchronously, and others synchronously, so long as students are clear on what you are doing when).
 
The Chat feature in a synchronous course can be beneficial for reducing bandwidth issues. Because video, and audio to a lesser extent, consume the most bandwidth, the chat feature can be beneficial for enabling typed questions or comments. Solution: Experiment with the chat feature in Blackboard as a full class, but also know that you can put students into smaller groups for more intimate discussion, and you can even “drop in”, just like you might do in a real class orbiting around the room!

Latest revision as of 16:25, 22 March 2020

This wiki article is designed to provide general information about teaching remotely.

Factoring in Bandwidth Considerations to your Distance Teaching

Contributed by Provost Josh Powers The tools of technology for remote instruction are substantial, but so are the practical implications for bandwidth and the ease with which students (and the instructor) are able to receive and engage content remotely with varying degrees of speed. The below graphic provides a visual perspective on this reality:

Bandwidth-Immediacy Matrix - click to enlarge

In summary, here are a few rules of thumb:

Synchronous course delivery via video utilizes the highest bandwidth. Students, and you, can get frustrated when video freezes or goes pixilated, and/or audio comes through truncated or delayed. Solution: Ask that students not utilize their video unless presenting. General Q&A also doesn’t require their video, and they can virtually “raise their hand” in Blackboard with you inviting the order of comment/question. We do generally recommend that the faculty member utilize their video, however (unless you are the source of connectivity challenge) since visuals are more engaging than a blank screen. We also recommend that persons not speaking leave their mics on mute.

Larger PPTs or documents (ones with much color and/or high meg pictures) can utilize substantial bandwidth. Content can be more likely to freeze or go pixilated when larger files load. Solution: Obviously there are moments when learning is enhanced with powerful visuals, but if/when they aren’t required, we recommend you consider going simpler where appropriate to reduce the chances for slow loads, and by extension, frustration.

Asynchronous teaching can be less frustrating because it is not time dependent. The frustration of time-consuming technology challenges in a time-bounded synchronous course can be higher than in an asynchronous course because a student in the latter can view/engage content on their own time. Slower loads have less implications in an asynchronous course, and a student can re-review all content (recorded video or audio that follows a PPT for instance). This is not possible in a synchronous course unless you record it (which, btw, you are encouraged to do since it is something not possible with a regular face-to-face course). Solution: Consider shifting at least some of your course content to an asynchronous approach. Obviously there are multiple issues to consider when doing this, but we encourage experimentation (i.e., if you don’t do fully asynchronous, you can opt to do some weeks asynchronously, and others synchronously, so long as students are clear on what you are doing when).

The Chat feature in a synchronous course can be beneficial for reducing bandwidth issues. Because video, and audio to a lesser extent, consume the most bandwidth, the chat feature can be beneficial for enabling typed questions or comments. Solution: Experiment with the chat feature in Blackboard as a full class, but also know that you can put students into smaller groups for more intimate discussion, and you can even “drop in”, just like you might do in a real class orbiting around the room!