New on-line teaching ideas for engineering, science and tech

Today’s are the  fourth in a series by Steve Mackay and Edwina Ross (Engineering Institute of Technology)

Virtual touchy feely is best with remote online labs

Experiential learning – or hands-on education – is one of the most optimal ways of gaining engineering expertise; online learning, therefore, must accommodate it. The ongoing virtualisation of instruments (e.g. oscilloscopes and signal generators controlled and viewed from PCs or tablets) is the key – the impetus for using remote labs. For example, it is common for mining trucks and plant equipment to be controlled remotely; this illustrates that virtualisation of work and equipment is growing apace.

Some traditional teachers of engineering remain sceptical; they suggest that remote labs lack authentic, hands-on work. Despite this, learners find a well-constructed remote lab (with a simple interface) useful and equivalent to a traditional lab.

Pointers for successful remote labs: * build them with a clear understanding that there will be multiple users * employ a scheduling system for the lab users – this can assist with system overload, * reduce system response times – they should remain below 150 milliseconds, * aim for “reality” – with an easy-to-use graphical user interface * use good lighting, * ensure teachers are well-trained and supportive, *encourage students to reuse labs to improve results * use lab work as part of a student’s final grade.

Design principles for the Graphical User Interface (GUI) for remote labs: * keep it simple and intuitive, * aim for authenticity, * ensure multiple users can work together, * enable a student to interface with a standard computer (preferably within a browser) with minimal software add-ons, * ensure the GUI displays key information swiftly, *use plain English, * have a quick exit option from unwanted menu selections, * standardise interfaces and make them consistent, * do not make the steps, within the GUI, necessary to remember, *simplify and clarify error messages.

Overall design considerations: *experiment type: how will the architecture impact on the experiment; multiple users and queuing issues? *scalability: how will the system cope when the number of users peaks? * maintainability: does it integrate easily into the overall IT services/systems? * security: has this been a key part of the design and are secure communication protocols supported? * dependence on protocols: does the architecture require a specific protocol?


More here .