1. 1 Moving From the Blackboard Learning System to the Blackboard Academic Suite Day 1: Understanding the Academic Suite Framework July 17, 2006 9:00 a.m. – 4:00 p.m. Jarl Jonas, Senior Consultant, Bb Training

2. 2 About the Instructor… Jarl Jonas Senior Consultant, Blackboard Training Additional Experience:  Online Course Developer & Instructor Blackboard Certification Series & Advanced Courses  Director for Online and Corporate Learning Development New York University School of Continuing and Professional Studies  Faculty Development Coordinator New York University Faculty Resource Network  Secondary Language Arts Teacher North Brunswick Township, New Jersey

3. 3 Introductions & Account Provision Please introduce yourself…  Name  Role/Responsibilities with the Institution  Previous, planned, or current use of Blackboard?

4. 4 This Week’s Agenda  Monday Understanding the Academic Suite Framework  Tuesday Blackboard Community System Admin & Essentials  Wednesday Blackboard Content System Essentials  Thursday Blackboard Content System Administration  Friday Blackboard Learning System: What’s New

5. 5 Workshop Objectives At the end of the workshop, participants will be able to:  Describe the value and components of the Blackboard Academic Suite  Define system roles, institution roles, and course/organization roles  Customize existing system roles  Create new system roles to reflect institutional processes  Create and manage institution roles  Discuss Domain management requirements and use cases  Identify roles and responsibilities associated with the institutional structure and the Blackboard System Roles  Create Domains and assign administrators  Associate users, courses, organizations, tabs, and modules with Domain collections  Identify best practices for Domain management

6. 6 Today’s Agenda  Introductions  KSU Use Case Discussion  Academic Suite Overview  Blackboard Roles  Domain Management

7. 7 Kentucky State University: Use Case Discussion

8. 8 KSU’s Planned Use of Blackboard  Supplement to traditional courses  Professional development  Distance learning  Delegated administration for academic areas  Aqua-culture products on e-Marketplace  e-Porfolios for SACs accreditation, specifically faculty credentials (pilot w/ them first)  Use of Community System as main web presence (long-term)  E-Reserves (library presence on Bb)  University Orientation 101  Blackboard Resource Center (Howard U. as an example)  Professional Development (IT and Bb workshops, then other areas)  Possible integration with Dell Learning System (Land Grant)

9. 9 Formalizing the Implementation Plan  Establish vision for Blackboard usage which is aligned w/ institutional mission  Compose long-term and short-term goals  Prioritize & formulate specific, measurable objectives for short-term goals  Take inventory of required resources  Create timeline and assign tasks  Pilot features and functions  Review and improve process and procedures  Implement with clear and concise guidelines

10. 10 KSU Mission Statement

11. 11 KSU Vision, Goals, & Objectives  Vision  Goals  Objectives

12. 12 The Blackboard Academic Suite

13. 13  Enables instructors to create and manage course content, utilize world class publisher content, evaluate performance and communicate with students.

14. 14  Enables institutions to connect users to vibrant online communities, deliver targeted content to diverse user groups and incorporate e- Commerce in the learning experience.

15. 15  Allows digital content to be shared, repurposed, and managed in diverse ways.

16. 16 Academic Suite: Functional Overview Learning System (Courses) - Deliver Content - Assess Performance - Communicate w/ Students Content System (Content Repository) -Collect Content - Share w/ Others - Discover Content - e-Portfolios Community System (Look & Feel/Access) - Target Information - Create CoP, SIGs -e-Marketplace

17. 17 Enabling a Networked Learning Environment  A true networked learning environment exists when any student or teacher can view instructional content, collaborate with educators, evaluate academic performance, and access any learning resources at any time to achieve their educational objectives.

18. 18 The Networked Learning Environment

19. 19 Blackboard Roles: An Overview

20. 20 Topics for Discussion  Define System Roles  Create & Customize System Roles  Define Institution Roles* Primary Secondary  Create & Manage Institution Roles  Define Course & Organization Roles  Modify User Privileges * For clients who license the Blackboard Community System only.

