Concerns @ Vista


Following are the list of concerns identified by the UWG Vista Migration Team ( ), the DE Steering Committee, various faculty and staff, regarding UWG's migration to a centrally hosted off-campus Vista server.


Issues in general fall under 7 categories:

I.                    Stability / Performance

II.                 Faculty & Student Usability

III.               Network Concerns

IV.              Pipeline/ Banner Integration

V.                 Administrative/ Logistical Issues

VI.              Support

VII.            Lack of Collective Decision-Making/ Faculty Input


I. Stability/ Performance


  1. Extremely poor performance record at beginning & throughout entire Spring 2004 rollout (see previous committee notes); resulting in user accounts being randomly kicked out of the system, weekly down times, slow access (pages taking up to 5 minutes to load), and denial of admin/design access during peak user hours (9am-5pm). Some schools that had migrated to Vista, chose to move back to CE, two weeks into the term.
  2. Poor performance at beginning of Summer; Poor performance record at beginning of Fall 2004 rollout -  resulted in down-time every day during first 7 days of classes – downtime of up to 5 hours on one day. File manager still experiencing intermittent slowness, for instructors/ designers/ trainers/ admin.
  3. eCore students enrolled in both eCore Vista courses and UWG’s CE courses continue to report degraded performance and higher occurrence of technical difficulties when using the Vista system as compared to the CE version. See attached “known issues” document.


II. Faculty & Student Usability


(see attached Known Issues document)


III. Network Concerns


1.      Bandwidth: If we have bandwidth issues between us and host, especially when on-campus students are in an in-lab testing situation....Who will address these issues? How quickly? (We have lots of faculty now who do all of their testing this way. We did have significant problems during the Fall term we were hosted on the USG server in Atlanta. The system office promises they will address the issue as it occurs.).


IV. Pipeline/ Banner Integration


1.      If WebCT is hosted somewhere else, how will it integrate with our Banner and Pipeline? How/ who will provide support to students and faculty? (The answer from the BOR thus far has been “we don’t know yet...” Promised we would be involved in testing – has not happened yet. Pipeline just released integrated component necessary for Vista, in …? )


V. Administrative/ Logistical Issues


1.      Archiving for long-periods: The CS department requested the ability to archive complete courses for up to 6 years, as a way of providing paperless archives of courses for accreditation review. The central office has provided minimal assurance regarding the ability or willingness to provide this service. Maximum file space or extenuating circumstances may necessitate that we or the CS dept be asked to pay additional fees associated with providing this space / service.  Without this assurance/ information, the CS department is reluctant to migrate to VISTA and instead continues to opt to use a free open-source tool called Moodle. Other departments, such as the Nursing Dept, are now also interested in this archiving possibility.

2.      Most USG institutions have very different academic calendars. If we are put on a central server then our downtime necessary for getting ready for the next term will be up to the centralized host & their timetable/ calendar.

3.      Archiving in general: Since there is no way for faculty to backup and restore on a course by course basis and there will be no separate archive server on to which we could move old courses, we would need to keep courses “live” for one year on the current active server. This means that students and faculty would see ALL course sections for which they taught or were enrolled for a period of one year (this is the way eCore works).

4.      Under our current set-up faculty can combine sections and teach multiple sections or cross-listed sections as one course; under Vista this is currently impossible. Though they are working on a solution, the current workaround involves manually loading one section and then having to load all other sections one student at a time. The template system in Vista is supposed to solve this issue but really does not because any additional files added at the template level do not propagate down to the course sections. (see Known Issue document).

5.      Lack of Communication: Repeatedly we have had issues where the central office told us one thing verbally, failed to follow-through, and then changed the rules without telling us. Still today, the central office can not tell us which of the two servers we will be hosted on (Ga State or UGA; Ga Southern is a test site).

6.      The association of templates at the course level makes the template public in 3.0 (other faculty designers then have access to all other faculty’s work automatically– see Known Issues document).




VI. Support


1.      Timeliness/ Quality of Support: There are tasks that our current UWG support infrastructure currently provides that we are not sure the off-campus host will provide. For example, currently if a faculty accidentally deletes information from their course, together with ITS we work to do whatever possible to restore that information within 48 hours. We will restore small parts of a course - like just the grades, or the lost bulletin board attachments. Will they be willing to do this, or will they only restore the entire course? In addition, our ITS often provides server log information upon request from faculty, regarding specific IP addresses and log files.  What will they do or not do? How quickly?

Normally when we pay a vendor for service & support, it includes service response times. If they had a document that outlined what they are willing to provide, and the timeframe for providing it, we might all feel better.

2.      Uncontrollables/ How another institution’s failings will impact us: One issue that has become apparent since my involvement in the eCore is that the central office has little control over the information the affiliate institutions provide or fail to provide. Example: Our ITS staff wrote a script to automatically pull registration data and send it to the central office for eCore enrollment/ WebCT enrollment purposes. The central office asked that all affiliates use this script and method; our ITS provided the instructions. A year later and the other affiliates are still sending in their registration data in different formats – one is even faxing hard copies that then have to be continually manually input almost daily. The result is that our students suffer because other affiliates’ ineptitude drains the central support staff’s time. According to our Registrar’s office, we had an exorbitant amount of eCore drops solely because the central office could not get their WebCt access activated fast enough, due to this logistical problem created by outside institutions.


VII. Lack of Collective Decision-Making/ Faculty Input


1.      Faculty Input: Many of the faculty have expressed concern that their voice regarding needs of themselves and their students will not be heard or adequately addressed by an outside host or the central office.

2.      Though many people have expressed concern over the entire centralization plan and forced upgrade to Vista as the sole USG platform, central office rep. Randal Thursby told reps in a phone conference that institutions will not be forced to upgrade until they deem the system competent but institutions would also not be allowed to fund any other course management alternative (EDP’s/ POs associated with supporting any other CMS would be denied).