Table of contents:
- Acceptable Use of ICON
- Statement on Privacy and Intellectual Property
- Who Can Request a Course?
- Requesting a Course
- What Ways May Courses Be Used?
- ICON User Roles and Associated Rights
- Creation and Maintenance of Rights and Roles
- Disk Space Management and Course Data Size
- Disaster Recovery
- Course Lifetime
- User Account Lifetime
- ICON Course Site and User Account Data
- Data Publishing
- Use Tracking
- Archiving and Backup
- Convention Development and Approval
- Convention Changes and Maintenance
- Storage and Distribution of the Handbook
The Handbook provides guidance for proper use of Iowa Courses Online (ICON). ICON includes the centrally supported Learning Management System (LMS), and integrations with other UI systems (e.g., integrations with the Student Information System (SIS), the UI Libraries, etc.).
Since the systems used to support ICON (such as the LMS) may change, an attempt has been made to describe ICON conventions and procedures in abstract form, independent of any particular software system.
Individual units within the University may define administrative conventions for the use of ICON within their unit. University-wide conventions and unit-specific conventions must be consistent in principle with enterprise conventions and with central University policies (https://itsecurity.uiowa.edu/university-it-policy), but unit-specific conventions may provide additional detail, guidelines or restrictions. There are some sections of the conventions document that should not be amended by individual campus units, as such a change would negatively impact the operation of ICON (e.g., Section III.G Naming). Requests for updates to these sections should follow the change process outlined in Appendix I. ICON Handbook Development and Maintenance. The ICON Core Team should be notified of any unit-specific amendments to the Conventions Handbook and such amendments should be made available to the team for review and comment.
Acceptable use of all ICON systems is governed by the University policy entitled “Acceptable Use of Information Technology Resources” found in Section II, Chapter 19 of The University of Iowa’s Operations Manual (available online https://opsmanual.uiowa.edu/community-policies/acceptable-use-information-technology-resources).
More specific descriptions of acceptable LMS use can be found below. Questions about usage not covered in these documents should be addressed to the Campus LMS Administrator at firstname.lastname@example.org.
ICON is infrastructure provided by The University of Iowa through the Office of Teaching, Learning & Technology in cooperation with the Office of the Provost. Placing content in ICON and using this tool for instruction raises issues related to ownership of copyrighted content within course sites, ownership of the course site, and the privacy rights of students who are using the course site. The following statements summarize the rights and responsibilities associated with ICON course sites:
- Placing content on an ICON server in no way alters the ownership of that content.
- Responsibility for administrative decisions concerning ICON course sites rests and assignment of administrative rights within ICON.
Departments and colleges are advised to consider the potential copyright implications of with the department or other unit responsible for the administration of the course for The University of Iowa. Such decisions include, but are not limited to: assignment of instructor rights through MAUI such decisions.
- The intellectual property policy in The University of Iowa Operations Manual at https://opsmanual.uiowa.edu/administrative-financial-and-facilities-policies/university-iowa-intellectual-property-policy.
- The University of Iowa Research Foundation web site at https://uirf.research.uiowa.edu/
Adding TAs and instructors to ICON courses has privacy implications for all students involved in the course. Instructors and TAs have access to class lists, grades, course specific communications and other information protected under FERPA. Instructors, ICON administrators, and collegiate and departmental administrators need to be aware of the FERPA implications of such an action and should consider potential privacy implications before adding
instructors or TAs to ICON course sites.
Some courses both face-to-face and those offered over the World Wide Web or via a course management system like ICON (powered by Canvas) may require the sharing of information like name, email address, phone, etc. with fellow classmates in order to facilitate classroom interaction. This sharing of information for such courses is not prohibited by FERPA, and it may be expected of all students, even for a student who has placed a block on directory information. Before enrolling in a course, students are encouraged to discuss any concerns they have regarding the sharing of this type of information with the instructor.
- The FERPA page at https://registrar.uiowa.edu/ferpa-handbook-faculty-and-staff
For more detail on student’s rights and the sharing of student information in a course, see the student records policy statement at https://opsmanual.uiowa.edu/students/treatment-student-education-records
The list of users presented here is not intended to be exhaustive. Instead, it represents current practice for providing space for an online course on University servers. As a general rule, it is up to the administrator creating the course to determine if the request for the course is legitimate and fits within the University’s Acceptable Use policy.
This is the largest group of course designers. It includes current, future, and emeritus faculty. While most courses for faculty designers will be courses known to the Student Information System (SIS), faculty may also be in charge of courses that fall outside the SIS (e.g., courses set up for research purposes or that offer staff training). Courses known to the SIS can be created either through the fully automated SIS integration for colleges which have selected that option (see Data Conventions > Integration for more details), or on a request basis. In addition, any faculty member may request an individual ICON course site. If the faculty member wishes to work on the course well in advance of the creation of the course through the fully automated method, s/he may request a development course (a course used for the development and testing of content but which will not have student enrollments).
UI Staff includes administrative assistants, program assistants, course coordinators, teaching assistants, research assistants, and IT staff. Courses for these users may be created by the fully automated system described above or they may be created on a request-only basis.
An ICON course may be created for UI students for class use (with written permission from the instructor). The student requesting an ICON course should be enrolled in classes at The University of Iowa. Student organizations are encouraged to use OrgSync (http://uiowa.orgsync.com/) from the Division of Student Life for online collaboration and document sharing.
A course created for users outside the UI community should only be created if the course adds value to the University community, and has a sponsor who is associated with the University of Iowa. Examples of valid reasons for creating courses for non-UI users are:
- instruction/coordination of programs with UI approval/support (International Nursing Association for Clinical Simulation and Learning),
- in-field instruction of UI courses and their support staff (the College of Business offers some courses that fit into this category),
- instruction of continuing education courses offered through a University of Iowa college (e.g., continuing education courses offered through Public Health).
Faculty and staff may request an ICON course by going to https://its.uiowa.edu/support/article/106761. This web page details how to request development courses, test courses, and courses that are tied to a University of Iowa Registrar’s course. The faculty or staff member may also directly contact his/her Collegiate Administrator (if one exists) or he/she may submit a request to the Campus Administrators (http://its.uiowa.edu/contact).
Since UI Students may have designer access to a course only by faculty approval, student requests should come through a faculty member. As above, this request can go either to the appropriate Collegiate Administrator or to the Campus Administrators.
Note that, since all ICON administrators have the right to create ICON courses, they also have the responsibility to ensure that the request meets the criteria required for course creation. This may involve contacting references identified on the ICON Course Site Request form submitted by the requester.
Traditional courses are aligned with official UI courses, both semester-based and non-semester based (e.g., continuing education, cohort classes, etc.) courses. Other uses would include staff training, student/faculty/staff organizations, continuing education courses offered through a college or other unit that is not aligned with an official UI course or non-student organizations with some University recognition or affiliation and research. Creation of those courses should be governed by the University’s Acceptable Use policy (available online at https://opsmanual.uiowa.edu/community-policies/acceptable-use-information-technology-resources).
ICON user roles and associated rights fall into five basic categories: (1) administrators, (2) support staff, (3) course designers/instructors and teaching assistants, (4) students, (5) custom roles.
While multiple individuals may hold the same role, as a general rule, it is advisable to keep the number of administrators low. Colleges are encouraged to review their role assignments for the first three categories on an annual basis. Section II-F Creation and Maintenance of Rights and Roles provides guidelines related to these procedures. Visit https://its.uiowa.edu/support/article/106816 for details on specific permissions for roles in ICON.
Note: Changes and amendments to the user roles and associated rights should only be made through the Handbook maintenance process outlined in Appendix I. ICON Handbook Development and Maintenance.
Users with ICON administrator roles are responsible for the day-to-day tasks related to course site and user account maintenance in ICON. While Office of Teaching, Learning & Technology (OTLT) staff are responsible for administration of the entire system, administrative rights are also granted to individuals around campus to support their colleges or departments.
Administrative rights are intended for instructional or support staff who work with instructors using ICON. Based on guidance from University General Counsel, this level of access is not available for those with a position of authority over instructors. Deans, Associate Deans, DEOs, or others with authority over instructors should seek approval from all instructors in their area to be granted elevated access in ICON.
There are three levels of ICON Administrators:
- Campus Administrator: Centrally-based at OTLT. Serves as coordinator for Collegiate Administrators and general administrator for groups without Collegiate Administrators. Can act as authority in case of conflict with Collegiate Administrators or other users.
- Collegiate Administrator Level 1: Elected by a college, division, or department to take responsibility for that group’s ICON course sites and body of users. High level of responsibility, administrator rights at the college level and instructor rights at the course level.
- Collegiate Administrator Level 2: Elected by a college, division, or department to take responsibility for that group’s ICON course sites and body of users. Medium level of responsibility, instructor rights at the course level.
Support staff are UI staff members responsible for verifying the contents of ICON course sites or testing sites from a student perspective.
There is one level of Support Staff access:
- Level 1: Can view all content and activity on an ICON course site, including enrollment and grade information. The intent of this role is read-only access, though the role may have some create/edit rights, based on how granular permissions can be for a given tool. Note that this level of access requires completion of FERPA training.
This category includes both the main designer/instructor for a course and Teaching Assistants for that course. The meaning of the rights
- Teacher: Has primary responsibility over content, activity, and student data in an ICON course site. This is usually the course instructor, but it may also be a support person or a graduate assistant.
- TA: Charged with teaching a section of a multi-section course with some autonomy. Some
- aspects are up to the TAs discretion; others are consistent among all sections of course. There is a course supervisor.
- Course Designer: Creates content and course structure (assignments, discussion forums, quizzes, etc.) but does not grade student activity.
A student is defined as a non-instructor and non-teaching assistant participant in an ICON course site who may or may not be a UI student. A user with the student role in ICON has the following rights:
- may use all ICON tools as implemented in a course by the instructor/designer, college, division, or department,
- when allowed by the course designer, may submit electronic documents to applicable ICON course sites.
A second class of student account is the Guest Student. This is a user who is external to the University of Iowa and has a guest hawkID account that is eligible for the ICON service.
A custom role may be created at the discretion of the Campus Administrators. Ideally, the role will be based on a pre-existing role with some small adjustments. For full details on the processes and conventions surrounding the creation of custom roles, see Creation and Maintenance of Rights and Roles below.
A user may request a role change if the current role is not sufficient. The request for role re-assignment should be addressed to an ICON administrator.
The administrator will examine the available roles according to the User Roles and Associated Rights section to determine if any of the pre-existing roles fit the situation. If greater rights are being requested (TA Level 2 rights to Instructor/Designer rights), the administrator should get written approval of the supervising body (an e-mail from the current course supervisor for example) before upgrading the user’s role. Note: non-administrative users requesting upgrades to administrator rights must meet the requirements for administrator rights listed below.
It may be determined that there is no existing role that meets the needs of the user. In this case, a request is made of the Campus Administrator for the creation of a new custom role. The Campus Administrator will take one of the following courses of action:
- The Campus Administrator will examine existing roles to see if a minor change could fulfill the user’s needs while causing little or no impact on other users with that role, in which case the Campus Administrator would make a change for all users with that role.
- If the impact of changing an existing role is deemed too great, the Campus Administrator may create a new role to suit the needs of the requester. Because that role would then be a possibility for other users, the Campus Administrator should try to use generic terminology when labeling the role (e.g., “Level 2 + TA” as opposed to “Chemistry 201 TA”).
Since each additional role adds complexity to the system, the Campus Administrator may decide to deny the request and assign the user to an existing role with no changes.
System administrators are responsible for ensuring data consistency across the entire system, including user account IDs, course IDs and the minimum meta-data collected for any user or course. Individual groups may collect additional data.
Integration efforts can assist in the enforcement of naming and data collection conventions.
Anyone seeking rights at an administrative level within ICON are required to meet the following training and eligibility requirements:
- an approved workflow form on file with the Campus Administrator, signed by the appropriate College IT director,
- completion of FERPA training,
- completion of training on the administrative functions of ICON,
- completion of training on the administrative conventions laid out in this handbook.
Additionally, administrators will be expected to remain current on the product, participating in continuing training when available, including regular attendance at ICON Collegiate Administrator meetings.
Due to security concerns and the need to maintain a close relationship between the Campus Administrators and the Collegiate Administrators, Collegiate Administrator appointments will be reviewed annually. Notifications will be sent to the college Deans requesting verification of the current list of Collegiate Administrators. A lack of response to these requests may result in cancellation of Collegiate Administrator rights. Colleges who participate in ICON collegiate administration are encouraged to inform the Campus Administrator of any changes in Collegiate Administrator appointments for their college as soon as they happen.
The complete schedule for Collegiate Administrator verification is as follows:
There are currently no disk space limits for courses. However, instructors/designers should consider placing very large content files on alternate servers (for example, the Learning Object Repository or a video streaming service) and simply placing links to those files in their ICON course sites. Instructor/designers are encouraged to contact the ICON support team to discuss storage options.
The ICON Administrative team, is responsible for monitoring ICON disk use. If disk space runs low, one of the following actions may be taken to alleviate the problem:
- Perform an audit of ICON disk use to determine if there are large files that can be moved onto other centrally-supported services (or the LOR). If there are:
- contact the course instructor and suggest the move;
- work with other OTLT staff, as needed, to facilitate the move of the data with minimal disruption to the instructor or students.
- Determine if there are any ICON course sites that can be removed from the system. If there are, the removal of those sites should follow processes laid out in the Archival and Backup section of this document.
- If the above remedies fail to address the problem, the ICON Administrative Team will work with the vendor to provide additional storage.
Disaster recovery for ICON will conform to the institutional Backup and Recovery policy found on the CIO’s web site at https://itsecurity.uiowa.edu/policy-backup-recovery.
ICON course designers are strongly encouraged to keep local copies of as much of their course content as possible to facilitate system recovery in the event of a disaster that causes loss of course site data. Additionally, the vendor will regularly back up ICON data to facilitate recovery in the case of complete system failure.
Contact the Campus Administrator for details of the backup and recovery conventions for ICON.
Policy Gap: The Course Lifetime conventions presented here are provided in lieu of a University of Iowa policy. This document will be revised to adhere to such a policy when it is created. See the Archival and Backup section for additional information on data persistence responsibilities.
Definition: Course re-offering is the process of creating a new instance of a course for a new set of students students. The new instance of the course site is created, either by request or through an automated process (see Integration for details). Then, using ICON’s course-editing tools from within the new course site, the instructor copies some or all components from the previous instance of the course site.
If technically possible, a retired course may also be re-offered. The University of Iowa instructor requests the restoration of the course into ICON. Once the course has been restored to the server, the instructor.
Instructors can control how and when their courses are available to students by adjusting settings within the course. Visit https://its.uiowa.edu/support/article/107456#Course for details on how to control student access to your course.
Definition: The process of retiring an ICON course site includes making a copy of the course site data and removing the site from the system.
The core strategy related to this convention is communication. Nothing will be done with respect to retiring an instructor’s course space without making every effort to confirm that the course may be retired. That being said, the intention is to retire a course two years after the date of the last enrollment into the course. The instructor will receive communication from the ICON Administrative Team at least three months prior to ICON course site retirement to notify him/her that the ICON course site will soon be retired and offering the opportunity to extend the course’s life time. It should be noted that there is a difference between extending an ICON course site’s life time and re-offering that course in a new ICON course site. See ICON Course Site Re-Offering for further details.
If, after the time has expired, the instructor has not requested additional life for the course, the course will be “retired.” The instructor will be contacted 1-2 working days prior to the ICON course site retirement to provide time for the instructor to archive any desired data. Then the course will be archived by the ICON Administrative Team according to the conventions outlined in Archival and Backup (including removing the course from the ICON system).
The complete schedule for ICON course site retirement is as follows:
Technical Gap Statement: The above procedure depends on a feature that is not yet available in ICON. We are working with the vendor to resolve this issue.
ICON User accounts remain eligible for ICON as long as the user is enrolled at The University of Iowa and has been enrolled in an active ICON course site within the last semester.
Definition: Non-UI User Accounts are for students who are not enrolled in registrar-affiliated courses and have a guest hawkID account.
Guest hawkID accounts will lose service eligibility one year after the account was created.
This section describes the minimal set of data that is kept in ICON. The publication of data should always conform to FERPA requirements (see Data Publishing below).
ICON contains the following user data:
- user ID (See Naming for user ID formats),
- first and last name, and
- university ID.
ICON contains the following course site data:
In accordance with FERPA regulations, no personal user information, except individual directory information, should be publicly available in ICON. Examples of individual directory information that can be published include first and last names, e-mail address, and HawkIDs. Students may file “Request to Withhold Student Information” documents, which further restrict publication of their data. Other user data, such as course .enrollment, active/inactive status, university ID number, and grade data, may be collected but will not be publicly available. See FERPA for Faculty and Staff https://registrar.uiowa.edu/ferpa-handbook-faculty-and-staff for details
The use of common ID conventions by all ICON administrators prevents confusion and conflict.
There are two main types of ICON user IDs. The most common is the HawkID, assigned to all faculty, staff and students at the University of Iowa. The other is the service ID. This ID, distinguished by an underscore character (_), grants access only to the ICON system.
The service ID format is defined below.
- Admin Service ID
- These IDs are for elevated access within ICON, follows the naming conventions of the serviceID hawkID service.
- Service accounts: <service_ID>_username
- These IDs are associated with a particular service or integration, and <service_ID> identifies the service.
There are two types of course sites for which IDs are created: academic and non-academic. Academic course sites can be session-based, non-session or development.
Non-academic course sites can be test/training or other.
Academic course site IDs
- Session-based course sites: These are course sites’s related to specified sessions that are known to the registrar. The format for the course site ID is: d_c_s_yS
- d: The full department code for the course. This can vary in length as defined by the Registrar (e.g., RELG).
- c: The full course code.
- s: The full section code.
- y: The four digit year in which the course is being offered.
- S: The session identifier for the course.
- Non-session course sites: These are course sites that are offered by The University of Iowa but have no definite session identifier. An example of this type of course site would be a Guided Independent Study course site. The format for these course site ID is: d_c_s_#
- d: The full department code for the course. This can vary in length as defined by the Registrar (e.g., RELG).
- c: The full course code.
- s: The full section code
- #: An alpha-numeric value that makes the course site ID unique within ICON.
- Development course sites: These are course sites created to allow instructor-designers to prepare content for an academic course prior to the creation of a session-based course site for that instructor. The format for the course site ID is: d_username_# d:
- The letter d, indicating a development course,
- username: The HawkID of the instructor-designer requesting the course,
- #: An alphanumeric value to create a unique course site ID.
Non-academic course site ID
Test/Training course sites: these are course sites created for ICON testing or training. The format for the course site ID is: t_username
- The user name can correspond to the user’s ICON ID.
- This course is not intended to provide staff training on specific topics unrelated to ICON but only for testing and training on the ICON system itself.
Other course sites: these are course sites created for specific service units engaged in faculty/staff training or other activities. One example would be staff training courses offered by UIHC. The format for the course site ID is: <service_unit_ID>###.
- The service unit ID is a string identifying the service unit for whom the course was created.
- The ### is a 3 digit value that uniquely identifies the ICON course.
Technical Gap Statement: The above conventions do not apply when ICON course sites require enrollment integration with other UI services. For those course sites, the following course site ID format is used: o_dc_S
- o: The Canvas Sub-account code into which the course offering and course template is to be placed. For example: DOE (Division of Online Education), or RELG (Religion).
- d: The full department code for the course. This code is typically defined by the Registrar and can vary in length from 2-4 characters. For example: 037 or RELG.
- c: The full course code, which may be followed by a character (a, b, c, etc.) to ensure a unique course site ID.
- S: The session ID code, as defined within ICON. This indicates where the course will be placed within ICON’s hierarchy. For example, 20053 (Fall 2005) or ONGOING (for courses that are not based on a particular session).
Note that the course site ID is divided into three groups delimited by underscores (_). This allows ICON to correctly parse the course site ID and create the correct mapping between a particular ICON course site and the appropriate UI course.
The course title identifies an ICON Course Site and provides information about the course content. The title typically appears at the top of the home page for the course site and in the list of courses that a user can access from the My ICON view. Users who change this content should ensure the new course title uniquely identifies the course site.
Academic Course Site Titles
- Session-based course sites. The elements of these course site titles are: d:c:s <Session> <descriptive title>
- d: The full department code for the course (e.g., 032 or RELG).
- c: The full course identifier.
- s: The full section identifier.
- <Session>: A string of characters that describe the session in which the course is being taught (e.g. Spr 04). The session name is abbreviated to keep the title length to a minimum. Recommended session strings are: Smr, Fall, Wntr, and Spr.
- <descriptive title>: The name of the course as listed in The University of Iowa course catalog.
- Non-session based course sites. The elements of these course site titles are: d:c:s <descriptive title> (<instructor>) d: The full department code for the course (e.g., 032 or RELG).
- c: The full course identifier.
- s: The full section identifier.
- <descriptive title>: The name of the course as listed in The University of Iowa course catalog.
- o <instructor>: The name of the primary instructor teaching the course. Because these courses are not session based, this may be useful in distinguishing between courses.
- Development course sites. The elements of these course site titles are: <descriptive title> (For Development Purposes Only)
- <descriptive title>: Any string of characters that is relevant and useful to the instructor.
- (For Development Purposes Only): This string of characters reminds the instructor that this course is just a place to develop content and should not be activated for student use.
Non-academic Course Site Titles
- Test/Training courses. The elements of these course site titles are: [Test|Training] [#|<description>] (<instructor name>).
- [Test|Training]: Either “Test” or “Training.”
- [#|<description>]: Text to distinguish the course site from all other test/training course sites.
- <instructor name>: The name of the person with instructor-designer rights to the course.
- Other course sites. The elements of these course site titles are: <course site ID> <descriptive title> (<instructor name>).
While it is not required that a particular course title be unique, it is often helpful to other ICON users.
ICON course sites can be created upon demand by instructors (and others). Alternatively, a College or department may request that an ICON course site be automatically created for each course listed in the University course catalog for that College or department.
Course sites created upon request
To request an ICON course site, an instructor goes to https://its.uiowa.edu/support/article/106761. The site explains the types of ICON course sites the instructor may request and provides links to submit the requests. The requester will be required to log in using HawkID and password and will then be allowed to submit a request for an ICON course site.
If the requested ICON course site is related to a course in the UI student information system (SIS), the course will normally be created by an overnight process and available to the instructor the following day. If the requested course site is not related to a course in the SIS, the request will be forwarded to and processed by an ICON administrator.
Course sites created automatically
A College or department may choose to request the automatic creation of an ICON course site for each of its UI courses known to the SIS for which the instructor is known to MAUI. This process would start on an agreed-upon date. To take advantage of this option, the College or department should send an e-mail message to email@example.com. Note that the creation of an ICON course site, by itself, does not require that the course site be used by the instructor. The course site is not available to students until the instructor enables that access.
For users who do not have HawkIDs but who need access to ICON, administrators have the right to create guest hawkID user accounts. These accounts can be created one at a time by filling out an online form.
An automatic process creates the course site, adds the instructor to the course site, and adds the course site to the list of courses that is automatically populated with students based on SIS data.
Colleges and departments may elect Fully Automated Course Creation and Enrollment. In this case, the instructor-designer is automatically added to the course when the course is created. Additionally, the course sites are automatically populated with students based on SIS data.
Other methods of populating course sites with students include:
- The instructor-designer for the course performs a batch-upload of a file of student records.
- The instructor-designer requests a self-registration system be set up for the particular course. Self registration allows a user to request access to a course site by filling out an online form.
- The instructor-designer requests a custom integration. The integration requirements are worked out between the instructor-designer and the ICON Integration Team.
It should be noted that, in any case, the students in an ICON course site will not see the course site until the instructor activates the course.
An integration, as the term is used here, enables ICON to communicate with other vended products, with campus systems, e.g., Evaluation and Examination Services. Integrations are created by the ICON Integration Team, or by external developers with assistance from the ICON Core Team.
Integrations with external, 3rd-party vended tools will need to be approved by the Technology Review Process: https://its.uiowa.edu/campus-software-program/technology-reviews.
The ICON Core Team ensures that integrations work with all product upgrades and will contact non-OTLT integration developers to inform them of planned upgrades.
Information on system use is gathered in the following ways:
To provide for error recovery, course and user creation activity is logged. Administrators can gather data on the methods used to add users and courses to the system (e.g., custom administrative interfaces, administrative tools provided by the system, or interactions with UI’s back-end systems) and can determine who is creating what types of accounts (guest student accounts, TAs, instructors, etc).
Login records include time of login and success or failure of the login.
To identify ICON course sites which are actively being used (not just marked as available for use by the instructor-designer), ICON course site use is monitored. Course site monitoring also tracks how course sites are being used (what tools are actively being used and not just marked as available), how long a student spends in a particular ICON course site, and the amount of data stored in an ICON course site. This data is used to generate reports for the system as a whole or by college or department.
Archiving and backup of ICON files are governed by The University of Iowa’s policy on Backup and Recovery (https://itsecurity.uiowa.edu/policy/policy-backup-recovery.shtml).
- Backup – a periodic, automated, system-wide process that makes a copy of the state of the system at the time of the backup and stores that copy on an external medium (e.g., tape storage).
- Archive – a copy of data related to a particular course. Archives may be created manually at any time by either the instructor or ICON Administrators. This process is also automatically performed by OTLT when preparing to remove a course from the ICON system.
- The LMS vendor is responsible for performing regular backups of the system. This form of backup is useful for catastrophic system failures (disk failure, system crash, etc). Restoration of data from such a backup is an all-or-nothing proposition. This process does not allow for restoration of individual files.
- OTLT is responsible for archiving course and user data prior to its removal from the system. Data is stored on a permanent, external medium such as a CD or DVD. The usefulness of the archive data is temporary; changes in the ICON system will make older archives obsolete and make it impossible to fully restore the courses to the system.
- Instructor/Designers of ICON course sites are responsible for keeping backup copies of online course data.
- All users of ICON are responsible for keeping backup copies of data uploaded into ICON by them.
If a course is designated for retirement from the system (see Course Lifetime for more information), the following archiving process will be used:
- Instructor/designers in the designated courses are notified. See the ICON Course Site Retirement section of this document.
- The following elements are archived by OTLT prior to course removal:
- Sufficient data to re-create the course on the system.
- A comma-separated values (CSV) file of the data in the gradebook tool will be captured as part of the archive.
- The archive is stored on an external medium such as a CD or DVD.
It is the instructor’s responsibility to make a copy of sufficient data to handle grade challenges that may occur after the completion of the course. The format of the data must be sufficiently general so it can be viewed independently of ICON.
The frequency of ICON data backups is governed by The University of Iowa Chief Information Officer’s data backup and recovery policy (https://itsecurity.uiowa.edu/policy/policy-backup-recovery.shtml) and the Service Level Agreement (SLA) between the vendor and the University of Iowa. This data backup represents OTLT's due diligence with respect to backup and recovery in the case of disaster or hardware failure.
Archives will be created for courses by OTLT only when the course is to be retired.
ICON course site instructor/designers should regularly make personal backups of the data in their course(s) to ensure their course data can be retrieved.
Technical Gap Statement: ICON currently does not support the ability to create individual archives of specific courses. Until that feature is available, it is strongly recommended that instructor/designers and students keep local copies of all data placed in the course.
The ICON Core Team is responsible for developing and describing conventions for the administration of ICON systems and technologies at The University of Iowa.
Such conventions must be consistent with the University’s enterprise IT policies, as specified by the IT Security & policy Office (https://itsecurity.uiowa.edu/policy/ITdevelopment.shtml), but may also provide additional detail, guidelines, or restrictions.
ICON conventions are developed, approved, and maintained through the following procedures.
Convention drafts are developed by the ICON Core Team, or by other ICON Project teams with input from the ICON Team. Drafts are reviewed by the ICON Steering Committee and the Academic Technology Advisory Council. The ICON Core Team decides the next step for a draft convention (accepting it, rejecting it, soliciting input from external parties, etc.). Once approved, the conventions are distributed to the public.
Requests to change or update conventions are submitted by users (e.g., University students, faculty, or staff) or by University employees involved in the ICON project. Change requests are reviewed by the ICON Core Team, in consultation with other ICON Team members. Amended convention statements are passed on to the ICON Steering Committee as specified in section A.
Written documents are produced to clearly define all conventions. The Handbook is available to the public on the ITS web site, along with any other necessary documents (e.g., training and documentation). The Handbook is available in an accessible HTML format.
Document Revision History
|3/01/05||1a||Initial Layout/Partial Draft||David Priebe|
|3/07/05||1b||Full Rough Draft||David Priebe|
|3/12/05||1c||Incorporated ICON Conventions Handbook Core Team comments. Added new rights tables created by Aprille Clarke.||David Priebe|
|3/18/05||1d||Incorporated wording changes suggested by ICON Core Team.||David Priebe|
|4/5/2005||1e||Updated with changes as suggested by the Review Team||David Priebe|
|4/27/2005||1f||Updated to reflect content changes suggested by project and review team. Added Intellectual Property section||David Priebe|
|5/3/2005||1g||Updated to reflect content changes suggested by the Project team.||David Priebe|
|5/4/2005||1h||Updated Rights and Roles section.||Aprille Clarke|
|5/18/2005||1i||Review team changes.||David Priebe|
|6/17/2005||1j||Further corrections||David Priebe|
|7/5/2005||1k||Update rights and roles||Aprille Clarke|
|9/6/2005||1l||Update sections for correctness. Technical gap added to Course ID section.||David Priebe|
|12/14/2005||1m||Added an abridged version. Added summary paragraphs to some sections to facilitate shortening the document. Made an editing pass of the abridged document for clarity.||David Priebe, Phil Potter|
|8/28/2006||1n||Made an editing pass of the document for clarity.||David Priebe, Phil Potter|
|11/16/2009||1n.1||Updated broken links in document.||Dave Long|
|03/30/2010||1o||Updated language in Section B, Part 2 to reflect updated language from Division of Student Services regarding shared student information in LMSs.||Dave Long|
|11/10/2014||1o.1||Updated language in Section II, Part D.1 to reflect updated course request tools.||Vicky Maloy|
|11/30/2016||1o.2||Updated broken links in document.||
|03/01/2018||1p||Editing pass for clarity, updated Rights and Roles section to reflect Canvas, updated broken links.||Dave Long|