21. 21 Blackboard Roles: What Are They? System RolesInstitutional RolesCourse/Org Roles

22. 22 Blackboard Roles: What They Control System Roles Determines access to:  Certain system-wide user privileges Can Restrict:  Domain Criteria Institutional Roles Dictates access to:  Community System Domains Brand Tabs Modules Organization Catalogue  Learning System Course Catalogue  Content System Permissions Workflow e-Portfolio Learning Objects Catalog Course/Org Roles Determines access to:  Certain features and functions within a Course or Organization

23. 23 Blackboard Roles: Labels System Roles  System Administrator  System Support  Course Administrator  User Administrator  Support  Community Administrator  e-Marketplace Administrator  e-Commerce Administrator  Custom  Guest  None  Observer Institutional Roles  Primary (only 1) Brand Initial Tabs/Modules  Secondary (unlimited) Further Tabs/Modules Course/Org Roles  Instructor/Leader  Teaching Assistant/Assistant  Course Builder/Org Builder  Grader/Grader  Student/Participant  Guest/Guest  Observer/Observer

24. 24 Typical User  System Role: None  P Institutional Role: Student  S Institutional Role: IRMC  Course Role 1: Student  Organization Role 1: Leader  Organization Role 2: Participant

25. 25 Blackboard Roles System Roles

26. 26 System Roles  System Administrator  System Support  Course Administrator  User Administrator  Support  Community Administrator*  e-Marketplace Administrator *  e-Commerce Administrator *  Custom Role  Guest  None  Observer *For clients who license the Blackboard Community System only.

27. 27 System Role: System Administrator  All administrative functions and every individual Course Control Panel

28. 28 System Role: System Support  Access to most administrative functions but NOT Individual Course Control Panels Content System administration Role administration Privilege administration Domains administration

29. 29 System Role: Course Administrator  Administration of courses and organizations  Limited administration of Users and Tools  No access to individual Course Control Panels

30. 30 System Role: User Administrator  Administration of Users and Enrollments  No access to individual Course Control Panels

31. 31 System Role: Support  Search for Courses or Organizations or Users  Import and Export of Courses or Organizations.

32. 32 System Role: Community Administrator  Administration of the Community System - Management area and Gateway Options  Administration of Institution Roles  Search for Users

33. 33 System Role: Guest  A user with the System Role of Guest can view any unsecured areas of courses that have Guest Access enabled.  Every Blackboard system has a pre-set user account called "Blackboard Guest" with the username of "guest" and the password of “guest.”  Any user who logs in with this username and password or who clicks the Preview button on the Gateway page is automatically given the Administrative System Role of Guest.  A Guest does not have access to the System Admin tab.

34. 34 System Role: Observer  A user with the System Role of Observer can “shadow” one other user on the system.  An Observer can see all courses in which a specific other user is enrolled.  Within each course, an Observer can view those materials and tools that the Instructor has opened to Observers.  An Observer does not have access to the System Admin tab.

35. 35 System Role: None  Default System Role.  A user with the System Role of None has no administrative controls or rights.  Users can access any tabs except System Admin and any course in which they are enrolled.  The Course Role (Course Builder, Grader, Guest, Instructor, Student, Teaching Assistant) assigned to that user for that particular course will determine the level of access and rights within a specific course.  A user with the System Role of None does not have access to the System Admin tab.

36. 36 Flexible System Roles and Privileges System Administrator now may: Modify existing System Roles Create new customizable System Roles Copy existing System Roles Allow users to have more than one System Role (Blackboard Community System™ required) System Roles are additive

37. 37 System Roles Management  Add Roles  Rename Roles

38. 38 User Privileges  By default, privileges are set up by Blackboard upon installation of the software.  The Manage User Privileges page lists the privileges assigned to each System Role and Course Role.  Each privilege can be modified to include or exclude roles.  Use the Manage User Privileges page to assign/modify the roles as per your institutional needs - remember these changes affect globally.  In most cases, users such as Students and Instructors will have an System Role of None (N).

