ICON Administrative Conventions and Procedures Handbook

Table of contents:

  1. Introduction

  2. ICON End User Conventions​​​​

    A.    Acceptable Use of ICON

    B.    Statement on Privacy and Intellectual Property

    C.    Who Can Request a Course?

    D.    Requesting a Course

    E.    What Ways May Courses Be Used?

    F.    ICON User Roles and Associated Rights

    G.   Creation and Maintenance of Rights and Roles

  3.  Data Conventions

A.   Disk Space Management and Course Data Size

B.   Disaster Recovery

C.   Course Lifetime

D.   User Account Lifetime

E.   ICON Course Site and User Account Data

F.    Data Publishing

G.   Naming

H.   Integration

I.     Use Tracking

J.    Archiving and Backup

Appendix I. ICON Handbook Development and Maintenance

A.    Convention Development and Approval

B.     Convention Changes and Maintenance

C.     Storage and Distribution of the Handbook

 

I. Introduction 

 

    The Handbook provides guidance for proper use of Iowa Courses
    Online (ICON). ICON includes the centrally supported Course Management System (CMS), 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 CMS) 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. These conventions must be consistent in principle with enterprise conventions and with central University policies, but 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 Handbook 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.

    II. ICON End User Conventions

    The following conventions and procedures describe best practices for using ICON, including the rights and responsibilities assumed by users.

    A. Acceptable Use of ICON

    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 CMS use can be found below. Questions about usage not covered in these documents should be addressed to the Campus CMS Administrator at its-helpdesk@uiowa.edu.

    B. Statement on Privacy and Intellectual Property

    1. Intellectual Property

    ICON is infrastructure provided by The University of Iowa through ITS 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.

    For more information on copyright issues go to:

    2. Privacy

    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 Desire2Learn) 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.

    For more information about FERPA issues go to:

    C. Who Can Request a Course?

    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.

    1. UI Faculty

    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).

    2. UI Staff

    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.

    3. UI Students

    An ICON course may be created for UI students for class use (with written permission
    from the instructor) or for assistance in the organization of student government and other student organizations. The student requesting an ICON course should be enrolled in classes at The University of Iowa.

    4. Non-UI Users (No HawkID)

    A course created for users outside the UI community should only be created if the course adds value to the University community. 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).

    D. Requesting a Course

    1. UI Faculty, TAs, Staff and Non-UI Users (No HawkID)

    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).

    2. UI Students

    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.

    E. What Ways May Courses Be Used?

    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).

    F. ICON User Roles and Associated Rights

    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.

    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.

    1. ICON Administrators

    Users with ICON administrator roles are responsible for the day-to-day tasks related
    to course site and user account maintenance in ICON. While ITS 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.

    There are four 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 and rights
    • Collegiate Administrator Level 2: Same as Level 1, but with a medium level of responsibility and rights
    • Collegiate Administrator Level 3: Same as Levels 1 and 2, but with a low level of responsibility and rights.
    • Rights Table:

    ROLE

    Central Admin

    Collegiate Admin

    LEVEL

    n/a

    L1

    L2

    L3

    TASK SET

    ICON Course Site and User Creation and Maintenance

    Create and maintain ICON course sites

    X

    X

    X

    X

    Use all ICON tools as permitted by University of Iowa Acceptable Use policy

    X

    X

    X

    X

    Create and maintain ICON user accounts, assign users to course sites

    X

    X

    X

    X

    Remove users from course sites

    X

    X

    X

    X

    Grant and maintain all roles below his/her own, including co-designer/co-instructor status

    X

    X

    X

     
    Delete ICON course sites from server

    X

    X

       
    Coordinate archival of ICON course sites

    X

         
    Use the impersonation tool in order to provide support to main instructor-designer.

    X

    X

       
     

    Communication Issues

    Issue escalation: contact vendor support, including on behalf of Distributed Administrators

    X

         
    Issue escalation: Escalate issues by communicating with Head Administrator  

    X

    X

    X

    Within appropriate org unit(s), make announcements to users regarding issues of specific interest that audience

    X

    X

    X

    X

    Within appropriate org unit(s), manage shared assets using Learning Object Repository

    X

    X

    X

     
    Run reports on ICON use

    X

    X

    X

     
     

    Hardware, Software, and Application Administration

    In conjunction with other groups (SPA, AIS, Distributed Administrators,
    advisory groups), make decisions regarding hardware, software,
    or other product-related upgrades or configuration changes

    X

         
    Serve in an advisory capacity to Head Administrator regarding hardware, software,
    or other product-related upgrades
     

    X

       
    Make administrative and structural changes to the use of ICON, such as role creation
    or adjustment, template deployment, organizational unit creation and maintenance

    X

         
     

    Template Creation and Deployment

    Create, maintain, and deploy navigation bar templates

    X

         
    Create, maintain, and deploy course content templates

    X

    X

    X

    X

    Deploy pre-created templates

    X

    X

    X

    X

    2. Support Staff

    Support staff are UI staff members responsible for verifying the contents of ICON course sites or testing sites from a student perspective.

    There are three levels of Support Staff:

    • Level 1: Can view all content and activity on an ICON course site, including enrollment and grade information. This is read-only access, the purpose of which is to verify enrollments and functionality. Note that this level of access requires completion of FERPA training.
    • Level 2: Can view activity on the site including communication tools, site content and enrollment information but cannot view the gradebook. Like level 1, this level of access requires completion of FERPA training.
    • Level 3: Can view all instructor-created content in an ICON course site, but not content that is in any way tied to a user ID (e.g., grades, classlist, discussion board posts, dropbox). This user does not require FERPA training.
    • Rights Table:

    ROLE

    Support Staff

    LEVEL

    L1

    L2

    L3

    TASK SET

    ICON Course Site Use

    View ICON course site content (e.g., documents, news postings, public calendar items)

    X

    X

    X

    View ICON course site communication tools (e.g. chat logs, discussion board posts, dropbox)

    X

    X

     
    View ICON course site enrollment information

    X

    X

     
    View ICON course site gradebook for the purpose of testing functionality or visibility

    X

       

    3. Course Designers/Instructors and Teaching Assistants

    This category includes both the main designer/instructor for a course and
    Teaching Assistants for that course. The meaning of the rights
    levels are:

    • Instructor-Designer: 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.
    • Instructor: Has responsibility over the day-to-day teaching of the course, but the actual content is managed by a different user.
    • TA-Designer: Charged with teaching a section of a multi-section course with a high level of autonomy. There may be little or no consistency among multiple sections, though there may be a course supervisor.

    • TA (High Level): 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.
    • TA (Low Level): Charged with aiding the primary instructor in maintenance tasks associated with an ICON course site.
    • Rights Table:

    ROLE

    Instructor-Designer

    Instructor

    Teaching Assistants

    LEVEL

    n/a

    n/a

    TA-Designer

    L1

    L2

    TASK SET

    ICON Course Site use

    Implement and customize all ICON toolsin
    accordance with University of Iowa Acceptable Use policy, and College
    and Departmental policies

    X

     

    X

       
    Implement, customize and manage the communication tools (e.g., chat, discussion boards,
    whiteboards, internal mail, dropbox)

    X

     

    X

    X

     
    Manage the communication tools (e.g., chat, discussion boards, whiteboards,
    internal mail, dropbox)

    X

    X

    X

    X

    X

    Implement, customize, and manage the quiz and survey tools

    X

     

    X

       
    Use the quiz/survey tool to read and evaluate student responses

    X

    X

    X

    X

    X

    Implement, customize, and manage the classlist and gradebook tools

    X

     

    X

       
    Customize gradebook setup

    X

     

    X

    X

     
    Enter grades into gradebook

    X

    X

    X

    X

    X

    Make available electronic content (self-authored
    or via library integrations) for student use; share resources with
    other instructors or teaching assistants using the Learning Objects
    Repository

    X

    X

    X

       
    Customize the look/feel of the ICON course site as permitted by college, division,
    department, or organizing course.

    X

     

    X

       
     

    User enrollment and statistics

    Use ITS-developed integrations for studentand teaching
    assistant enrollment

    X

     

    X

       
    Remove users from course sites

    X

     

    X

       
    Enroll and use testing ID (simulated student)

    X

    X

    X

       
    Use reporting tools within ICON course site for student use and progress tracking

    X

     

    X

       

    4. Students

    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 account. This is a user who does not have a HawkID and authenticates directly into ICON. In addition to the rights listed above, this user can update his or her password within the ICON application.

    5. Custom Roles

    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.

    G. Creation and Maintenance of Rights and Roles

    1. Procedure for Changing Roles, Rights, and Creating New Roles

    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.

    2. Data Consistency and Conventions

    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.

    3. Requirements for Collegiate Administrator-level Rights

    Anyone seeking rights at an administrative level within ICON are required to meet the following training and eligibility requirements:

    • a letter 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:

    Time Frame Action
    At the beginning of each academic year. A request for verification of Collegiate Administrator(s) is sent to the deans of all colleges who participate in ICON collegiate administration.
    1 month after the initial notification. If no response has been received to the first request, a second notification is sent to the college deans requesting verification of Collegiate Administrators.
    1 week after the phone call is placed. If no response has been received, Collegiate Administrator rights are removed for that College.

    III. Data Conventions

    A. Disk Space Management and Course Data Size

    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 streaming server) 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, in conjunction with Systems and Platform Administration (SPA), 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 SPA to provide additional storage.

    B. Disaster Recovery

    Disaster recovery for ICON will conform to the institutional Backup and
    Recovery policy found on the CIO’s web site (http://cio.uiowa.edu/Policy/policy-backup-recovery.shtml).

    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, ITS Systems and Platform Administration (SPA) 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.

    C. Course Lifetime

    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.

    1. ICON Course Site Re-Offering

    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.

    Technical Gap: Because we are unable
    to archive a course on the server we are unable to test, within ICON, how
    this course could be restored onto the system.

    2. ICON Course Site Deactivation

    Definition: The course site is made unavailable to students but remains
    on the ICON server and is visible to the instructor of the course.

    Time Frame Action
    12 months after the completion date for the course The instructor is notified, via email, that the course site will be deactivated in 1 month.
    1 month later If the instructor has not replied,,the course site is deactivated. (The instructor may over-ride this.)

    On every anniversary of the end date of the course, if the instructor has re-activated the course site, the above process is repeated.

    3. ICON Course Site Retirement

    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:

    Time Frame Action
    2 years after the the last student enrollment in the course site A notification is sent to the instructor, via email, stating that the course will be retired in 3 months.
    1 month later If no response to the above note is received, a second e-mail note is sent to the instructor stating that the course will be retired in 2 months.
    2 months after the first note If no response is received, a third e-mail note is sent to the instructor stating that the course will be retired in 1 month.
    1-2 working days prior to retiring the course site If no response is received, a final e-mail note is sent to the instructor, stating that the course will be retired. The note will remind the instructor to back up any content in the course.
    1-2 working days later If no response has been received, the course site is retired (archived and removed from the ICON system).

    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.

    D. User Account Lifetime

    Policy Gap: The User Account 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.

    ICON User accounts remain active as long as the ICON user is enrolled at The University of Iowa and has been enrolled in an active ICON course site within the past six months.

    1. UI User accounts in ICON

    Definition: UI User accounts in are for users who have HawkIDs.

    2. Non-UI User Accounts

    Definition: Non-UI are for students who do not have a HawkID.

    Since these accounts exist only in ICON, they will remain on the server indefinitely, with the exception test-student accounts, which are created for an individual instructor and last as long as the instructor’s HawkID is valid.

    Since non-UI user accounts have an impact on ICON licensing costs , it is necessary to keep track of them. ID Non-UI user accounts remain active until 12 months after the last log-in.

    E. ICON Course Site and User Account Data

    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:

    • course ID (See Naming for the course ID formats) and
    • course requestor ID.

    F. Data Publishing

    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.

    G. Naming

    The use of common ID conventions by all ICON administrators prevents confusion and conflict.

    1. User ID Format

    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 guest user ID. This ID, distinguished by an underscore character (_), grants access only to the ICON system. It is for users whose only affiliation with the University of Iowa is through the use of ICON.

    The guest user ID formats are defined below.

    • Test student account: t_hawkid
      • This account is created for a course instructor. It allows the instructor to view the course data as a student for the purpose of testing the course.
      • It should be noted that this account is specific to a particular instructor, not to a course. This account could be registered into several courses taught by the same instructor.
      • This ID is created upon an instructor’s request.
      • At the time the ID is created, a random password for the account is generated and sent to the instructor. The instructor is strongly encouraged to change the password immediately.
    • Guest User: g#_FLastname
      • This ID begins with a g followed by a number which is used to differentiate the ID from IDs of users that might have similar first and last names.
      • The body of the ID (after the ‘_’) is made up of the first letter of the first name and first 6 letters of the last name.
    • Service Specific User: <service_ID>_username
      • These IDs, associated with a particular service, are created to associate a particular account with the service. <service_ID> identifies the service; username refers to an actual user associated with the service.

    2. Course ID Format

    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., 032 or 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., 032 or 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_S

    • o: The D2L Org Unit code into which the course offering and course template is to be placed. For example: DCE (Division of Continuing 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 full section code, preceded by the characters SEC.
    • 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 four 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.

     

    3. Course Title Format

    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>).
      • <course site ID>: The ICON course site ID (see course site ID format conventions above).
      • <descriptive title>: Text describing the purpose of the course.
      • <instructor name>: The name of the person with instructor/designer rights to the course.

    While it is not required that a particular course title be unique, it is often helpful to other ICON users.

    H. Integration

    1. ICON Course Site Creation

    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 requestor 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 its-helpdesk@uiowa.edu. 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.

    2. User Account Creation

    User accounts will automatically be created in ICON for all faculty, staff and students when the HawkID is assigned. User accounts are added to the system nightly.

    For users who do not have HawkIDs but who need access to ICON, administrators have the right to create local guest user accounts. . These accounts can be created either in a batch mode, by uploading a comma-separated values file to ICON, or one at a time, by filling out an online form.

    3. Mapping Users to ICON Course Sites

    There are two ways to associate users with registrar-based course sites. The default method is request-based registration, which occurs when an instructor fills out an online form requesting the creation of the ICON course site. 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.

    Alternatively, 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. (This method may also be used to create guest accounts.)
    • 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-designer activates the course.

    4. Other Integrations

    An integration, as the term is used here, enables ICON to communicate with other 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 Integration Team. The ICON Integration Team ensures that integrations work with all product upgrades and will contact non-ITS integration developers to inform them of planned upgrades.

    I. Use Tracking

    Information on system use is gathered in the following ways:

    1. Course and User Creation

    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, instructor-designers, etc).

    2. Logins

    Login records include time of login and success or failure of the login.

    3. ICON Course Site Use

    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.

    4. Integration and Custom Tool Logging

    To help identify errors and to track the value of an integration to The University of Iowa, all integrations created for ICON perform logging.

    J. Archiving and Backup

    1. General Convention

    Archiving and backup of ICON files are governed by The University of Iowa’s policy on Backup and Recovery (http://cio.uiowa.edu/Policy/policy-backup-recovery.shtml).

    2. Terms

    • 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). This is a process that is typically handled by ITS Systems and Platform Administration (SPA).
    • 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.

    3. Responsibility for Archiving and Storage of Data

    • ITS Systems and Platform Administration is responsible for general backups of the system and associated data. 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.

    4. Data Archiving for ICON Course Site Retirement

    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 server.
      • 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.

    5. Frequency of Data Backup and Archiving

    The frequency of ICON data backups is governed by The University of Iowa
    Chief Information Officer’s data backup and recovery policy (http://cio.uiowa.edu/Policy/policy-backup-recovery.shtml)
    and the Service Level Agreement (SLA) between Systems and Platform Administration
    and OTLT. This data backup represents ITS’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.

     

     

    Appendix I. ICON Handbook Development and Maintenance

    The ICON Handbook 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 in the Enterprise Information Technology Policy Development and Approval Process, but may also provide additional detail, guidelines, or restrictions.

    ICON conventions are developed, approved, and maintained through the following procedures.

    A. Convention Development and Approval

    Convention drafts are developed by the ICON Administration Team, or by other ICON Project teams with input from the Administration Team. Drafts are reviewed by the eLearning Core Group and the ICON Advisory Team. The 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.

    B. Convention Changes and Maintenance

    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 Administration Team, in consultation with other ICON Team members. Amended convention statements are passed on to the eLearning Core Group as specified in section A.

     

    C. Storage and Distribution of the Handbook

    Written documents are produced to clearly define all conventions. The Handbook
    is available to the public on the ICON web site, along with any other necessary
    documents (e.g., training and documentation). The Handbook is available in an
    accessible HTML format, and will also be available in a printable format
    such as PDF or HTML with printer-friendly stylesheets.

     

     

     

    Document Revision History

    Date

    Version

    Description

    Author

    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 CMSs. 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. 

    Shane Trautsch

    Article number: 
    106526
    Last updated: 
    January 3, 2017
    Service: 
    Category: