V. Defining Our Users and Their Requirements
User stories are simple descriptions of features, written in plain English, that help website developers effectively plan a new website with the website users in mind. Since different groups of website users have different requirements, some user stories may only apply to certain user groups, e.g., “Evergreen Developer” or “Potential Evergreen Implementers.”
Immediately after finalizing the strategic requirements listed above, the Web Planning Team began an analysis of Evergreen community members. The primary goal of this analysis was to catalog as many different roles in the community as possible, thus ensuring that the Team would consider the requirements of all potential users.
The following criteria were used when discussing community groups and roles:
where users are located geographically
where users are in the OSLS/EG adoption process (potential/information-gathering, migration process, production environment, etc.)
where users are coming to the site from (referral links, search engines, etc.)
what users' goals are when they visit an EG property (“why are they here?”), and
what we need to convey to them for an effective interaction to take place from our perspective (“why do we, as site planners, care if they visit” –> “what defines success for the EG web properties?”).
Within this framework, the team identified many groups of EG community members, some of which overlap and some which are distinct. As with other planning phases, regular updates and requests for comments were made to the general community list.
The following list of groups of Evergreen community members was finalized by the Web Team in January 2011:
1. “Administrators” administer one or more Evergreen systems for their organization.
2. “Developers” perform the actual application development (programming) of the Evergreen software.
3. “Documentors” include members of the Documentation Interest Group and other community members responsible for producing documentation of Evergreen software and/or processes.
4. “Consultants” are third-party vendors or service providers that assist organizations with Evergreen implementations in some capacity.
5. “Governance Members” are members of the Evergreen Governance Committee, the team tasked with creating the future “Evergreen Foundation.”
6. “Webmasters” are members of the Evergreen Communications Committee and other identified community members responsible for maintaining the community website.
7. “Potentials” are those users considering a future implementation of Evergreen for their organization.
8. “Skeptics” are potential users that are explicitly unsure of open source development methodology, support models, open source ILS in general, or Evergreen specifically.
9. “Migration” users are planning or in the middle of a migration to Evergreen.
10. “Standalone” users are existing or potential Evergreen users of a single-library implementation of Evergreen.
11. “Extenders” include third-party developers, integrators, and other “unofficial” developers with an interest in Evergreen development and source code.
12. “Install” users are seeking information about Evergreen software repositories and related downloads.
13. “Translators” participate in translating the Evergreen software and/or documentation.
14. “Accessibility” users participate in ensuring Evergreen software, documentation, and website are as accessible to as many users as possible.
15. “LIS” users are professors, teachers, or students interested in studying Evergreen and other ILS software in a LIS or other academic context.
B. Functionality-related Requirements vs. Content-related Requirements
For each group of website users identified, the Web Team wrote multiple requirements in the form of user stories. As in previous phases of the planning process, frequent feedback was given to - and sought from - the community via the general mailing list. The Web Team tracked two separate types of user stories: those related to functionality, and those related to content.
User stories can be related to website functionality, such as activities, applications, and tasks that users perform. For instance, an online event calendar that allows committees to schedule recurring monthly meetings is an example of a functionality-related user story.
User stories can also be related to content on the website, such as specific documents, materials, multimedia, or pages. For instance, having a special page on the website explaining the benefits of Evergreen to people who don't currently use it is an example of a content-related user story.
A complete list of user stories, classified by user role, is available in “Appendix C: Complete list of identified user stories.”
1. Planning Process
Although the Web Planning team sought feedback and comments from the community via the general mailing list, a formal survey was also desired to get detailed and structured feedback. Several team members created a draft survey, which was then refined with feedback from the rest of the team. The methods and goals of the survey included:
achieving high diversity of targets and responses (in terms of various stakeholder groups and audience/user/visitor groups)
high response rate (we don't really have a denominator for response rate calculation)
depth of responses (e.g., “I like blogs” vs. “I would like to see a feature wishlist system with specific features X, Y, and Z”)
make it as easy as possible for community members to suggest miscellaneous requests and suggestions (unstructured feedback)
provide structured feedback opportunities (e.g., “would you prefer Feature A to be implemented as X or as Y?” or “Rank Features A through G in preferred order”)
2. Survey
Once the team had achieved consensus on the content to be presented in the survey, two team members took the lead in crafting the survey in the SurveyMonkey tool. The survey was released to the community on March 1st, 2011 and publicized via the Evergreen general mailing list. The community was asked to complete the survey within two weeks of the release, and follow-up reminders were sent as well. Approximately 42 respondents completed the survey.
The aggregate survey results are included as a PDF attachment in Appendix B. Although a complete set of detailed, per-respondent survey results was also downloaded and analyzed by the Web Team, it was decided that those should not be published since respondents were never informed their answers could be made public.
Following the survey, the Web Team conducted two meetings to analyze and discuss the results. While the survey results did reinforce some existing notions about the community's use of the website, some interesting points were made:
Who responded? The survey was advertised almost exclusively on the Evergreen mailing list, which is populated by both existing and potential users of Evergreen. Over 20% of survey respondents identified themselves as potential Evergreen users not currently using the software. The Web Team had anticipated that this user group would be underrepresented in the survey respondents due to lack of interest, so this was a fortunate surprise.
The “standalone” user role was defined relatively late in the user role planning phase, and there was some curiosity among the Web Team as to how many users that role included. However, 10% of survey respondents identified themselves with a one-library organization, validating this role and justifying specific content targeted to its members.
Over 60% of survey respondents classified their library/organization as a public library, followed by college/university or “other.” Only a single respondent identified themselves with a K-12 library or library system. The Web Team discussed ways to help K-12 Evergreen users connect, as well as bigger picture objectives of increasing awareness of Evergreen in the broader K-12 community.
When asked to identify their role - or more commonly, roles - in their library or system's Evergreen project, the average respondent selected approximately four of the presented options. This figure satisfied the Web Team's goal of diversity of response and also confirmed the suspicion that Evergreen community members tended to wear “multiple hats” within their project. From a website planning perspective, this indicates the need for built-in site tools that help website users manage multiple interests and monitor information from various sources. For example, users may benefit from a customizable news feed that presents information only from topics of interest that they have identified.
As mentioned above, respondents were given several options when asked to identify their role(s). Some of these roles were specific to individual Evergreen implementations, such as “installing/maintaining Evergreen” or “training/supporting end users.” However, some of the roles also explicitly mentioned - or at least implied participation - in the greater Evergreen community, outside of the scope of an individual project. These roles included functions such as website maintenance or content creation, documentation, translation, etc. A relatively high number of respondents identified with the community participation roles. From a high-level perspective, this is very encouraging: it indicates a healthy, interconnected community ecology as opposed to a standalone email list populated solely by self-interested individuals seeking specific technical answers or other goals.
Given the importance of community participation, the Web Team was encouraged to note that approximately 25% of respondents say they have contributed to the Evergreen website in the past; a variety of contributions were mentioned, primarily documentation.
Users who stated that they had not contributed content were asked why they had not, in an attempt to identify any cultural or technical barriers to contribution. The majority of reasons can be sorted into three main groups:
a) Users who felt they had no valuable content to contribute due to relative inexperience with the Evergreen software, e.g., ”…only recently migrated…” This attitude is to be expected in such a young community such as Evergreen; however, the rapid uptake of Evergreen in libraries around the world should translate relatively quickly into a large increase of potential website contributors.
b) Users who felt they had no valuable content to contribute due to perceived lack of technical capability, e.g., ”…not a programmer…” Non-developers provide value to an open source software ecosystem in many ways that are just as valuable as the developers themselves, such as documentation, quality assurance and testing, business/system analysis functions, etc. It is critical to encourage a strong culture of contribution and collaboration within the community so that these non-developer assets can be fully used.
c) Users who are unsure of how to contribute content to the website, e.g., ”…not sure how to go about doing it…” This attitude indicates a need for tools, documentation, and processes that allow as many community members as possible to easily contribute valuable information to the website in an effective manner. From a website planning perspective, this can be considered a strong mandate to encourage a culture of active participation and provide website tools that encourage participation and remove barriers from as many potential contributors as possible.