39. 39 Privileges Availability

40. 40 Manage Privileges for a System Role

41. 41 Multiple System Roles User Properties:

42. 42 Blackboard Roles Institution Roles

43. 43 Institution Roles Institution Roles provide users with access to information (content) and services Access to the Blackboard Community System tabs, modules, and brands is controlled through Institution Roles. Access to the Blackboard Content System My Content area, e-Portfolios, and the Learning Objects catalog is controlled through Institution Roles. Access to the Blackboard Learning System Course and Organization Catalogs is controlled through Institution Roles.

44. 44 Institution Roles  The number of Institution Roles is unlimited.

45. 45 Institution Roles Institution Roles are split into two groups Primary Roles Secondary Roles A user is assigned one Primary Role but they can have an unlimited number of Secondary Roles The Community System has several default Institution roles: Student, Faculty, Staff, Alumni, Prospective Student, Guest, Observer. These default roles may be renamed and reused. Each role may be used to display an unlimited number of tabs and modules. **Note: Fewer roles = a more manageable system

46. 46 Primary Institution Roles Each user must be assigned a Primary Institution Role. Primary Institution Role can also determine the Blackboard Community System brand that a user will see when they access the Community System.

47. 47 Secondary Institution Roles Users may be assigned an unlimited number of Secondary Institution Roles. Primary and Secondary Institution Roles control the tabs and modules that are presented to users when they access the system.

48. 48 Blackboard Roles Course & Organization Roles

49. 49 Course and Organization Roles Organization Roles Leader Assistant Organization Builder Grader Participant Guest Course Roles Instructor Teaching Assistant Course Builder Grader Student Guest  Administrators or Instructors may assign a Course Role/Organization Role to a user when performing enrollment functions for a course or organization.  Course Roles/Organization Roles determine the particular level of access and rights a user has in a course.  A user’s role may vary from course to course or organization to organization.

50. 50 Course Roles Course Roles can be assigned in three ways: 1.Use the Batch Create User process. 2.Select role on an individual basis though Modify Courses. 3.Select role on an individual basis through Modify Users.

51. 51 Domain Management Overview, Set-up, & Maintenance

52. 52 Overview

53. 53 System Administration Dilemmas  Institutional groups within an institution (campuses, schools, departments, etc.) want administrative control of their Blackboard courses and content. Risks inherent in granting System Administration privileges to many staff. Not practical to set up separate Blackboard servers for each organization.  Institution manages Blackboard server(s) centrally which may create a bottleneck for simple administrative tasks.

54. 54 What are Domains?  A domain is an area of control.  A domain can contain a subset or collection of: Users Courses Organizations Modules Tabs  Each domain can be managed by users, or Domain Administrators, who have System Roles with specific administrative privileges for that area of control.

55. 55 Characteristics of Blackboard Domains  Domains offer a customizable, flexible, and secure system administration model.  Domains gather courses, users, tabs, modules, and organizations into defined sets called collections.  Each domain can have one or many collections.  Once established, administration of a domain is controlled by assigning System Roles to users that only apply to that domain. Privileges are restricted to the items that exist in that domain.  Applying System Roles in a domain limits the user to using the privileges assigned in the System Role to the data in the domain. Note: If System Roles are applied directly to a user via the User Properties page, privileges will be granted in the default domain (the entire system).

56. 56 Examples for Establishing Multiple Domains  Organize users, courses, organizations, tabs, and modules into groupings.  Delegate administration of users, courses, organizations, tabs, and modules.  Assign different administrative responsibilities to different staff members within a domain.  Control Domain Administrators' access to specific features within a domain by defining privileges.

57. 57 Restrictions on Domains  Domains require Blackboard Community System features to organize and manage data. Domains are only available with the Blackboard Community System.  Domains are designed to be flexible and do not adhere to any hierarchy within the system. Domains can be defined to overlap or even nest, but that structure is applied. The domains do not have a relationship within the system.  New items, such as courses and users, that meet the constraints of a domain are included in the domain when created. Domain administrators may not control the default attributes of items at creation. For example, a Domain Administrator cannot require that all new courses created in the domain adhere to specific default values.  Domains are not used to manage other items in the system such as Tools and Building Blocks.

