| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| webteam:webplan:2011:section5_users [2011/06/02 15:02] – jimcraner | webteam:webplan:2011:section5_users [2022/02/10 13:34] (current) – external edit 127.0.0.1 |
|---|
| The following criteria were used when discussing community groups and roles: | 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?”). | -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. | 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. |
| |
| A. Identified Groups Within the EG Community | ==== A. Identified Groups Within the EG Community ==== |
| |
| The following list of groups of Evergreen community members was finalized by the Web Team in January 2011: | The following list of groups of Evergreen community members was finalized by the Web Team in January 2011: |
| 15. “LIS” users are professors, teachers, or students interested in studying Evergreen and other ILS software in a LIS or other academic context. | 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 | ==== 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. | 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 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. | 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.” | A complete list of user stories, classified by user role, is available in [[webteam:webplan:2011:appc_userstories|“Appendix C: Complete list of identified user stories.”]] |
| |
| C. Community Feedback Survey | ==== C. Community Feedback Survey ==== |
| |
| 1. Planning Process | **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: | 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) | -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) | -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”) | -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) | -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”) | -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 | |
| | **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. | 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. | The aggregate survey results are included as a {{:webteam:egwebsite_surveysummary_03172011.pdf|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: | 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 {@@@INC IN RECO} 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, {@@@INC IN RECO} 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. {@@@INC IN RECO} 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. * Content-related findings | *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. |
| * Respondents were given a list of existing website sections/components and asked to identify those that they “most frequently” access. Unsurprisingly, the most commonly used sections of the site are the official documentation set (produced by the Doc Interest Group), the unofficial documentation set (produced by the community using the website's Dokuwiki functionality, and the mailing list archives. The Web Team had already identified these three content areas as containing almost the entire collective knowledge base of Evergreen. | *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. |
| {@@@INC IN RECO} These three areas - docs, wiki, and mailing list - can ideally be used as three different “tiers” or “phases” of collaboration and community knowledge management. For instance, a discussion about a particular problem or feature may take place on the mailing list, where it appears in the archives. Information that is deemed especially valuable in the mailing list archives might be moved by an enthusiastic website contributor into the unofficial documentation stored on the wiki. Documentation Interest Group members may then regularly review popular wiki pages to determine if they are suitable for inclusion in the “official” documentation where they would most likely be accessed by the largest number of potential users. | *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. |
| * The previous recommendation described a process of curation, by which people in different roles or contexts could manually move knowledge from a limited discussion context into a context accessible to all on the website. However, website visitors increasingly rely on search, especially for finding specific information within a broad topic such as Evergreen. {@@@INC IN RECO} It is critical that all identified information sources are incorporated into a search corpus and that end-user search tools on the site are able to return useful results to user queries. {@@@INC IN RECO} In addition, the website should be structured in a way that optimizes automated indexing by third parties such as Google. This will help ensure that the site is ranked as a valuable resource for those searching with off-site tools. | *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. |
| * When asked which content was easy to find on the EG website, users overwhelmingly and unsurprisingly mentioned the download section and the documentation section. Informative data was gathered, however, | * 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. |
| |
| *** Functionality findings | |
| |
