What best practices do you recommend for our library websites?
In my work to maintain the libraries.org directory of libraries, I regularly visit the websites of dozens of libraries every day. This work gives me a good vantage point on the state of library websites, which range from world-class design with sophisticated features to those with minimal capabilities. Many libraries have no website at all. Of the 17,312 public libraries in the United States recorded in the database, 1,087 have been confirmed recently as having no working website.
The library websites I have observed range from superlative quality to those with glaring problems. These sites inform these suggestions for what to do and what not to do in the implementation of a library website. These recommendations deal more with the technologies involved than design and layout.
Library websites must use the https protocol to encrypt the delivery of their content to meet basic expectations for privacy and security. Implementing https will cause web browsers to show a padlock or other indicator that that the page is properly encrypted and safely viewed. Sites that instead use the http protocol send content as clear text, vulnerable to network eavesdropping. Unencrypted websites are not consistent with the expectations for libraries to protect the privacy of the individuals using their information resources. Using nonencrypted http has other highly negative implications. Web browsers, since October 2018, flag sites using http as insecure and untrustworthy, a status that no library would want associated with their website. Libraries aim to provide vetted and objective content, and it would be unfortunate for their sites to be branded as unreliable due to a lapse in the technical configuration of their server. For an in-depth discussion of this issue, see the forthcoming October 2019 issue of Library Technology Reports.
Almost all libraries use Google Analytics to measure and assess the use of their websites. The use of this free tool is controversial relative to privacy concerns. Google Analytics works through the placement of a tracking code embedded on each page, which sends data Google's servers each time an item is accessed. Libraries should verify that transmitting raw usage data to a commercial organization is consistent with their privacy policies. The service can be configured to anonymize this data by truncating the IP address. To be consistent with library values and privacy policies, this anonymization configuration option should be activated (see: https://support.google.com/ analytics/answer/2763052).
Given the now dominant proportions of web access though mobile phones, library websites must be designed to work well on these devices. The implementation of a responsive website ensures that each page is delivered according to screen size and capabilities of each type of device. To accommodate smartphones, the layout of pages must be fluid, have scalable fonts, and not have touchpoints so close that navigation is difficult. If users on a smartphone need to pinch the screen to manually expand portions of the screen to read the text or enter a search, then it is not responsive and will be avoided by those trying to use it from their phones. Most content management systems now include responsive themes that can jumpstart your design toward the goal of working well with all devices. You can also use freely available frameworks such as React (initially developed by Facebook), Angular JS (Google), Bootstrap (Twitter) to build pages with modern interface features and responsive layout. Also be sure that the measures you take to work with smaller devices don't frustrate those accessing your site with full-sized laptop or desktop computers. I have come across some library websites that require constant scrolling and that don't offer menus or other navigation shortcuts.
Sites that do not support mobile access are also punished in search engine rankings. Google's initially incorporated mobile factors into its search engine rankings in 2015, which were expanded in 2017. The company provides guidelines on mobile support (https://developers.google.com/search/ mobile-sites/). Site managers can check whether Google considers a page mobile friendly: https://search.google.com/test/ mobile-friendly.
Libraries should also be sure that they are designing their websites in ways that meet requirements for use by persons with disabilities. This topic was addressed in the Q&A section of the August 2018 Smart Libraries Newsletter. In most cases, a clean layout and a responsive design will also go a long way toward compliance with the characteristics needed for compliance with disability-related requirements such as Section 508 and Web Content Accessibility Guidelines. Valid implementation of HTML5, which includes mandatory Alt text for images, will also help meet compliance.
Libraries should also be careful regarding the placement of social media links, badges, or widgets on their websites. There are multiple areas of concern. One involves the attention and engagement. Placing an outbound link on the library's website to its social media pages jettisons users that have visited the library's primary destination on the web for providing access to its information resources and services to an external commercial site. While increasing the numbers of visits to a library's social media pages might be one measure of its user engagement efforts, it should not come at the expense of its own website. Widgets to share or link to a social media account may also include coding that tracks the user's activity on the library's website. At a minimum, these widgets make data available to the social network that the individual has visited the library's site. In some cases, query strings or other information may be held in third party cookies that may leak more sensitive data. Maintaining a presence on Facebook and other social networks can benefit the library. For its constituents that use these networks, they can provide details such as the library's location, hours, and contacts, as well as feature photos, videos, and other media to feature events and programs. Social media pages should be designed to build interest for the library and funnel individuals to its physical or virtual presence.
I have come across some libraries that rely entirely on a Facebook page rather than have its own website. Such a reliance on a commercial social networking site seems less than ideal for representing the library on the web, though it may be perceived as a convenient way to have some type of presence for those that lack the resources and expertise to deploy their own websites.
It is important for library websites to use validated coding. Even though a page may appear on your browser as expected, technical errors on the page may cause it to not display correctly on other browsers or on other types of devices. Site managers should check every page for HTML and CSS coding, using one of the free validation tools, such as the W3C Markup Validation Service (https://validator.w3.org/).
The URL that represents the library website should be considered a strategic branding element. It should reflect the identity of the library and once established should not be changed except under extraordinary circumstances. As noted earlier, the website must be configured so that the protocol component is https:// and not http://. Using a secure protocol gives confidence that the site is trustworthy and confirms that its domain has been vetted to belong to the expected organization.
Libraries should create their URL within the appropriate top-level domain. Only libraries serving commercial organizations should operate within the .com domain. Currently 1,994 public libraries in the United States have URLs within the .com domain, a glaring inconsistency with their nonprofit and educational status. Academic libraries will usually fall within the .edu domain of their parent organization. Public libraries then to use .org associated with non-profit organizations, or an appropriate geographic (tn.us) or governmental domain (.gov).
I observe that many library websites use URLs within the .com domain related to a service provider or hosting service. Over 200 libraries rely on a content management service from The Library Corporation, which carries the “youseemore. com” URL (such as: https://www.youseemore.com/mecklib/). Another group of libraries have URLs related to the LibGuides content management platform from Springhare (such as https://edgecombelibrary.libguides.com). Many libraries lacking budgets for building a website use free services such as Wix.com or Google Sites. The use of a commercial hosting service or content management system does not necessarily require the library's site operate through its domain or URL. Instead, the library can make a DNS configuration, creating a CNAME entry that creates an alias enabling the site to operate under its own domain instead of the one associated with its provider.
The other elements of the URL should be as simple and clear as possible. Some conventions have become well-established among libraries. For academic libraries, the URL may depend on whether or not the library website operates within the university site (such as https://myuniversity.edu/library) or is deployed independently (https://library.myuniversity. edu). Public libraries may be part of a city or county website (https://mycounty.state.us/library) or may have their own site (https://mypubliclibrary.org). Note that the convention of using “www” as part of the URL is less common in recent years. Libraries should also avoid including file names or other elements that will cause the URL to break should you need to change the underlying content management system. Rather, use the default page naming of your web server (https://mylibrary. org instead of https://mylibrary.org/index.html). The use of file names for the main site or key landing pages will result in unstable URLs that will break each time your library changes its hosting environment. Also avoid the domain elements associated with specific content management products (such as https://libguides.mylibrary.org). The URL for your library website should be considered as a constant brand that must live beyond any specific product or hosting arrangement.
Incorporating structured data into the library website will improve its discoverability through Google and other search engines. Structured data, following established vocabularies such as schema.org as well as standard descriptors in page headings are not visible to human visitors to your website, but enable search engine harvesting crawlers and other computerbased agents to more easily parse the content of the site. Many key elements of a library website can be expressed through schema.org, such as its organizational entity, physical address, geographic coordinates, phone number, operating hours, and event schedules. The inclusion of structured data brings the library into the realm of the semantic web, enabling interoperability with other information services in parallel with conveying information to individuals visiting the site.
Libraries should be careful in the use of multimedia content on the site. I have come across some library websites that automatically play music when launched. This is a feature that will not be appreciated. Likewise, there are few circumstances where an auto-play video might be warranted. Be judicious with rich media, finding a balance between using it to provide dynamic and enriching content but not surprising your visitors with unexpected audio or video.
It is essential for every page on the library website to load quickly. I've encountered many library websites that were difficult to use due to the slowness of each page. Website managers should naturally monitor website performance and identify any components or dependencies that may be introducing latency. The “network” tab of the Developer's Tools built into the Google Chrome browser details the performance of every component within a page.
It is very helpful to the visitors of the website to offer an e-mail address for contacting the library. Providing a built-in form to send messages is not user-friendly. While publishing an email address may lead to some unwanted messages, you are more likely to hear from your community members about questions or issues they want to ask. If you must use a form, be sure that it works. On many occasions I have composed a message on a library website only to receive an error when submitted.
Be sure to provide a “Favicon” as part of the library URL branding. This icon, though limited to a finite number of pixels, can be a simplified version of the library's logo or some other visual association with the library that will appear on browser tabs or other contexts.
These suggestions cover some of the basic technology concerns that should be addressed in the deployment of a library website. Most can be implemented easily and can be accomplished though incremental changes in the configuration of the web server. Others may involve more complex changes and may need to be incorporated into the library's next website redesign project. Libraries can't be complacent with their websites. They demand constant attention in many areas, including design and functionality in addition to the technical issues mentioned above.