58. 58 Blackboard Domain Terminology  Domain: A grouping of data defined for the purpose of delegating administrative responsibilities to other staff members.  Collection: A set of data, defined by variables or selected individually, that appears in a domain.  System Role: A role that grants administrative privileges. When applied in a domain, the privileges are only valid when working with data in the domain. System Administrators can define an unlimited number of System Roles and assign privileges to hundreds of administrative functions through each System Role. Each user may have multiple System Roles assigned.  Category: A variable that defines and groups courses. Courses may be assigned multiple categories. Categories are a logical means of assigning courses to a collection.  Institution Role: A variable that defines and groups users. Users may be assigned multiple Institution Roles. Institution Roles are a logical means of assigning users to a collection. Institution Roles control what is presented to users.  Availability: Determines access. Courses that are unavailable are only accessible by certain users. Likewise, a user that is unavailable may not access the system.  Enabled: A flag set by Snapshot. Data is often disabled to mark it for archive or deletion.  Datasource Key: A variable assigned to data added to the system through Snapshot. When Snapshot is used to integrate with other information systems, Datasource keys can be used to define collections based on the source of the record.

59. 59 Default Domain  Every system has at least one domain.  This domain includes all the system's courses, organizations, users, tabs, modules  Users with a System Role of System Administrator have full privileges over the default domain (the entire system). Default Domain All courses All organizations All users All tabs All modules Managed by 1 or more System Administrators

60. 60 Multiple Domains  Any number of additional Domains may be defined.  Each domain MAY include all or selected items from the Default Domain courses, organizations, users, tabs, and/or modules  Each Domain has one or more Domain Administrators each with separate System Roles. Default Domain Domain1 Domain2 Domain3

61. 61 Case Study: Kentucky State University  Three colleges: College of PS College of Arts… College of Math… State University Domain PS-Domain Arts Domain Math Domain

62. 62 Collections College Domains  Users by data source key from integration with student information system or  Users by Institution Role  Courses by catalog entry  One Community System Tab  School-specific Community System Modules

63. 63 Administration College Domains  1 Domain Administrator with a custom System Role that includes standard User and Course administrator privileges except: Creation Deletion  Custom System Role added to provide access to Course Control Panels  1 Community Administrator to maintain the school's tab and modules

64. 64 Case Study: Domain for System Administration Division of Labor  Main Domain  Active Domain for All active Users and Courses  Domains for all Disabled Users Staging and review prior to deleting users Disabled Courses Staging and review prior to archiving (if needed) and deletion  Facilitates delegation of responsibilities Main Domain Disabled Courses Domain Disabled Users Domain Active Domain

65. 65 Administration of Multiple Domains  Administration of domains is assigned by the Full System Administrator through combining a user record with System Roles within the domain.  Each Domain Administrator can be assigned any number of System Roles.  The privileges included in these roles are additive, so they can be combined to create several different models of Domain Administrators.  The same user can be an administrator in multiple domains.  Domain Administrators have a tailored way of using the Administrator Panel functions. Their view of the Administrator Panel will be specific to their domain(s) and the privileges of their System Role(s).

66. 66 Full System Administrator Tasks for Domain Management Setup

67. 67 Defining Domains: Recommended Sequence of Tasks  Set up a model for Institution Roles.  Set up a model for Course and Organization Categories.  Institutions that are using Snapshot to populate the Blackboard database with data from other systems can also use data source keys to define collections.  Create System Roles (If different than default).  Identify users to serve as Domain Administrators.  Create domains.  Define collections.  Setup and assign Domain Administrators.

