Attachment 790 Details for Bug 4849 – XML file that is not converting to PDF

XML file that is not converting to PDF

polar-bear-high-tech.xml (text/xml), 7.67 KB, created by Carlos Araya on 2001-11-13 13:19:15 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Carlos Araya

Created: 2001-11-13 13:19:15 UTC

Size: 7.67 KB

patch

obsolete

><?xml version="1.0"?>
><!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 
>"docbook/docbookx.dtd">
>
><article>
><articleinfo>
>	<author>
>		<firstname>Carlos</firstname>
>		<surname>Araya</surname>
>	</author>
>	<title>The Polar Bear Goes High Tech</title>
>	<subtitle>Pitfalls and subtleties of implementing technology in education</subtitle>
>	<revhistory>
>		<revision>
>			<authorinitials>cal</authorinitials>
>        		<revnumber>0.1</revnumber>
>        		<date>November 7th, 2001</date>
>        		<revremark>Initial Draft, some polar bears covered</revremark>
>     		</revision>
>	</revhistory>
></articleinfo>
>
>
><para>At the CVC conference, Martha Mills, Francine Van Meter and 
>Scott Hildreth presented a panel entitled <citetitle>Watch out for 
>Polar Bears: Survival Tactics for Distance Education</citetitle> about 
>things that you would likely face when working on distance education. 
>However, the presentation left out one area that I believe it's 
>critical for a successful distance learning experience: 
>Technology.</para>
>
><para>Having worn (and still wearing) the hats of "techie" (Server 
>administrator and tech support) and "instructional designer" (trainer) 
>I've discovered some technical and some instructional design 
>principles that may help other people when working with technology. I 
>will illustrate these principles with examples as much as I 
>can.</para>
>
><para>I'd like to point out one thing when talking about these
>hightech polar bears: Your Milleage May Vary
>(<acronym>YMMV</acronym>). These are the experiences of one person at
>two very different institutions and may not reflect other people's
>experiences. I welcome other polar bears and how you've dealt with
>them.</para>
>
><important>
><para>This paper is written in the ssumption that you have buy-in from
>your administrators and your faculty will be patient and understand
>that you're a technical expert and not a miracle worker. It also
>assumes that you will have support from other departments within your
>institution. If not the polar bears will me much harder to tame and
>deal with.</para>
></important>
>
><sect1 id="Development"> 
><title>Rome wasn't built on a day, neither should your course</title>
>
><blockquote>
><para>On one of my regular trainings an instructors introduces
>hereself and tells me <emphasis>I need to have a course ready by
>winter and I haven't had any experience with online courses, as a
>student or as an instructor</emphasis> and now we're midway through
>our Fall semester/quarter. </para>
></blockquote>
>
><para>How many times have you heard statements like the one above? 
>I've lost track of the number of faculty who have come to me basically 
>requesting that I develop their course for them because they start 
>teaching shortly and they don't have the expertise to put their course 
>online</para> 
>
><para>The way I deal with these kinds of request is simply to let them 
>become familiar with the software and tell them up front that course 
>development takes time. How you address this will deppend a lot on 
>your policies for course development and whether you have an 
>instructional design team in place. Some of the more successful 
>programs work 2 years in advance: right now they are working on Fall 
>2003 courses and have had their courses for Fall 2001 ready for the 
>past 2 years; but <acronym>YMMV</acronym>.</para>
>
><para>There is also an issue of educationg administrators on what it 
>takes to develop an online course. A lot of times the expectations of 
>a quick turnaround come from deans or department chairs who have not 
>had as much experience in developing online couses or who, having 
>developed an online course, believe that all faculty should be able to 
>pick it up as quickly as they did.</para> 
></sect1> 
>
>
>
><sect1 id="Local Resources">
><title>The importance of being local</title>
>
><blockquote>
><para>A faculty member comes to me and asks, <emphasis>If you guys are 
>not going to support me, who will?</emphasis></para>
></blockquote>
>
><para>If you're working on one campus only; you can, and often are 
>required to,  wear more than one hat and be your faculty's technical 
>support. if you work with more than one institution then the support 
>problem gets compounded to the point where you can spend most of your 
>work time doing support and nothing else.</para>  
>
><para>The obvious answer would be to hire more people (or students if 
>you can snatch workstudy dollars) to work exclusively on support, but 
>I know that's not a realistic expectation. So I will say it first and 
>explain it later: <emphasis>Work samarter, not harder.</emphasis></para>
>
><para>What do I mean by smarter? for example: you get the same 
>question over and over again; instead of answering the question over 
>email, you develop an FAQ and post in on a website where it is easily 
>accessible for students who are having problems.</para>
>
><para>Another example of working smarter is to know when to say no. A 
>lot of the problems that student have have nothing to do with Distance 
>Learning or with the school at all. The classical example is the 
>student calling Distance Learning because they can't connect to the 
>Internet at all. while it would be nice to help them with all their 
>problems, there is a limit to the resources you can muster for support 
>of any kind so it is important to prioritize.</para>
>
></sect1>
>
><sect1 id="Be prepared">
><title>You never know... so be ready for when it happens</title>
>
><blockquote>
><para>For the first 6 to 8 weeks of the semester the perforrmance of 
>the WebCT server was awful. There were colleges that were ready to 
>spend money and move their courses to a webct.com server in order to 
>get rid of these problems for their faculty. After much trial and 
>error, the problems were identified and corrected but there were (and 
>still are) a lot of faculty members who got very dissapointed and are 
>seriously rethinking about teaching online next term</para>
></blockquote>
>
><para>We always think that we will never have to deal with a worst
>case scennario, but there are times when we have to deal with things
>that make it harder for use to do our jobs effectively.</para>
>
><para>The first thing to do is to plan a recovery strategy. What do I
>do if my primary system goes down or becomes irresponsive? How do I
>ensure the shortest downtime possible for my users? How much support
>is too much for the resources I have available?</para>
>
><para>The first and second questions are related: <emphasis>What do I
>do if my primary system goes down or becomes unresponsive?</emphasis>
>is almost the same as asking, <emphasis>How do I ensure the shortest
>downtime possible for my users?</emphasis> They both have a lot to do
>with what resources you have available at your ogranization. In an
>ideal world I would have a <emphasis>Hot-standby</emphasis> server
>where the backups from our live production server would go and which
>we could switch to if we needed to. Another thing to consider is
>working with colleagues to build collaboartive solutions. for example:
></para>
>
><blockquote>
><para>A group of colleges who have worked together in the past have
>agreed to partner and provide backup services for all
>participants. One strategy they take is to provide mirroring services
>for the courses from participant colleges in such a way that if the
>primary server goes down it will automatically go to the backup server
>and continue services.</para>
>
><para>The participants realize from the beginning that this will
>require additional resources and that planning and implementation will
>become key to the success of their project</para>
></blockquote>
></sect1>
>
>
></article>

Actions: View

Attachments on bug 4849: 790