Open Forum Summary: LMS Support

During the Open Forum, various aspects of support were discussed. The major points and comments that were made during the open forum are provided below. These points, and in addition to the survey results, has helped to inform our discussions and preliminary planning on how to provide appropriate support to a wide range of faculty.

In summary, what we have discerned from this Open Forum is that there is a large range of expertise among the faculty with both technical knowledge and know-how. The support structure needs to serve this wide range in the knowledge base and craft material that is geared for the various audiences. Often there has been an emphasis demonstrating a particular tool and explaining things using technical terms; additional emphasis needs to be placed on how such tools can be used to to support student learning outcomes and not driven by technical nuances. Hence the training material must be crafted with the understanding of the salient tasks that faculty need to perform and delivered in various modes.

The current support structure is, also, fragmented and faculty obtain different messages and instructions from different support groups. Each of the support units need to be aligned in understanding the needs of faculty and to be able to correctly triage issues and redirect faculty members to the most appropriate support. (There should be no ping-pong-ing.)

Since faculty prefer different types of support, several modes of delivery is required. Full support should be provide in the forms of web-accessible guides and other training material and real-time support via phone and in-person. Types of training requested included:

• On-line, written, visual, and video
• One on One
• Lab seminars
• Lecture style
• Searchable knowledge base
• Phone help line
• Brown bags

Comments and points obtained from the Open Forum:

Types of Support:

• There is a large range of the type of support that is needed, some faculty are very technically savvey and others are just beginners.
  The support structure needs to address each of the various technical levels of faculty.

• Lots of little support help is needed -- Faculty want to be able to get help on getting started. Examples of questions they will pose include:
  • "How do I do this....?"
  • "What is the right tool to do ....?"
    
  • "Where do I go to get help on...?"
• Faculty need to be able to meet with support personal via one-on-one sessions.
  • This will enable them to have their specific issues addressed quickly and at the appropriate technical level
• It is not a goal of faculty to become technical savvy.
  • Hence, the need for technical support.
  • Hence, the need to have different levels of support provided (i.e., meet the needs of your audience).
• Many faculty fear technology...
  • The support needs to demystify technology.
  • The support needs not to be provided using technospeak but in layman terms.
    

Phone Support:

• There needs to be multiple entry points into the Call-in Center. E.g., the way the UHD provides the ability to redirect faculty calls.

• There needs to be a friendly facility to escalate a particular issue.
  
  • Having the ability to talk to only a first-level support does not always solve issues.
• There needs to be a way to avoid bottlenecks.
  • E.g., The turnaround time for the support that the faculty need should not be impacted by peak periods for other IT activities
• Faculty need phone support during times in when the University is not "open."
  • having additional phone support during off hours would be helpful
  • outsource after hours was mentioned as being both good and bad
• It was remarked that more attention needs to be placed on automated systems (e.g., a knowledge base) in lie of more head count
  

Where to go for Support:

• There needs to be multiple points of entry into the Support System. Based upon
  • the type of problem encountered or inquiry sought
  • where the faculty member is most comfortable going for help

• Each entry point of the Support System should be able to facilitate providing appropriate support (I.e., no ping-pong-ing).
• When a faculty members calls, the "Need Help Now".
  • Hence, the first place they call needs to be knowledgeable about providing help or connecting them directly to the right place.
• Support is currently fragmented, we are not leveraging the various existing support structures:
  • A faculty members needs to know which group to call for each various problem.
  • A faculty member may not know what the core issue is and hence don't know where to obtain the correct help.
• Every office (that provides support) must allow any faculty member to walk in and get appropriate assistance.
• Faculty have a greater rapport with support staff that is "closer" to them and prefer to work with these individuals.
• Where ever a faculty member goes for support, there needs to be a consistent message. Otherwise confusing is increased.
• Support information that is provided via various groups need to be shared with each group so that
  • they are all working from the same message base and know how to redirect faculty to the right location, and
  • they know how to redirect faculty to the right location.
    

Training Guides:

• Really Good Documents are needed

• Online Documents must
  • be well written
• be well design
• be well focused
  
• adhere to universal design
• The documents should be copious in nature. An example is the "How to" guides provided by A&R.
• Need knowledge base coupled with FAQ & Documentation
• Need to commit to video all training sessions
  • need captioning: capabilities, training, and facilitation [ on using captioning functionality ].

Training:

• Train-the-trainer model works well:
  • when Faculty teach each other, and the difference in knowledge base is not great.
  • when "what are the pitfalls" are shared
  • when "lessons-learned" are shared

• Training must be focused on the audience and on their immediate tasks that they need to complete.
  • E.g., how to make their web pages ADA compliant, as opposed to teaching to become a web developer.
  • Demo-style training and comprehensive exposure of particular tools is not helpful.
• We need to move from "training" to teaching.
• There needs to be ongoing training based upon topic:
  • support train-the-trainer model (individual faculty members will help other faculty members in their department with similar issues),
  • provide both in-person, online, and one-on-one training,
  • tailor the training to the faculty audience
    (use the faculty background knowledge in the particular subject matter at hand).
• An Annual, One day Conference would be beneficial:
  • You can highlight what's coming up in the upcoming year.
  • You can provide break out sessions to allow birds of a feather group to be formed.
  • The conference can highlight how hybrid courses can be used to enhance particular pedagogical approaches, and to help more faculty to engage in hybrid course development.

Other:

• The RTP process needs to recognize, encourage, and reenforce faculty activity in developing online courses.

• Down loading of software need to be easier.
• Personalization and Configuration is getting in the way...
  • how does a faulty or staff validate what the student has access to or what they see
  • remember faculty members are the first line of support from students
    

Concrete Suggestion:

• A demo or test instance of SOLAR should exist.
• Within this instance, a generic student account should be created that is accessible by all faculty.
  
• This way they can exactly what a student will see, understand how it works, and then provide appropriate assistance.
  
• Since its a test instance all operations would have no impact on production data.