68. 68 Full System Administrator Task: Create System Roles  System Roles can be created for each domain, but it is more efficient to create System Roles based on like privileges that can be applied to an administrator in each domain.  Because System Roles are additive in the domain, it is possible to create a System Role model based entirely on tasks and then use a combination of those tasks to grant individualized privileges to specific delegated administrators.  When creating System Roles, consider the following: What administrative tasks will be used by domain administrators? What privileges are needed to accomplish these tasks? How can those privileges be grouped so that each set of privileges accomplishes a goal or goals? Are there any privileges that are not always applicable in the set? How should System Roles be named? The naming convention should be easily recognizable and define the set of privileges.

69. 69 Examples of System Roles  A System Role named USER_MANAGER is created with full privileges to manager user accounts. This System Role can then be used in each domain to grant a domain administrator the ability to administer all user accounts in the domain.  Another System Role, USER_PASSWORD may be granted to a domain administrator to allow that user to change users' password, but not modify any other details about the user record.  In the College of PS domain, the Department Head may be given the role USER_MANAGER, while an assistant is assigned the USER_PASSWORD System Role in the domain to respond to requests to replace a lost password.

70. 70 Full System Administrator Task: Identify Users to Serve as Domain Administrators  Each domain can have an unlimited number of administrators with an unlimited number of System Roles.  In a domain, different administrators are assigned different responsibilities and tasks.  Consider the following when assigning users as domain administrators: What aspects of the domain require a domain administrator? Are there specific System Roles that grant privileges to accomplish these tasks without introducing additional unnecessary or potentially risky privileges? If not, consider revising the construction of System Roles or creating a new System Role to cover the exceptional case. How do the required tasks form the responsibilities for domain administrators? Is one administrator required to manage users while another is assigned courses? Who should be assigned to the different domain administrator positions?

71. 71 Full System Administrator Task: Create Domains  Creating a domain adds a new domain to the system.  After creation, the domain must be populated with collections and Domain Administrators must be assigned.  Only the System Administrator can see the list of domains.  Domains are invisible to users within the system, since they are an administrative management tool.  Administrators within the domain are also unaware of the domain. Administrators within the domain simply access features and functions on the Administrator Panel.  The domain controls what data can be managed by the domain administrator.

72. 72 Defining Domains  Each domain is defined by assigning criteria to create sets of users, courses, organizations, tabs, and modules. Each set is called a collection.  Adding the collections is a process of defining the collection in such a way to encompass every item that should be included. When new items, such as a user or a course, are added to the system, they automatically become a part of any domain for which they meet the collection criteria. For this reason, it is important when defining a collection to use the criteria and the rules to determine the items that fall into the collection to ensure that new items are added to the collection when created. There is an option to add items individually. The ability to add items individually is useful for defining domains that are limited and static, ensuring that no other items become a part of the domain.

73. 73 Relationships Between Collections  There is no relationship between the Users in a domain and the Courses and Organizations.  Users enrolled in a Course are not automatically included in the domain.  Within a domain, enrollments are controlled by courses.  A Domain Administrator with privileges to modify users may not change users' enrollments in a course.  A Domain Administrator with privileges to modify course enrollments may include or exclude users from a course.

74. 74 Full System Administrator Task: Define Collections -Course and Organization Criteria  Availability  Course Category  Disabled/Enabled Status  Enrollment Type  Data Source Key  Specific Course IDs/Organization IDs

75. 75 Considerations for Defining Collections: Courses and Organizations  What categories can be used to define the courses and organizations in this domain?  Alternatively or in addition to categories, what data source keys can be used to define the courses and organizations in this domain?  Should the domain include unavailable courses and organizations? Should the domain include disabled courses and organizations? This is an important consideration as unavailable and disabled status is often used to mark courses and organizations that are complete and scheduled for archive.  Should the courses and organizations in the domain be limited by Enrollment Options, for example, courses in which Students can enroll themselves?  Course and Organization categories must be added individually, even if the category is nested in a category that is already included in the domain.

76. 76 Full System Administrator Task: Define Collections - User Criteria  Availability  Privacy Options  Institution Role  System Role  Disabled/Enabled Status  Data Source Key  Specific Usernames

