Repository Users
Access
The Repository Users Team must decide who has access to the repository and how that access will be granted. This team answers questions such as: “Will the repository be open to faculty in my state, publicly available, or open to selected groups or individuals?” and “Will users be required to apply for an account?” Many of the stakeholders identified in the early portions of the planning process may become your repository users, so consider the best way to meet the access needs of these groups.
Repositories have taken a variety of approaches to user access. For example, Connexions (http://cnx.org/) and Wisc-Online (http://www.wisc-online.com/) are both open to the public. In both cases, a new user simply registers for a free account and is then able to use the repository. Wisc-Online users may search and use the learning objects in the repository. Connexions goes a step further, allowing any user to also contribute resources to the repository. Both of these repositories use open source software that they developed in-house, and do not have any software licensing constraints that limit the number or types of users.
In contrast, The Orange Grove uses proprietary repository software which is priced based on the number of licensed users in the system. Given this constraint, it was decided that the Orange Grove would only offer accounts to Florida educators, although Guest Users have access to any public resources in the repository. Another consideration was that, as a K20 repository, some materials appropriate for higher education coursework might not be suitable for younger students. Limiting access to educators allows instructors to make the decision as to what is suitable for their students.
The Repository Users Team should also determine how users will acquire their accounts. There are several different methods. Both Connexions and Wisc-Online allow users to self-register by completing and submitting a short online form available on the repository homepage. Another method is to have staff members responsible for entering user information into the system and establishing permissions. In the Orange Grove, educators who request an account submit their information to the project staff via email. The project manager then creates an account for them. Guests can login to view and use publicly available resources. A third method is to integrate the repository directly into statewide or institutional Learning Management Systems (LMS). If the repository software can be integrated into the LMS, users can be automatically added to the system and authenticated when they enter the repository through their LMS. The Orange Grove is pursuing this third option because it not only lessens the burden of account management on the repository staff, but allows users to use their familiar LMS interface to access the repository. The repository is then only one click away from their course interface, which The Orange Grove project team believes will facilitate use.
User management and associated issues such as establishing usernames, passwords, and groups and roles (including contributing, reviewing, editing, accepting, rejecting, and deleting resources) may be centralized or de-centralized functions, depending on the software capabilities.
User management
User management and associated issues such as establishing usernames, passwords, and groups and roles (including contributing, reviewing, editing, accepting, rejecting, and deleting resources) may be centralized or de-centralized functions, depending on the software capabilities.
One important user management decision which has long term impact is establishing the convention for user names. When The Orange Grove repository first started, staff gave little thought to user name formats. User names were created using first initial with last name (tsmith). Because the software did not provide a field for the full names of users as a method of further identification and discrimination, it quickly became difficult to locate an individual as the number of accounts grew. Some confusion and duplications resulted. The Orange Grove now uses the standard: last name_first name. Another approach might be: institution acronym_last name_first name (bcc_smith_tom). This would ensure that there are fewer duplications across the system, and provide additional information about users. Consider whether you wish to capture any additional information about your users, and what options your software provides. Integrations with learning management systems (LMSs) may also impact your user conventions. Currently, in Orange Grove integrations, the LMS username becomes the repository username.
User Information
The Repository Users Team should also specify what information you wish to capture about each repository user. We suggest you capture general information about your users, such as their name, title, institution, and email address. If possible, you may want to record your users’ areas of expertise to assist you in forming content review teams and establishing communities of practice. This information will support your communication and marketing efforts. User information may also be useful for evaluating and documenting your areas of repository success, and for future funding requests. Statistics on the number of unique users, communities, and institutions served demonstrate the need for and value of the repository.
User Support
Finally, the Repository Users Team should establish a framework for user support and communication. Planning for a user support system is important to keep your repository customers satisfied. Users who receive friendly and timely support to resolve their problems will likely return again. Problems both large and small arise when users interact with the system (i.e. forgotten passwords, system downtime, questions about materials in the repository) and there should be a structure in place to assist users when these issues arise. By tracking user problems reported through your support system, you can identify training needs, possible defects in your repository software, and even suggest future software improvements.
Support systems differ widely in their size and levels of sophistication, but ideally, your system should have several goals. First, we suggest you provide one point of contact for questions and problem resolution. From a single intake point, you might route users to different groups within your support team.
Second, give reliable, accurate and prompt service. Any contact from your users should be viewed as a marketing opportunity. So, even if you can’t resolve a problem right away, by acknowledging your receipt of an inquiry immediately, you can create a positive impression on the user. Of course, this first impression should be followed up with some type of resolution. The attitude conveyed in responses to your users is also important. A positive and helpful tone is essential.
Third, view support problems as an opportunity to increase your users performance level. User problems often allow you to provide feedback on more efficient ways for users to perform tasks and/or to direct them to self-help materials, such as tutorials, support wikis, blogs, and knowledge banks that can increase their competence with your system – and may avoid future questions.
When reading through this section, consider current support systems and structures that might be available to you, or for which you might be able to share costs. A logical first step is to consider how customers should make contact with the support system. Options include: telephone, email, chat and instant messaging, web logging, and fax. If you offer several pathways for contact, consider how queries will be integrated for data management and tracking.
It’s a good idea to offer at least two options to your users: for example, if you provide telephone support and the user has difficulty reaching a support person, providing an email option can allow the user to register their request. Many systems generate an automatic acknowledgement to email support requests. And, if you provide phone support, it’s a good idea to provide a toll-free number.
One rule of thumb to use in planning for support staffing is to provide one support person for every 90 – 250 customers. Factors that affect the number of staff needed include the complexity of your system, the technical level of your users, and whether your users move around a lot or are stationary. If your system is complex and your users are technically advanced and access your repository from a variety of locations, you will likely experience more complex problems, and need more support staff. If your users are less experienced technically and consistently access your repository from one or two locations, you should need fewer staff.
When planning for staffing, you may want to assign support tasks to staff members that have other duties besides responding to support requests. Most support staff members suffer “burnout” if they are expected to respond to users for longer than around 5 hours a day, particularly when providing telephone support. If your support staffers are tired, they also tend to make mistakes and their customer-friendly attitudes may suffer.
Finally, you should consider what type of data you would like to collect from the support system. The kind of data you collect will likely depend on the complexity of your support system, and number of users served. If you have a highly automated telephone support system and a number of support staff, you may want to measure how long your users have to wait to reach a support person, how long it takes the support member to resolve the problem, and length of time required to document each call. The percentage of calls that are resolved upon first contact (without the need for the user to contact support a second time) can also be a useful metric to highlight your support staff’s level of competency related to the complexity of your support requests. If you have a large support staff, it’s useful to survey this group on their perceptions of effectiveness of the system and to identify areas for improvement.
Other metrics that may be useful to even small support systems are to track the type of problems or issues reported. Peak times or dates that support requests are generated can also help you staff your support system more efficiently. Customer satisfaction surveys are another way to get feedback on the effectiveness and the quality of your support system.
Resources