77. 77 Considerations for Defining Collections: Users  What Institution Roles can be used to define the users in this domain?  Alternatively or in addition to Institution Roles, what data source keys can be used to define the users in this domain?  Users may also be defined by System Role, however, customized System Roles are more likely to be based on privileges and thus are not usually a good model for defining the users in a domain. System Role is most useful as an attribute when using the Guest or Observer role.  Should the domain include unavailable Users? Should the domain include disabled Users? This is an important consideration as unavailable and disabled status is often used to mark User records for archive or removal.  Should the Users in the domain be limited by Privacy Options? Users that opt out of the User Directory can be excluded from a domain.

78. 78 Example of Domain Criteria  Scenario: The CoPS domain has been created and contains a collection of courses and users that includes all the courses offered in the department and all the users that work in the department or list Languages as their major of study.  The courses collection may be defined as: Categories: CoPS Availability: Ignore Enabled: Ignore  The user collection may be defined as: Institution Roles: CoPS Availability: Available Only Enabled: Enabled Only

79. 79 Full System Administrator Task: Define Collections -Module and Tab Criteria  Availability  Specific Modules and/or Tabs

80. 80 Considerations for Defining Collections: Tabs and Modules  Should the domain include unavailable Tabs and Modules? This is a way to allow users to create tabs and modules but not modify them once they are published. Alternatively, a domain can include only available materials. In this case, the unavailable materials that are in production cannot be modified by the domain administrators.  Tabs and modules can be individually selected for inclusion in a domain.

81. 81 Full System Administrator Task: Setup Domain Administrators  Domain Administrators are created by combining a user with System Roles within the domain.  System Roles are roles that define administrative privileges.  A user can have several System Roles applied within a domain.  When a user has several System Roles, all the privileges in each role are applied - the sum of all the privileges.  System Roles may be attached to users on the Modify User page or when users are created. System Roles added in this way apply to the default domain, allowing users to impact all data on the system.

82. 82 Example of Domain Setup  Once the individuals who will serve as domain administrators and the System Roles that will grant appropriate privileges are identified, the last step is to put that information together within the domain. For example: Domain: CoPS User: kysutrain01 (Donna) System Roles: Course Administrator, User Administrator, Course Control Panel

83. 83 Best Practices

84. 84 Structure a Flexible and Secure Administration Module Using Domains  Develop an Administration model that matches the organizational needs of the institution. What are the groupings on Campus that require Domain Management?  Define the groups at the institution that can be supported by delegated administrators with privileges limited to that domain. Some institutions may choose to use domains to separate management of users between students, faculty, alumni, and staff. The same institutions can use domains to separate management of courses between academic departments. The same institutions can even apply both models, and allow the academic department domain administrators control over users in their respective departments. Further, each department could be divided into separate domains. One domain could be used to manage the tab and module content while another domain managed courses and still another domain handled users.

85. 85 Establish Clear Goals and Organization  The flexibility of domains demands clear goals and organization before creating the domains and assigning administrative privileges. How is the institution organized and managed? Does it make sense to create domains for each functional group? Consider this question beyond just academic departments and think about the groups on campus that support the learning mission. How are Institution Roles used to define users within Blackboard systems? For example, are users organized by major, location, year of study, or other variables? How are individuals at the institution managed? Are the different sets of users managed by different functional groups? For example, is there an alumni office that handles alumni relations? Is the admissions department responsible for prospective students? Who is responsible for the content that appears in tabs and modules? What Institution Roles are used to define who can view content? Are there different information systems responsible for shared data with the Blackboard systems?

86. 86 Develop Naming Conventions for Domains  It is very likely that the groupings on campus will have subgroupings that also require delegated administration.  Subgroupings cannot be nested as domains within a domain, but this is not a barrier to creating a hierarchical structure of domains.  Because domains are made up of collections, and a unit, such as a course or user, can appear in multiple collections, it is easy to define domains that consist of a subgroup of another domain.  To maintain the proper organization, develop a naming convention for domains that incorporates the larger domains.