Planning Drupal Development in Libraries
Content
11 12 13 14 15 16 17 18 19 20
THE TECH SET
Ellyssa Kroski, Series Editor
Drupal in Libraries
Kenneth J. Varnum
www.neal-schuman.com LIBRARY AND INFORMATION TECHNOLOGY ASSOCIATION
11 12 13 14 15 16 17 18 19 20
THE TECH SET
Ellyssa Kroski, Series Editor
#
Drupal in Libraries
Kenneth J. Varnum
AL A TechSource
An imprint of the American Library Association Chicago
www.neal-schuman.com
2012
© 2012 by Kenneth J. Varnum. Any claim of copyright is subject to applicable limitations and exceptions, such as rights of fair use and library copying pursuant to Sections 107 and 108 of the U.S. Copyright Act. No copyright is claimed for content in the public domain, such as works of the U.S. government. Printed in the United States of America Library of Congress Cataloging-in-Publication Data Varnum, Kenneth J., 1967– Drupal in libraries / Kenneth J. Varnum. p. cm. — (The tech set ; #14) Includes bibliographical references and index. ISBN 978-1-55570-778-1 (alk. paper) 1. Library Web sites—Design. 2. Drupal (Computer file) 3. Web site development. I. Title. Z674.75.W67V37 2012 006.7—dc23 2012007201
This paper meets the requirements of ANSI/NISO Z39.48-1992 (Permanence of Paper).
www.neal-schuman.com
CONTENTS
Foreword by Ellyssa Kroski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Types of Solutions Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Social Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v vii ix 1 13 21 33 39 91 99
8. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9. Developing Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Recommended Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Don’t miss this book’s companion website! Turn the page for details.
www.neal-schuman.com
iii
THE TECH SET® Volumes 11–20 is more than just the book you’re holding! These 10 titles, along with the 10 titles that preceded them, in THE TECH SET® series feature three components: 1. This book 2. Companion web content that provides more details on the topic and keeps you current 3. Author podcasts that will extend your knowledge and give you insight into the author’s experience The companion webpages and podcasts can be found at: www.alatechsource.org/techset/ On the website, you’ll go far beyond the printed pages you’re holding and: Access author updates that are packed with new advice and recommended resources Use the website comments section to interact, ask questions, and share advice with the authors and your LIS peers Hear these pros in screencasts, podcasts, and other videos providing great instruction on getting the most out of the latest library technologies For more information on THE TECH SET® series and the individual titles, visit www.neal-schuman.com/techset-11-to-20.
www.neal-schuman.com
PREFACE
You’ve likely picked up Drupal in Libraries because you’ve heard something about Drupal and want to know if it is a good fit for your organization. Or perhaps you’ve been told to “fix the website” and you’re exploring various technologies to make that request a reality. I wrote Drupal in Libraries because there was no similar book available when I was managing a major website redesign in Drupal. Much of what I include in this book is derived from the processes and lessons I learned as I investigated content management software, managed the development team that customized our Drupal installation, and worked closely with the project management team to redesign our library’s website. The lessons I learned— some the hard way—will save you time and effort. The days when an organization could essentially put up some HTML pages and call it a done deal are long past (if they ever truly existed). A multitude of tools and technologies exist to help libraries organize, publish, and maintain their content. One of the rising stars in this arena is the Drupal open source content management framework. So what is an “open source content management framework”? Healthy open source software tools create a community from their user base. This community helps augment and develop the tool itself, creating new functionality that is relevant to its users. Drupal and libraries have forged a particularly symbiotic relationship, with libraries large and small creating—and, most importantly, sharing—chunks of code to accomplish specific tasks.
ORGANIZATION AND AUDIENCE
Drupal in Libraries will guide readers step by step through the decisions and tasks needed to develop and launch a Drupal-powered website. Chapter 1 discusses open source and proprietary software and helps you understand the pros and cons of an open source approach. It ends with a discussion of
www.neal-schuman.com
vii
viii
Drupal in Libraries
Drupal concepts to help you understand the rest of the book. Chapter 2, “Types of Solutions Available,” describes the range of solutions available— from doing it yourself to outsourcing the entire development process, with various gradations in between. In Chapter 3, “Planning,” you will go through a planning process that will guide you to your initial functional specifications for your site. “Social Mechanics,” Chapter 4, gives you hints and suggestions to work with your IT department, colleagues, and management as you develop your technical specifications. The bulk of the how-to in Drupal in Libraries is in Chapter 5, “Implementation.” This chapter guides you through installing Drupal, adding modules, and developing your own themes (page layouts) and describes the modules created by other librarians for use on their sites. Chapters 6–8 discuss marketing your site, best practices for project management and development, and measuring the success and impact of the site once it launches. The book wraps up with a chapter on emerging trends and tools in Drupal and a look at the changes that might be expected when the next versions of Drupal (versions 8 and 9) are released in the years to come. Drupal in Libraries is for you, the information professional. It assumes that you have some knowledge of website design and architecture, but it does not require you to be a specialist. You may have some programming skills, but they are not required for you to make use of this book. Being a framework, not a “solution,” means that Drupal is powerful enough to accomplish almost any web content management task yet is focused on one thing—organizing web content—effectively. It is a tool set to manage web content and allow you, the web project manager, to rapidly customize the functionality you need.
www.neal-schuman.com
3
PLANNING
Inventory Your Resources Determine Your Goals Determine Scope of Development Effort Assess Staffing Needs Create Site Design Develop Functionality
A good project plan will get you through the project even when you run into unexpected speed bumps or problems along the way. Aside from building a firm understanding of the functionality you want to achieve in your new library website, you also need to address a range of fundamental questions at the outset. The adage goes, “failing to plan is planning to fail.” Like most adages, this one is a gross oversimplification. It still contains more than a grain of truth. You will not be able to identify, let alone arrive at a contingency option for, every possible problem or challenge you will face. However, by developing a collective understanding among all project stakeholders of the major desired outcomes, critical functionality, and interface features and developing a technology plan based on these items, you will reduce uncertainty and generate goodwill and understanding within your library. By the time you begin active development (see Chapter 5), you should be able to answer such basic questions as these: How much time, budget, and expertise do we have (or have access to) to build the site? What functionality is core to the project’s success, and what is secondary? What should the finished site look like? Who will do the work during construction, and who will maintain it once it’s built? Where will you host your site?
www.neal-schuman.com
21
22
Drupal in Libraries
It’s important to keep in mind that these are not necessarily sequential steps. You will want to start with an assessment of where you are and where you want to go, but then much of the rest of the process will happen simultaneously with answers to one question influencing options in other areas.
INVENTORY YOUR RESOURCES
Any large web project starts with a chicken-and-egg question (“How many resources do I need to build the site that I want to build given the time and resources I have available?”) and ends with a vague answer (“It depends.”). If you have ever contemplated an addition or renovation to your home, you know the initial conversations with your contractor can be maddening. You start with, “I want to add a family room,” to which the contractor responds, “How much do you want to spend?” You give a figure, which then turns into an estimate of what you can do for that money, which turns into a new figure, or changed features, or different finishes. Each decision you make informs the others; you rarely arrive directly at a precise target. Rather, you gradually go half the distance until you have ended up with a clearly defined goal. A good place to start is to take a set of basic inventories of resources. Who is available in your organization to work on the project? You will need to identify people capable of working in several areas. Managing Drupal itself is the obvious one; who will be doing the installations, configurations, and maintenance? Depending on the size of your library, the answer to this will vary. It might be your existing systems staff. It could be technology-savvy librarians who are interested and willing (or able to be convinced) to take on this task. You could hire short-term staff to handle development and turn over long-term maintenance to permanent staff. You also need to figure out who will be doing the design. Drupal is a modular development environment that separates the interface from the functionality, allowing different “themes” to be overlaid on the site with a relatively small impact on programming. An early decision point, then, is deciding whether to use an existing theme from the Drupal community, take an existing theme and make relatively minor modifications to it to suit your library’s existing graphic identity (color scheme, placement of logos, etc.), or develop a theme from scratch. The closer you get to ground-up development, the more time and efforts are required. Having a basic usability assessment process in place for stages of design from early prototypes to after you’ve launched your Drupal site is also important. This kind of assessment—designed to answer basic questions such as “Can users find functionality X?” or “Is the link to Y labeled properly?” to “Where should the link to the circulation desk be located?”—can be done
www.neal-schuman.com
Planning
23
effectively yet informally. It is important to the ultimate success of the project to do usability verification early and often. When we designed the University of Michigan Library’s site, we tested it repeatedly with library patrons using paper prototypes (printouts of pages mocked up in Adobe Photoshop), early versions in Drupal, and the finished version in Drupal.
DETERMINE YOUR GOALS
The second most important area of decisions centers on the functionality you want your site to have. What do patrons do when they come to your site? What resources do you offer them? How do they want to interact with your library when visiting virtually? You probably have a great deal of information about how your patrons interact with your current site. This could come from server log file analysis or tools such as Google Analytics. Perhaps you have conducted small focus groups of your patrons to ask them what they like and do not like about your site. It is likely that your library’s public services staff have a great deal of information about what patrons find easy to use and hard to use—after all, they are the ones who talk to the patrons after the site has failed—but it is still important to rely on first-person evidence. As you develop a list of functions for your site, start prioritizing them. What are the absolutely must-have items, what would be nice to have, and what would be icing on the cake? For most libraries, the must-have list will include things like these: Catalog search Database finder Online journal finder Event calendar Directions to the library, perhaps with an interactive map Library hours Managing patron accounts Contact links for the library, reference service, and circulation desks Signing up for the library newsletter Your list will without doubt be much longer and more detailed. Compiling the list is one piece of the task. Putting the functions into some sort of order is harder. You will need to think about your users’ needs. As your users are a diverse lot, consider developing personas to help you. Personas are archetypes for users. For example, you may be able to abbreviate your patron community into a half-dozen typical types: the student in need of research materials at the last minute; the genealogist looking for family history information; the
www.neal-schuman.com
24
Drupal in Libraries
small business owner doing competitive intelligence for his company; and a faculty member putting together a research proposal. Put yourself in the place of each of your personas and think about the kinds of tools and resources they will need from your website to get them through their tasks from start to finish. Then, combining this information with what you know from usage statistics, interactions with your patrons, and the tools and services the library feels are most valuable, come up with a priority list of functions your site cannot do without. Aaron Schmidt and Amanda Etches’s book User Experience (UX) Design for Libraries (THE TECH SET #18) has more on persona creation and use.
DETERMINE SCOPE OF DEVELOPMENT EFFORT
Regardless of where your Drupal site lives, you have three basic options for developing it: using Drupal out of the box, adding modules from the community pool, or modifying/creating modules to match your needs. Which option you choose depends largely on what you want to do—how different is the functionality you want to create from what others have already done— and what set of skills and capabilities you have to work with. We’ll discuss each of these three options in turn. It is likely that your site will end up reflecting a mixture of the second and third options—you will probably end up with a mix of community modules, community modules you adapt in small ways to meet your needs, and custom modules you create from scratch. The more custom modules you develop, and the more you customize community modules, the greater the long-term maintenance burden you take on. Let me explain. The Drupal community of users maintains modules and keeps them up-to-date (to improve functionality, to patch bugs, to close inadvertent security holes, and to keep the modules functional as Drupal’s core code evolves). To the extent that your modules are different from the modules shared with others, you will have a larger unshared burden to make sure that your site can survive an update to Drupal’s core with a minimum of effort on your part. This is the basic hierarchy you should follow as you consider module development: 1. Use a community module. There are more than 3,100 to choose from. 2. Modify a community module to meet your need, if you cannot find a way to use community modules to meet your needs. 3. As a last option, develop your own module, but only go this route if you cannot find a sufficiently similar module to modify. If you do pursue this option, consider submitting your new module back to the community so that others might adopt it and find ways to further improve it. Your site’s needs are probably not unique in the world of
www.neal-schuman.com
Planning
25
libraries or even in the world of Drupal libraries. What you create may be helpful to others.
Out-of-the-Box Drupal
One of Drupal’s strengths is that you have a fully functioning content management system as soon as you’ve installed it and performed the initial setup steps. Drupal comes with four basic themes (Bartik, Stark, Garland, and Seven). Each theme has a slightly different purpose. Bartik is the default theme for the public view of the site. Seven is the default administrative view (see Figure 3.1). Stark is a bare-bones theme designed to show the novice user how Drupal pages are structured, while Garland, which has been part of Drupal since Drupal 5, is more detailed and feature-rich. Drupal’s core, or basic, functionality is there as well. This means that you can turn the site on and start creating and publishing content immediately. Few organizations will want to have their site go live to the public without making some adjustments to the basic theme and functionality. However, with a bit of CSS customization, you can quickly change colors, font sizes, and so forth, to update the basic Garland theme. The Drupal community has created Figure 3.1: Drupal’s Site Administration Page in the Garland Theme
www.neal-schuman.com
26
Drupal in Libraries
an extensive collection of themes, all of which are available to you to “reskin” your site—all through a simple configuration interface (see Figure 3.2).
Use Community Modules
A plain download-and-install version of Drupal gives you the ability to create users and assign them roles in the site, publish pages, and build navigation menus, among other basic functions. All in all, this is sufficient to get a basic site up and running very quickly and allow you to establish authoring roles to match your organization’s needs. It will, for example, give some individuals Figure 3.2: Drupal’s Bartik and Seven Default Themes and the Contributed Zen Theme
www.neal-schuman.com
Planning
27
the authority to write and edit pages, others authority to write, edit, and delete pages, and still others who have full administrator access to the configuration panels to change the site’s look or functionality. You can change themes, establish navigation, and create page templates. In short, you can have a functioning site using Drupal with a modicum of development effort. You may even find that the content is more time-consuming to work with than the system itself. However, there are other functions that do not come “out of the box” and that must be downloaded and installed. I’ll discuss the mechanics of installing a new module in “Install Modules” in Chapter 5 (pp. 49–52); here, I’ll give an example of specific functionality a module can give you. Let’s say that you want to add the popular Pathauto module to give pages in your site human-readable URLs rather than Drupal’s default, somewhat unfriendly system-generated URLs. Without this module, a page titled “Getting to the Library” might have the unmemorable URL http://www.library.org/ node/31. Conveying no particularly important meaning to the user, the number is the identifier of the database entry for this particular page. A more user-friendly URL for this page might be http://www.library.org/gettingto-the-library. The Pathauto module automatically converts the page title into an alias for the actual URL and sets up the behind-the-scenes mappings for the human-readable URL and Drupal’s machine-generated one. Pathauto can also set up multiple aliases so that you can have multiple URLs—both http://www.library.org/directions and http://www.library.org/ getting-to-the-library direct to the same page. You might want to do this if the page title changed from the previous site but you wanted to make sure that bookmarks for the old link still worked.
Customize Your Own Modules
Drupal’s greatest strength, ease of customization, can be its weakness as well. Because of Drupal’s flexible architecture, a site administrator can add just about any kind of functionality through a new custom module. As a rule of thumb, avoid this practice unless there are truly no existing community modules that achieve the same goal or come close. If you do customize your own module, you should create it in such a way that it could be accepted as a community module if you chose to do so (see guidelines for this process at http://drupal.org/node/7765). At the least, following these good practices will reduce your future maintenance chores to the bare minimum, because a well-architected module that plays nicely with the current version of Drupal core will be more likely to play nicely with an updated version. And if Drupal core is updated, the migration path to new functionality equivalent to the superseded functionality is generally documented, making the module developer’s job easier.
www.neal-schuman.com
28
Drupal in Libraries
ASSESS STAFFING NEEDS
In addition to the staff, whether internal or outsourced, who will be doing the programming and design work, your Drupal site will likely involve a large portion of your library’s staff on the content side. While you can realistically outsource graphic and application design, you and your library staff will take responsibility for your content. It is the whole point of the site after all.
During Development
You are presumably replacing your current website, which may or may not be in a content management system, with a Drupal-powered one. The first step is to perform a content review so that you can separate content that needs to be moved to the new system from content that is no longer needed. There are several approaches to such an inventory. If your site is built of plain old HTML files, you can start from the file system’s directory to list out all of the nested files and folders. If your site is already in a content management system of some kind, it almost certainly has a site map or export tool that can list all of your site’s content. See “Recommended Reading” for resources on conducting a site inventory. The people who are responsible for the content should likewise be responsible for reviewing it and migrating it into the new system when the time comes.
Reviewing without Responsibility
When the University of Michigan Library migrated from flat files into Drupal, we asked the dozens of people systemwide to review their content for migration, with the understanding that any content they selected would be moved for them. We hired students to copy and paste from the webpages selected by staff into Drupal. Because there was no penalty for moving lots of content, many staff were lenient when it came to the content review and opted to keep everything. This resulted in our students moving a significant amount of outdated, redundant, or just plain not useful content into Drupal initially. When the project management group reviewed the often lengthy lists of content to be migrated and communicated more directly with the content owners, the second pass resulted in a much shorter list of content to migrate. As a related note, migrating the content centrally may be politically expedient, but giving the content owners a role in this process helps it go more smoothly and allows last-minute content decisions to happen in the flow.
As you review your content, there are several categories of content you may wish to consider leaving behind: Outdated information—pages describing services, events, tools, and so forth that are no longer offered by your library but that are still on
www.neal-schuman.com
Planning
29
your current site (even if those pages are “orphans,” no longer linked from anywhere). Orphaned pages—if it’s not linked to anywhere on your site, is it really useful? Duplicate content—for example, if you have the same information on library hours in multiple places, it is more difficult for your staff to keep the site accurate, and it is more confusing for the user. There is probably a great deal of similar content that could, and should, be consolidated.
After Launch
Once your Drupal site is launched, the big content push is over and you move into maintenance mode. You may not need to have all hands involved in content management, but it makes sense to establish a few roles for staff on the website. If you have a large organization, it may be useful to have people taking care of these roles in each unit. The simple hierarchy described here will likely work well for many organizations, but tailor the roles and responsibilities to meet your library’s particular needs: Content Author—the person who is authorized to write and edit content (whether at the unit or library level, depending on the size and style of your organization) Content Editor—the person who reviews new content, approves edits, and deletes unneeded pages from the site Site Administrator—the person who has the ability to manage Drupal itself, such as adding modules and updating themes (often several individuals have this role so that changes can be made without waiting for the admin to get back from vacation or illness) In some organizations, content authors are authorized to publish directly to the live site. In others, there is a review and editing stage. It generally makes sense to delegate the content questions to library staff who know most about the topic and not have this function in the systems office. Systems personnel understand the application but may not be best positioned to review content for accuracy or library style.
CREATE SITE DESIGN
Drupal keeps the look and feel of your site separate from functionality and content. As you think about what you say and how users interact with your site (the content and functionality), you should also be working on the design of the site. You may have an existing site whose design works well for
www.neal-schuman.com
30
Drupal in Libraries
you, even if the content is hard to manage. Or you may view moving to a content management system as an opportune time to revamp the interface as well. Here are some points you should consider as you plan your design. Does your current site’s design represent the image your library wants to portray? If your library is on the cutting edge of technology and services, do you want your site to be “edgy” as well? If your clientele’s needs are better met by a simple, functional design, then that is the way to go. Is your current site accessible to those with vision or other impairments? If you have not recently reviewed your site for compliance with web accessibility guidelines, a redesign is a terrific time to do so. (Handy resources for this are listed in “Recommended Reading.”)
Accessibility Is Part of Design
You should build accessibility reviews into your site’s development plan so that your website is fully accessible to those who use screen readers or other assistive technology. Validating against these tools early and often will make accessibility an easy outcome. While there is no single standard for defining an accessible site, two sets of guidelines are commonly followed (and may be required by state law or local policy). The first is required for U.S. Government agencies (and has been adopted by many state and local governments and other organizations) and is known as “Section 508” (see http://www.section508.gov/). The second, the Web Content Accessibility Guidelines [WCAG], is managed by the World Wide Web Consortium (see http://www.w3.org/WAI/intro/wcag). Developing your site with accessibility in mind generally leads to improved use for all users regardless of level of physical or cognitive disability.
What do your users (and your staff) think of your current design? If you are not sure, ask them. This can be done through a simple online survey. Another method is to provide images of a typical page in your current system or the new system as you design it, and ask patrons to simply circle design elements they like, cross out elements they do not like, and add anything that might be missing. You will receive a wealth of information about your users’ perceptions of your design in short order and can begin identifying parts of the design that work well and those that do not. Once you have this basic information about the site’s design needs you can start working on a theme. Themes are the way Drupal separates the “look and feel” of the site from the functionality of the site. They are written largely in HTML and CSS, although some PHP is needed to import the content for a particular page type display. As with modules, there are hundreds of
www.neal-schuman.com
Planning
31
community-contributed themes to start from, so, if you don’t see one you like, you can build your own from scratch or modify an existing theme that has most of what you need.
DEVELOP FUNCTIONALITY
This is where the rubber meets the road. What do you want users to do when they are on your Drupal site? They might want to search the catalog, reserve a meeting room, renew a book, get reference help, connect to a database, enroll in a class or workshop, or perform any number of other tasks. Figuring out the functions you want should be based significantly on the goals you are setting out to achieve. As in other stages of planning, perform a needs assessment to explore what your patrons would like to do if they could and what they use on your current site and listen to feedback (either actively solicited for this purpose or already submitted through other channels). Some goals may be met by a single function; others may require multiple functions or features to achieve. As you develop the list of functions, you can begin to compare them with both your goals and the pool of community modules. You will thus build a model of what you need and how you will achieve it and begin calculating the time needed to do any custom work. This exploration could be done through a simple table with a few columns: Function—What would this function do, who will use it, and how often will it be used? Goals Met—Of the goals you established, which ones does this function enable? Priority—How important is this function to the overall function of the site? Is this a must-have item, a nice-to-have item, or a bonus if you achieve it? Community Modules—Are there community modules that (in whole or in part) achieve this goal? Scope of Work—How much will it take to make the community module behave the way you would like or to develop your own module from scratch? At this early stage of your exploration, you may want to characterize this broadly as a small, moderate, or significant effort and then refine these estimates to actual development time as you learn more. Now comes the hard part—making decisions about priorities based on the information you have gathered. Having some consistency in the inputs will make these decisions understandable and communicable to other staff and to
www.neal-schuman.com
32
Drupal in Libraries
whatever constituencies are following the web redesign effort. As we’ll explore in the following chapter, keeping these constituencies informed about what is going on, and having consistent and open rationales for decisions, will go a long way toward smoothing the inevitable disagreements among them.
www.neal-schuman.com
INDEX
Page numbers followed by the letter “f” indicate figures; those followed by the letter “t” indicate tables.
A
Accessibility, 10, 30, 43, 102, 115–117 Acquia Drupal, 44 Activating, 50–52, 51f “AddtoAny,” 81 Administrative interface, 44, 45 organic groups, 8, 70–72, 71f reports and, 84–87, 85f, 86f, 87f Adobe Photoshop, 23 AJAX-based, 44–45 Akismet, 78 Alfresco, 6t Alpha testing, 104 Amazon.com, 16–17, 49 Analog, 110 Analytics, 107–111 click path analysis, 110–111 web server log files, 108–109 Ann Arbor (MI) District Library, 115–116 AntiSpam, 78 Apache, 40–41 API. See Application programming interface (API) Apple.com, 109 Application programming interface (API), 116–117 CRUD, 117 Drupal’s API, 87–89, 116–117 Architecture Drupal, 27, 100 information, 35–36
programming, 73 website, 82 Article discovery, 75, 115–116 Askey, Dale, 89 Audio, 113 Authoring group, 36 Available updates report, 101–102, 102f AWStats, 107
B
Backup, 48 hardware, 13–14, 16 safe computing,101–103 Bartik theme administrative interface, 45 colors, 50–52, 51f, 72 default for public view, 25 editing, 72, 74 example, 26f files, regions and blocks, 47t, 53f navigation, 53, 53f structure of, 73–74 Bartik.info, 73 Bartik-test, 74 Berra, Yogi, 4 Best practices content management, 103–104 Drupal way, 100–102, 102f launching site, 104–105 planning, 47t, 74, 99–100 safe computing, 102–103
www.neal-schuman.com
123
124
Drupal in Libraries
Code4lib Journal, 89 Color, activating, 50–52, 51f, 72 Communication, 34–37 Community, giving back to, 26–27, 26f, 89 Configuring library website, 55–61, 57f, 58f, 59f panels and, 65–67, 66f, 67f views and, 61–65, 62f, 63f Content categories, 82–83 creation, 56–59, 57f, 58f, 59f, 60–61, 92–93 creation interface, 45–47, 47t defined, 7 editor, 29 links, 3, 7, 57, 93, 94f, 96f, 97 management, 103–104 themes, 9–10 Content Creation Kit (CCK) constructing, 56–59, 57f, 58f, 59f, 60–61 panels, 65–67, 66f, 67f, 68f SOPAC and, 116 view and, 61–65, 62f, 63f Content management system (CMS) advisory groups, 35–36 buy-in, 35 change management, 34–35 efficiencies, 2–3 feature and functionality matrix, 6t vs. flat file, 1–3 open source vs. closed, 4 selecting, 4–5, 6t Cookies, 111 “Creating Drupal 7.x modules,” 88 Cron jobs, 44, 47t, 55 CRUD, 117 CSS. See Cascading Style Sheets (CSS) cURL, 50 Customize, 9–10, 14t, 24, 44, 73, 100–101 CSS and, 25 e-mail and, 69 functionality, 10 installation and, 48 modules and, 27, 55, 88t theme, 27, 74–75
Beta testing, 104 Bing, 47, 47f, 108 Black box system, 4 Blocks, 10, 45, 53–54, 53f module creation, 87–89 navigation, 53 panels and, 65, 67 tagging and, 78–80,79f, 80f themes and, 52 views and, 61, 65 Blogs, 2, 96 activating, 50–52, 51f RSS feed, 46, 81–82 software, 15 Blyberg, Jon, 115–116 Book page nodes, 45–46 Broken links, 93, 94f Browsers, 5, 50–51, 69, 73, 96, 111 analytics and, 108–109 Buytaert, Dries, 117
C
Calendars, 8 CAPTCHA, 78 Cascading Style Sheets (CSS), 2–3, 10, 30, 73, 92–93 customization, 25 defaults, 64 forthcoming updates, 117 ID fields, 65–66 module components, 88t panels and, 65–66 theme structure and, 73 Catalog (OPAC), 116 access, 75 integrating, 13, 39, 115 modules, 49 searching, 23, 31 serials and, 116 Cell phone, QR codes, 96, 97f Click path analysis, 110–111 Closed (proprietary) system, 4, 77 Cloud computing, 16–17, 117 Amazon Web Services, 16 CMS. See Content management system (CMS) Code sharing, 103 “Coder” module, 88
www.neal-schuman.com
Index
125
D
Daisy, 6t Darien (CT) Public Library, 115–116 Dashboard, 4, 50–52, 51f Databases activating, 50–52, 51f application, 40–42 backup, 101–103 connecting to, 31 CMSs and, 2 creation, 42, 43f Drupal, 74–76 entry, 8, 27 files, 48, 60 finder, 23 IP address and, 110 migration, 83–84 MyPHPAdmin, 42, 43 structure, 103 tables and, 7–8 Delicious, 81 Development community, 6t CMS and, 6t environment, 101 hosting options, 14t website, 17–20 Digg, 81 Digital Information Services Librarian, 36 Director of Communications, 36 Drupal activating, 50–52, 51f administrative interface, 59f, 65 architecture, 27, 35–36, 100 backup, 101–103 blocks, 10, 45, 53–54, 53f “Coder” module, 88 community giveback, 89 concepts, 2, 7–11, 23–25 configuring, 55–59, 57f, 58f, 59f, 60–65, 62f, 63f Content Creation Kit (CCK), 56–59, 57f, 58f, 59f, 60–61, 92–93, 116 content management, 4–5, 7–8, 10–11 customized, 9–10 database, 42, 43f, 74–75 defined, 5–6 development, 14t, 17–20, 24, 101
feature and function matrix, 6t file system and, 1–3, 47–49, 47f filter, 63–64, 78, 85–87 functions, 8, 31–32 Groups website, 7 installation, 8, 41–45, 41f, 52–54 integrating library resources, 74–76 library developer community and, 6–7 maintenance, 29 operating system creation, 40–41 outsourcing, 13, 14t, 18–19, 28–31 reports and, 45, 55f, 84–87, 85f, 86f, 87f script installation, 43 security, 34, 43–44, 77–78, 117 selecting, 4–5, 6t site design, 9–10, 29–31 SOPAC and CCK, 116 tagging, 78–80, 79f, 80f tools, 6t trends, 115–117 tutorials, 88 versions, 12, 115–117 vocabulary, 7, 17, 49 web root, 47–49, 47t See also Installation; Modules; Themes Drupal API, 87–89, 116–117 Drupal 5 migration, 12, 83–84 out-of-the-box, 25–26, 25f, 45 Drupal 6 Acquia, 44 administrative interface, 44 Content Creation Kit (CCK), 56 installation, 40–42 modules, 12, 48 Drupal 7 Content Creation Kit (CCK), 56 files, where to find them, 47t installation, 40–45 integrating library resources, 74–76 modules, 12, 48–49, 115 regions and blocks in Bartik theme, 53f reports, 25 themes, 72–73 trends, 115–117 tutorials, 88 Drupal 8, 116–117 Drupal 9, 116–117
www.neal-schuman.com
126
Drupal in Libraries
outsourcing, 18, 28 QR codes, 96, 97f Guides, 75–76
DrupalCon, 116–117 Drupalib, 7 Drupal.org, 41, 44, 46, 49–50, 82, 88, 89
E
E-mail form, 69 Etches, Amanda, 24 Evaluation. See Measuring achievement Event calendar, 23 EZproxy, 7
H
Hardware collaboration, 33 hosting and developing options, 13, 14t, 17–20 maintaining, 111 options, 14–16, 40 protection, 48 Harlan Hatcher Graduate Library, 3f Harvard University, 34 Headers, 65 Heterogeneous site, example of, 3f Homepage, 2, 3f Hosting cloud, 16–17 commercial, 40 developer, 17–21, 101 hardware, 13, 14t, 17–20 options, 14t, 13–17 server, 15–16 web server log files, 109–110, 109f HTML accessing data, 75 content management and, 1–3, 28, 30, 82 creating a document, 61 Drupal and, 10, 84, 92–93, 101, 117 file system, 47t filter, 61 modules and, 88 web server log files, 108–109
F
Facebook, 76, 81, 96, 115 Faculty Advisory Group, 35 FAQ interface, 9 Fast Company (magazine), 34 FCKeditor, 8 Feature and Functionality Matrix for Selecting a CMS, 6t FedEx, 34 Feedback, 31 social media and, 76–80, 77f, 79f, 80f Webform module, 67–69, 68f, 69f Feeds, 76, 83 Fields, 7–8, 56–61, 64–65, 69, 79–80, 87 activating, 50–52, 51f File system, 41–45, 47–49, 47f Filter, 63–64, 78, 85–87 Firefox, 5 Flash Player, 110 Flat file system, 1–3, 28 Flickr, 67, 115 Focus groups, 36 Footer, 53, 65 Functionality, 31–32
I
Icons, 66, 73–74 Images, 7, 11 adding, 42 backing up, 103 file system, 47t libraries, 30 themes and, 73–74 Implementation. See Installation; Methods and practices Information Architecture Advisory Group, 35 Inline, 80
G
Garland theme, 25, 25f, 47t Git, 48 Global Comment Settings Window, 71f Google, 47f, 82, 108–109 Google Analytics, 23, 49, 107, 110–111 Googlebot, 109 Graphics Drupal and, 65 file system and, 47f identity and, 2–3, 3f, 18, 22
www.neal-schuman.com
Index
Installation administrator interface, 44–45 configuring website, 55–61, 57f, 58f, 59f panels and, 65–67, 66f, 67f views and, 61–65, 62f, 63f content creating, 42–43, 43f, 45–46 files, 41–45, 41f, 47–49, 47f hardware, 39–41 modules, 49–52, 51f, 87–89, 88t operating environment, 40–41 panels, 65–67, 66f, 67f script, 43 security, 34, 43–44, 77–78, 117 setup, 42–44 themes, 52–54, 53f updates, 54–55, 55f web root, 47–49, 47t website download, 41 Institutional Review Board (IRB), 112 Interactive design, 23–24 site, 9–10, 29–31 tagging, 78–80, 79f, 80f Interface administrative, 57–62, 66, 57f, 58f, 59f, 62f, 63f, 66f content management systems and, 3–4 Drupal and, 11–12, 14t, 26, 40, 103 installing, 42, 44–47, 47t, 48–49 LibGuides, 75 modules and, 116–117 organic groups, 72 staff and, 93–94, 94f themes, 52–56, 55f URL and, 49–52 Webform page, 68f website and, 7, 9, 97, 101, 107 Internal developer, 19–20 Internet Explorer, 73 Internet provider, 15 IP address, 69 spam and, 78 web log files, 109f, 110 IT department, 33–34, 44
127
L
J
JavaScript, 47, 108 Joomla!, 6t
LAMP, 40, 48 Launch, 36–37 marketing, 91–92, 94–98 testing, 104–105 Layout, page, 2 Legacy application, 2 LibGuides, 75–76 Library administration, 15, 35, 112 categories, 82–83 contact, 3, 7, 23, 93, 94f, 96f, 97, 115 content creation, 56–59, 57f, 58f, 59f, 60–61 content creation management, 103–104 developer community and, 6–7, 101 interactive design needs, 23–24, 30 IT department, 33–34, 44 LibGuides, 75–76 migration, 83–84 newsletter, 23 patron accounts, 23 site, 9–10, 29–31 staff, 34, 92–95, 94f web team, 36 Library branch, 56–61, 70, 86 panels and, 65–67 social media and, 76, 79 theme customization, 74 views and, 61–65, 63f LinkedIn, 81 Links, 2–3, 7, 97 adding, 64 administrative, 45–46 broken, 27, 29, 93, 94f database and, 83–84 downloading, 44 log-in, 56 module and, 52, 54 panels and, 10 resources and, 23, 56–57, 61, 76, 87 social media and, 76, 78, 81 Linux, 40, 42, 44, 48 Localhost, 109 Log analysis, 107, 109–110 Logo, 3, 10, 22, 53, 53f, 56 logo.png, 73
www.neal-schuman.com
128
Drupal in Libraries
installation, 40–43, 41f integrating resources into, 83–84 LibGuides, 75–76 organic groups, 8, 70–72, 71f page layout, 2 panels, 65–67, 66f, 67f reports and, 45, 55f, 84–87, 85f, 86f, 87f RSS feeds, 81–82 search engine optimization (SEO), 82 security, 34, 43–44, 77–78, 117 setup, 43–44 social media enabling, 76–78, 77f sharing, 80–81, 81f tagging, 78–80, 79f, 80f style, 72–73 theme installation, 9–10, 52–54, 53f, 73 theme installation, customization of, 74–75 up-to-date, 54–55, 55f, 84–87, 85f, 86f, 87f See also Installation; Modules Metrics. See Measuring achievement Microsoft Word, 93 Migration, 83–84 Mobile, 117 Modules activating, 50–52, 51f, 77 blocks, 87–89 community, 26–27, 26f, 31, 89 creation, 87–89, 88t customized, 27, 55–56, 88t environment, 101–103 file system, 47–49, 47f functions, 2, 6t, 7–8, 10–12, 11f, 31, 75 installation, 40, 49–52, 51f, 75, 77–81 interface, 116–117 options, 4, 24–27, 42, 45–46, 83 organic groups, 8, 70–72, 71f out-of-the-box, 24–27, 25f panels, 10–11, 27, 65–67, 66f, 67f, 80 reports, 54–55, 55f, 88–89, 111 up-to-date, 53–55, 55f, 102f, 115–117 views, 11, 11f, 40, 52, 61–66, 62f, 63f, 66f integrating, 75–76 updating, 84–87, 116–117 web root, 47–49, 47t See also Themes MODx, 6t
M
Macintosh, 109 Maintenance, 29 Malicious software, 50 See also Security Marketing change and, 34–35, 91–92, 94, 96, 98 external, 91–92 integrating library resources, 74–76 interface, easy, 93 links and, 93, 94f, 96f, 97 plan, 97–98 public, 95–97 QR codes, 96, 97f search engine optimization (SEO), 82 social media, 95–97 staff, 91–95, 94f Measuring achievement analytics, 107–111 AWStats, 107 click path analysis, 110–111 Google Analytics, 107–108 log files, 108–110, 109f observation, 112–113 questions, 108 selecting a CMS, 6t server log analysis, 109–110 surveys, 111–112 testing, 113 user feedback, 31, 67–69, 68f, 69f, 108–109 social media and, 76–80, 77f tagging, 79–80, 79f, 80f web analytics, 108–111, 109f web log files, 108–110, 109f Methods and practices administrator interface, 44–45 Amazon.com, 79 community giveback, 89 configuring, 55–59, 57f, 58f, 59f, 60–65, 62f, 63f content, 45–46, 70, 82–84 creating operating environment, 40–41, 43f database migration, 83–84 feedback, 67–69, 68f, 69f file system, 47–49, 47f HTML, 45, 53, 67, 70, 72, 74, 80, 84
www.neal-schuman.com
Index
Mollom, 78 MyPHPAdmin, 42, 43f MySQL, 17–19, 40–42 Acquia Drupal, 44 Pathauto, 8 Perl, 2 PHP content management and, 2 customization, 74, 84 design and, 30, 88 development and, 19, 100 Drupal and, 10, 17 file system and, 47f operating environment, 40–43 style and structure with, 73 Planning. See Project management Plone, 6t PostgreSQL, 41 Press release, 95 Priority, 31 Product availability, 6t Profiles, 47t Programming, 19, 73, 76 API, 116 staff, 14t, 17, 22, 28 Project management change and, 34–35 communication, 34–37 content, 21–24, 28–29 development, 21–22, 101 functionality, 23–24, 31–32 goals, 23–24 interactive, 23–24 inventory resources, 22–23 IT department, 33–34, 44 modules, 26–27 needs assessment, 31–32 out-of-the-box, 25–26, 25f, 45 planning, 21–22 redesign, 30, 32 scope of, 24–25 site design, 29–31 staffing needs, 28–29 stakeholders, 21, 35 transition, 34 usability assessment, 22–23 web team, 36 See also Best practices; Marketing Public relations. See Marketing
129
N
Navigation content, 2–3, 8, 10, 45, 53, 70, 72, 80, 83 interface, 74 menu, 26–27, 26f, 67 panels, 65 Node, 11, 60–62, 86–87, 93 book page nodes, 46 defined, 8 panel and, 65, 68 social media and, 76–77, 81, 84 themes and, 72–74 views and, 64
O
Observation, 112–113 Online journal finder, 23 OPAC. See Catalog (OPAC) Open source systems black box system, 4 vs. closed systems, 4–5 Drupal and, 5–6, 6t, 8, 40–41, 54, 89 pros and cons, 1–3, 33–34 OpenURL resolver, 7 Operating systems, 17, 40 closed (proprietary), 4, 77 environment, 40–41, 55 open source, 2–6, 5–6, 6t, 8, 33–34, 40–41, 54 Organic groups, 8, 70–72, 71f Orphaned pages, 28 Outdated information, 28–29 Out-of-the-box modules, 25–26, 25f, 45 Outsourcing, 13, 14t developers, 18–19 staffing, 28–31 Overlays, 22
P
Palos Verdes (CA) Library District, 115 Panels. See Modules
Q
QR codes, 96, 97f
www.neal-schuman.com
130
Drupal in Libraries
Social mechanics buy-in, 35 change management, 34–35 colleagues, 34 committees, 35–36 communications, 33, 36 IT department, 33–34, 44 staff, 34–37 web team, 36 Social media commenting, 76–78 enabling, 76–78, 77f RSS feeds, 81–82 sharing, 80–81, 81f tagging, 78–80, 79f, 80f Social OPAC. See SOPAC “Social Share,” 81 Software development project, 13–15, 17–18 internal development, 19–20 malicious, 50 outsourcing, 18–19 See also Drupal; Hosting; Security Sony Music, 34 SOPAC, 75, 115–116 Spam, 78 Springshare, 75 SQLite, 41 Staff development and, 14f, 15, 17–19, 30, 34–36, 99 marketing to, 92–95, 94f needs, 8–9, 22, 28–29, 70, 72 Stark theme design, 25, 47t Statistics. See Measuring achievement Styling, 72–73 Subversion (SVN), 48 Summon article discovery integration, 115–116 Serials Solutions, 116 Sun Microsystems, 34 Support availability, 6t Surveys, 111–112
R
Regions and Blocks in Drupal 7’s Bartik Theme, 53f Release mechanism, 6t Reports, 45, 82, 96, 112 administrative interface, 93–94, 94f Available Updates report, 101–102, 102f modules and, 54–55, 55f, 88–89 views and, 61, 84–87, 85f, 86f, 87f web server log files, 109–110 Robots.txt, 47 Roles, organic groups and, 8, 70–72, 71f RSS feeds, 46, 65, 76, 81–84
S
Safari, 109 Safe computing, 101–103 Sandbox project, 89 Scalability, 6t Schmidt, Aaron, 24 Scope of project, 31 Screenshot.png, 73 Script installation, 43 Search engine optimization (SEO), 82 Search phrases, 93 Security Drupal and, 43–44 holes, 24 malicious software, 50 patches, 15, 117 risks and, 33–34 safeguards, 77–78, 101–102, 102f Serials solutions article discovery integration, 115–116 Summon, 116 Server choosing, 1, 13–16, 14t cloud, 16–17 log analysis, 109–110 Seven theme design, 25, 26f, 47t SilverStripe, 6t Site administrator, 29 design, 9–10, 29–31 Skin, 9 file system, 47t reskin, 26 See also Themes
T
Tagging, 78–80, 79f, 80f Taxonomy Manager, 8 Technology Advisory Group, 35
www.neal-schuman.com
Index
Template.php, 73 Templates, 2–4, 9–10, 54, 80, 110 creating, 27 template.php, 72 themes and, 73–74 Testing, 94, 96, 97, 101–102 Bartik-test, 74 changes, 54–55 development, 18, 48 Institutional Review Board (IRB), 112 launch, 104–105 user, 23, 113 Themes basic, 25–27, 25f, 26f customization, 27, 74–75 default, 9–10 description, 9–10 installation, 52–54, 53f structure, 73–74 style and, 73 up-to-date, 54–55, 55f web root, 47–49, 47t Timeline, 97, 99 Trends, future API, 116 article discovery integration, 115–116 forthcoming, 116–117 modules, forthcoming, 115–116 Serials Solutions, 116 Social OPAC, 115–116 Tutorials, 88 Twitter, 49, 81, 96 TypePad, 78 TYPO3, 6t
131
Unix, 17, 40, 42, 48 Updates, 54–55 Available Updates report, 101–102, 102f installation, 49–50 OpenURL resolver, 7–8 reports and, 45, 55f, 84–87, 85f, 86f, 87f URL, 87, 97 User Experience (UX) Design for Libraries (Schmidt and Etches), 24 Users ID, 108 marketing plan, 97–98 needs, 31–32 organic groups, 8, 70–72, 71f roles, 9 testing, 113
V
Video, 75, 113 Views. See Modules
W
WAMP, 40, 48 Web Content Manager, 36 Web log files, 108–110, 109f Web root, 47–49, 47t Web Systems Manager, 36 Webform module, 67–69, 68f, 69f WebGU, 6t Website accessibility, 10, 30, 43, 102, 115–117 categories, 82–83 configuring, 55–61, 57f, 58f, 59f panels and, 65–67, 66f, 67f views and, 61–65, 62f, 63f content creation, 56–59, 57f, 58f, 59f, 60–61 content creation management, 2, 103–104 customize, 9–10, 14t, 24, 44, 73, 100–101 CSS and, 25 e-mail and, 69 installation and, 48 modules and, 27, 55, 88t theme, 27, 74–75 design, 9–10, 29–31 development, 14t, 17–20, 101 FAQ interface, 9
U
Universally unique identifiers (UUIDs), 117 University of Michigan Library categories, 82–83 committees and, 35–36 Harlan Hatcher Graduate Library, 3f homepage, 3f needs, 28 report, 94f Serials Solutions, Summon, 116 website, 2, 23, 28 XML and, 75–76
www.neal-schuman.com
132
Drupal in Libraries
“We Love Open Source Software. No, You Can’t Have Our Code” (Askey), 89 Wget, 50 White House website, 34 Wiki, 15 Windows, 17, 40, 42, 44, 48 WordPress Import, 45, 76, 83
Website (cont’d.) feedback, 31, 67–69, 68f, 69f social media and, 76–80, 77f tagging, 79–80, 79f, 80f filters, 63–64, 78, 85–87 functionality, 31–32 goals, 23–25 identity and, 2–3, 3f, 18, 22 interactive design, 23–24 LibGuides, 75–76 QR codes, 96, 97f updating, 84–87, 85f, 86f, 87f, 117 user, 31–32, 108 web server log files, 108–109 See also Drupal; Hosting; Measuring achievement
X
XML, 75–76
Y
YouTube, 75
Z
Zen theme, 10, 26f
www.neal-schuman.com
“
This is the series to acquire and share in any institution over the next year. I think of it as a cost-effective way to attend the equivalent of ten excellent technology management courses led by a dream faculty! TECH SET® #11–20 will help librarians stay relevant, thrive, and survive. It is a must-read for all library leaders and planners. — Stephen Abram, MLS, Vice President, Strategic Relations and Markets, Cengage Learning
”
Drupal in Libraries is part of THE TECH SET® VOLUMES 11–20, a series of concise guides edited by Ellyssa Kroski and offering practical instruction from the field’s hottest tech gurus. Each title in the series is a one-stop passport to an emerging technology. If you’re ready to start creating, collaborating, connecting, and communicating through cutting-edge tools and techniques, you’ll want to get primed by all the books in THE TECH SET®. New tech skills for you spell new services for your patrons: • Learn the latest, cutting-edge technologies. • Plan new library services for these popular applications. • Navigate the social mechanics involved with gaining buy-in for these forward-thinking initiatives. • Utilize the social marketing techniques used by info pros. • Assess the benefits of these new technologies to maintain your success. • Follow best practices already established by innovators and libraries using these technologies. Find out more about each topic in THE TECH SET® VOLUMES 11–20 and preview the Tables of Contents online at www.alatechsource.org/techset/. 11. Cloud Computing for Libraries, by Marshall Breeding 12. Building Mobile Library Applications, by Jason A. Clark 13. Location-Aware Services and QR Codes for Libraries, by Joe Murphy 14. Drupal in Libraries, by Kenneth J. Varnum 15. Strategic Planning for Social Media in Libraries, by Sarah K. Steiner 16. Next-Gen Library Redesign, by Michael Lascarides 17. Screencasting for Libraries, by Greg R. Notess 18. User Experience (UX) Design for Libraries, by Aaron Schmidt and Amanda Etches 19. IM and SMS Reference Services for Libraries, by Amanda Bielskas and Kathleen M. Dreyer 20. Semantic Web Technologies and Social Searching for Librarians, by Robin M. Fay and Michael P. Sauers
Each multimedia title features a book, a companion website, and a podcast to fully cover the topic and then keep you up-to-date.
American Library Association 50 E. Huron Street Chicago, IL 60611 1 (866) SHOPALA (866) 746-7252 www.neal-schuman.com
THE TECH SET
Ellyssa Kroski, Series Editor
Drupal in Libraries
Kenneth J. Varnum
www.neal-schuman.com LIBRARY AND INFORMATION TECHNOLOGY ASSOCIATION
11 12 13 14 15 16 17 18 19 20
THE TECH SET
Ellyssa Kroski, Series Editor
#
Drupal in Libraries
Kenneth J. Varnum
AL A TechSource
An imprint of the American Library Association Chicago
www.neal-schuman.com
2012
© 2012 by Kenneth J. Varnum. Any claim of copyright is subject to applicable limitations and exceptions, such as rights of fair use and library copying pursuant to Sections 107 and 108 of the U.S. Copyright Act. No copyright is claimed for content in the public domain, such as works of the U.S. government. Printed in the United States of America Library of Congress Cataloging-in-Publication Data Varnum, Kenneth J., 1967– Drupal in libraries / Kenneth J. Varnum. p. cm. — (The tech set ; #14) Includes bibliographical references and index. ISBN 978-1-55570-778-1 (alk. paper) 1. Library Web sites—Design. 2. Drupal (Computer file) 3. Web site development. I. Title. Z674.75.W67V37 2012 006.7—dc23 2012007201
This paper meets the requirements of ANSI/NISO Z39.48-1992 (Permanence of Paper).
www.neal-schuman.com
CONTENTS
Foreword by Ellyssa Kroski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Types of Solutions Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Social Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v vii ix 1 13 21 33 39 91 99
8. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9. Developing Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Recommended Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Don’t miss this book’s companion website! Turn the page for details.
www.neal-schuman.com
iii
THE TECH SET® Volumes 11–20 is more than just the book you’re holding! These 10 titles, along with the 10 titles that preceded them, in THE TECH SET® series feature three components: 1. This book 2. Companion web content that provides more details on the topic and keeps you current 3. Author podcasts that will extend your knowledge and give you insight into the author’s experience The companion webpages and podcasts can be found at: www.alatechsource.org/techset/ On the website, you’ll go far beyond the printed pages you’re holding and: Access author updates that are packed with new advice and recommended resources Use the website comments section to interact, ask questions, and share advice with the authors and your LIS peers Hear these pros in screencasts, podcasts, and other videos providing great instruction on getting the most out of the latest library technologies For more information on THE TECH SET® series and the individual titles, visit www.neal-schuman.com/techset-11-to-20.
www.neal-schuman.com
PREFACE
You’ve likely picked up Drupal in Libraries because you’ve heard something about Drupal and want to know if it is a good fit for your organization. Or perhaps you’ve been told to “fix the website” and you’re exploring various technologies to make that request a reality. I wrote Drupal in Libraries because there was no similar book available when I was managing a major website redesign in Drupal. Much of what I include in this book is derived from the processes and lessons I learned as I investigated content management software, managed the development team that customized our Drupal installation, and worked closely with the project management team to redesign our library’s website. The lessons I learned— some the hard way—will save you time and effort. The days when an organization could essentially put up some HTML pages and call it a done deal are long past (if they ever truly existed). A multitude of tools and technologies exist to help libraries organize, publish, and maintain their content. One of the rising stars in this arena is the Drupal open source content management framework. So what is an “open source content management framework”? Healthy open source software tools create a community from their user base. This community helps augment and develop the tool itself, creating new functionality that is relevant to its users. Drupal and libraries have forged a particularly symbiotic relationship, with libraries large and small creating—and, most importantly, sharing—chunks of code to accomplish specific tasks.
ORGANIZATION AND AUDIENCE
Drupal in Libraries will guide readers step by step through the decisions and tasks needed to develop and launch a Drupal-powered website. Chapter 1 discusses open source and proprietary software and helps you understand the pros and cons of an open source approach. It ends with a discussion of
www.neal-schuman.com
vii
viii
Drupal in Libraries
Drupal concepts to help you understand the rest of the book. Chapter 2, “Types of Solutions Available,” describes the range of solutions available— from doing it yourself to outsourcing the entire development process, with various gradations in between. In Chapter 3, “Planning,” you will go through a planning process that will guide you to your initial functional specifications for your site. “Social Mechanics,” Chapter 4, gives you hints and suggestions to work with your IT department, colleagues, and management as you develop your technical specifications. The bulk of the how-to in Drupal in Libraries is in Chapter 5, “Implementation.” This chapter guides you through installing Drupal, adding modules, and developing your own themes (page layouts) and describes the modules created by other librarians for use on their sites. Chapters 6–8 discuss marketing your site, best practices for project management and development, and measuring the success and impact of the site once it launches. The book wraps up with a chapter on emerging trends and tools in Drupal and a look at the changes that might be expected when the next versions of Drupal (versions 8 and 9) are released in the years to come. Drupal in Libraries is for you, the information professional. It assumes that you have some knowledge of website design and architecture, but it does not require you to be a specialist. You may have some programming skills, but they are not required for you to make use of this book. Being a framework, not a “solution,” means that Drupal is powerful enough to accomplish almost any web content management task yet is focused on one thing—organizing web content—effectively. It is a tool set to manage web content and allow you, the web project manager, to rapidly customize the functionality you need.
www.neal-schuman.com
3
PLANNING
Inventory Your Resources Determine Your Goals Determine Scope of Development Effort Assess Staffing Needs Create Site Design Develop Functionality
A good project plan will get you through the project even when you run into unexpected speed bumps or problems along the way. Aside from building a firm understanding of the functionality you want to achieve in your new library website, you also need to address a range of fundamental questions at the outset. The adage goes, “failing to plan is planning to fail.” Like most adages, this one is a gross oversimplification. It still contains more than a grain of truth. You will not be able to identify, let alone arrive at a contingency option for, every possible problem or challenge you will face. However, by developing a collective understanding among all project stakeholders of the major desired outcomes, critical functionality, and interface features and developing a technology plan based on these items, you will reduce uncertainty and generate goodwill and understanding within your library. By the time you begin active development (see Chapter 5), you should be able to answer such basic questions as these: How much time, budget, and expertise do we have (or have access to) to build the site? What functionality is core to the project’s success, and what is secondary? What should the finished site look like? Who will do the work during construction, and who will maintain it once it’s built? Where will you host your site?
www.neal-schuman.com
21
22
Drupal in Libraries
It’s important to keep in mind that these are not necessarily sequential steps. You will want to start with an assessment of where you are and where you want to go, but then much of the rest of the process will happen simultaneously with answers to one question influencing options in other areas.
INVENTORY YOUR RESOURCES
Any large web project starts with a chicken-and-egg question (“How many resources do I need to build the site that I want to build given the time and resources I have available?”) and ends with a vague answer (“It depends.”). If you have ever contemplated an addition or renovation to your home, you know the initial conversations with your contractor can be maddening. You start with, “I want to add a family room,” to which the contractor responds, “How much do you want to spend?” You give a figure, which then turns into an estimate of what you can do for that money, which turns into a new figure, or changed features, or different finishes. Each decision you make informs the others; you rarely arrive directly at a precise target. Rather, you gradually go half the distance until you have ended up with a clearly defined goal. A good place to start is to take a set of basic inventories of resources. Who is available in your organization to work on the project? You will need to identify people capable of working in several areas. Managing Drupal itself is the obvious one; who will be doing the installations, configurations, and maintenance? Depending on the size of your library, the answer to this will vary. It might be your existing systems staff. It could be technology-savvy librarians who are interested and willing (or able to be convinced) to take on this task. You could hire short-term staff to handle development and turn over long-term maintenance to permanent staff. You also need to figure out who will be doing the design. Drupal is a modular development environment that separates the interface from the functionality, allowing different “themes” to be overlaid on the site with a relatively small impact on programming. An early decision point, then, is deciding whether to use an existing theme from the Drupal community, take an existing theme and make relatively minor modifications to it to suit your library’s existing graphic identity (color scheme, placement of logos, etc.), or develop a theme from scratch. The closer you get to ground-up development, the more time and efforts are required. Having a basic usability assessment process in place for stages of design from early prototypes to after you’ve launched your Drupal site is also important. This kind of assessment—designed to answer basic questions such as “Can users find functionality X?” or “Is the link to Y labeled properly?” to “Where should the link to the circulation desk be located?”—can be done
www.neal-schuman.com
Planning
23
effectively yet informally. It is important to the ultimate success of the project to do usability verification early and often. When we designed the University of Michigan Library’s site, we tested it repeatedly with library patrons using paper prototypes (printouts of pages mocked up in Adobe Photoshop), early versions in Drupal, and the finished version in Drupal.
DETERMINE YOUR GOALS
The second most important area of decisions centers on the functionality you want your site to have. What do patrons do when they come to your site? What resources do you offer them? How do they want to interact with your library when visiting virtually? You probably have a great deal of information about how your patrons interact with your current site. This could come from server log file analysis or tools such as Google Analytics. Perhaps you have conducted small focus groups of your patrons to ask them what they like and do not like about your site. It is likely that your library’s public services staff have a great deal of information about what patrons find easy to use and hard to use—after all, they are the ones who talk to the patrons after the site has failed—but it is still important to rely on first-person evidence. As you develop a list of functions for your site, start prioritizing them. What are the absolutely must-have items, what would be nice to have, and what would be icing on the cake? For most libraries, the must-have list will include things like these: Catalog search Database finder Online journal finder Event calendar Directions to the library, perhaps with an interactive map Library hours Managing patron accounts Contact links for the library, reference service, and circulation desks Signing up for the library newsletter Your list will without doubt be much longer and more detailed. Compiling the list is one piece of the task. Putting the functions into some sort of order is harder. You will need to think about your users’ needs. As your users are a diverse lot, consider developing personas to help you. Personas are archetypes for users. For example, you may be able to abbreviate your patron community into a half-dozen typical types: the student in need of research materials at the last minute; the genealogist looking for family history information; the
www.neal-schuman.com
24
Drupal in Libraries
small business owner doing competitive intelligence for his company; and a faculty member putting together a research proposal. Put yourself in the place of each of your personas and think about the kinds of tools and resources they will need from your website to get them through their tasks from start to finish. Then, combining this information with what you know from usage statistics, interactions with your patrons, and the tools and services the library feels are most valuable, come up with a priority list of functions your site cannot do without. Aaron Schmidt and Amanda Etches’s book User Experience (UX) Design for Libraries (THE TECH SET #18) has more on persona creation and use.
DETERMINE SCOPE OF DEVELOPMENT EFFORT
Regardless of where your Drupal site lives, you have three basic options for developing it: using Drupal out of the box, adding modules from the community pool, or modifying/creating modules to match your needs. Which option you choose depends largely on what you want to do—how different is the functionality you want to create from what others have already done— and what set of skills and capabilities you have to work with. We’ll discuss each of these three options in turn. It is likely that your site will end up reflecting a mixture of the second and third options—you will probably end up with a mix of community modules, community modules you adapt in small ways to meet your needs, and custom modules you create from scratch. The more custom modules you develop, and the more you customize community modules, the greater the long-term maintenance burden you take on. Let me explain. The Drupal community of users maintains modules and keeps them up-to-date (to improve functionality, to patch bugs, to close inadvertent security holes, and to keep the modules functional as Drupal’s core code evolves). To the extent that your modules are different from the modules shared with others, you will have a larger unshared burden to make sure that your site can survive an update to Drupal’s core with a minimum of effort on your part. This is the basic hierarchy you should follow as you consider module development: 1. Use a community module. There are more than 3,100 to choose from. 2. Modify a community module to meet your need, if you cannot find a way to use community modules to meet your needs. 3. As a last option, develop your own module, but only go this route if you cannot find a sufficiently similar module to modify. If you do pursue this option, consider submitting your new module back to the community so that others might adopt it and find ways to further improve it. Your site’s needs are probably not unique in the world of
www.neal-schuman.com
Planning
25
libraries or even in the world of Drupal libraries. What you create may be helpful to others.
Out-of-the-Box Drupal
One of Drupal’s strengths is that you have a fully functioning content management system as soon as you’ve installed it and performed the initial setup steps. Drupal comes with four basic themes (Bartik, Stark, Garland, and Seven). Each theme has a slightly different purpose. Bartik is the default theme for the public view of the site. Seven is the default administrative view (see Figure 3.1). Stark is a bare-bones theme designed to show the novice user how Drupal pages are structured, while Garland, which has been part of Drupal since Drupal 5, is more detailed and feature-rich. Drupal’s core, or basic, functionality is there as well. This means that you can turn the site on and start creating and publishing content immediately. Few organizations will want to have their site go live to the public without making some adjustments to the basic theme and functionality. However, with a bit of CSS customization, you can quickly change colors, font sizes, and so forth, to update the basic Garland theme. The Drupal community has created Figure 3.1: Drupal’s Site Administration Page in the Garland Theme
www.neal-schuman.com
26
Drupal in Libraries
an extensive collection of themes, all of which are available to you to “reskin” your site—all through a simple configuration interface (see Figure 3.2).
Use Community Modules
A plain download-and-install version of Drupal gives you the ability to create users and assign them roles in the site, publish pages, and build navigation menus, among other basic functions. All in all, this is sufficient to get a basic site up and running very quickly and allow you to establish authoring roles to match your organization’s needs. It will, for example, give some individuals Figure 3.2: Drupal’s Bartik and Seven Default Themes and the Contributed Zen Theme
www.neal-schuman.com
Planning
27
the authority to write and edit pages, others authority to write, edit, and delete pages, and still others who have full administrator access to the configuration panels to change the site’s look or functionality. You can change themes, establish navigation, and create page templates. In short, you can have a functioning site using Drupal with a modicum of development effort. You may even find that the content is more time-consuming to work with than the system itself. However, there are other functions that do not come “out of the box” and that must be downloaded and installed. I’ll discuss the mechanics of installing a new module in “Install Modules” in Chapter 5 (pp. 49–52); here, I’ll give an example of specific functionality a module can give you. Let’s say that you want to add the popular Pathauto module to give pages in your site human-readable URLs rather than Drupal’s default, somewhat unfriendly system-generated URLs. Without this module, a page titled “Getting to the Library” might have the unmemorable URL http://www.library.org/ node/31. Conveying no particularly important meaning to the user, the number is the identifier of the database entry for this particular page. A more user-friendly URL for this page might be http://www.library.org/gettingto-the-library. The Pathauto module automatically converts the page title into an alias for the actual URL and sets up the behind-the-scenes mappings for the human-readable URL and Drupal’s machine-generated one. Pathauto can also set up multiple aliases so that you can have multiple URLs—both http://www.library.org/directions and http://www.library.org/ getting-to-the-library direct to the same page. You might want to do this if the page title changed from the previous site but you wanted to make sure that bookmarks for the old link still worked.
Customize Your Own Modules
Drupal’s greatest strength, ease of customization, can be its weakness as well. Because of Drupal’s flexible architecture, a site administrator can add just about any kind of functionality through a new custom module. As a rule of thumb, avoid this practice unless there are truly no existing community modules that achieve the same goal or come close. If you do customize your own module, you should create it in such a way that it could be accepted as a community module if you chose to do so (see guidelines for this process at http://drupal.org/node/7765). At the least, following these good practices will reduce your future maintenance chores to the bare minimum, because a well-architected module that plays nicely with the current version of Drupal core will be more likely to play nicely with an updated version. And if Drupal core is updated, the migration path to new functionality equivalent to the superseded functionality is generally documented, making the module developer’s job easier.
www.neal-schuman.com
28
Drupal in Libraries
ASSESS STAFFING NEEDS
In addition to the staff, whether internal or outsourced, who will be doing the programming and design work, your Drupal site will likely involve a large portion of your library’s staff on the content side. While you can realistically outsource graphic and application design, you and your library staff will take responsibility for your content. It is the whole point of the site after all.
During Development
You are presumably replacing your current website, which may or may not be in a content management system, with a Drupal-powered one. The first step is to perform a content review so that you can separate content that needs to be moved to the new system from content that is no longer needed. There are several approaches to such an inventory. If your site is built of plain old HTML files, you can start from the file system’s directory to list out all of the nested files and folders. If your site is already in a content management system of some kind, it almost certainly has a site map or export tool that can list all of your site’s content. See “Recommended Reading” for resources on conducting a site inventory. The people who are responsible for the content should likewise be responsible for reviewing it and migrating it into the new system when the time comes.
Reviewing without Responsibility
When the University of Michigan Library migrated from flat files into Drupal, we asked the dozens of people systemwide to review their content for migration, with the understanding that any content they selected would be moved for them. We hired students to copy and paste from the webpages selected by staff into Drupal. Because there was no penalty for moving lots of content, many staff were lenient when it came to the content review and opted to keep everything. This resulted in our students moving a significant amount of outdated, redundant, or just plain not useful content into Drupal initially. When the project management group reviewed the often lengthy lists of content to be migrated and communicated more directly with the content owners, the second pass resulted in a much shorter list of content to migrate. As a related note, migrating the content centrally may be politically expedient, but giving the content owners a role in this process helps it go more smoothly and allows last-minute content decisions to happen in the flow.
As you review your content, there are several categories of content you may wish to consider leaving behind: Outdated information—pages describing services, events, tools, and so forth that are no longer offered by your library but that are still on
www.neal-schuman.com
Planning
29
your current site (even if those pages are “orphans,” no longer linked from anywhere). Orphaned pages—if it’s not linked to anywhere on your site, is it really useful? Duplicate content—for example, if you have the same information on library hours in multiple places, it is more difficult for your staff to keep the site accurate, and it is more confusing for the user. There is probably a great deal of similar content that could, and should, be consolidated.
After Launch
Once your Drupal site is launched, the big content push is over and you move into maintenance mode. You may not need to have all hands involved in content management, but it makes sense to establish a few roles for staff on the website. If you have a large organization, it may be useful to have people taking care of these roles in each unit. The simple hierarchy described here will likely work well for many organizations, but tailor the roles and responsibilities to meet your library’s particular needs: Content Author—the person who is authorized to write and edit content (whether at the unit or library level, depending on the size and style of your organization) Content Editor—the person who reviews new content, approves edits, and deletes unneeded pages from the site Site Administrator—the person who has the ability to manage Drupal itself, such as adding modules and updating themes (often several individuals have this role so that changes can be made without waiting for the admin to get back from vacation or illness) In some organizations, content authors are authorized to publish directly to the live site. In others, there is a review and editing stage. It generally makes sense to delegate the content questions to library staff who know most about the topic and not have this function in the systems office. Systems personnel understand the application but may not be best positioned to review content for accuracy or library style.
CREATE SITE DESIGN
Drupal keeps the look and feel of your site separate from functionality and content. As you think about what you say and how users interact with your site (the content and functionality), you should also be working on the design of the site. You may have an existing site whose design works well for
www.neal-schuman.com
30
Drupal in Libraries
you, even if the content is hard to manage. Or you may view moving to a content management system as an opportune time to revamp the interface as well. Here are some points you should consider as you plan your design. Does your current site’s design represent the image your library wants to portray? If your library is on the cutting edge of technology and services, do you want your site to be “edgy” as well? If your clientele’s needs are better met by a simple, functional design, then that is the way to go. Is your current site accessible to those with vision or other impairments? If you have not recently reviewed your site for compliance with web accessibility guidelines, a redesign is a terrific time to do so. (Handy resources for this are listed in “Recommended Reading.”)
Accessibility Is Part of Design
You should build accessibility reviews into your site’s development plan so that your website is fully accessible to those who use screen readers or other assistive technology. Validating against these tools early and often will make accessibility an easy outcome. While there is no single standard for defining an accessible site, two sets of guidelines are commonly followed (and may be required by state law or local policy). The first is required for U.S. Government agencies (and has been adopted by many state and local governments and other organizations) and is known as “Section 508” (see http://www.section508.gov/). The second, the Web Content Accessibility Guidelines [WCAG], is managed by the World Wide Web Consortium (see http://www.w3.org/WAI/intro/wcag). Developing your site with accessibility in mind generally leads to improved use for all users regardless of level of physical or cognitive disability.
What do your users (and your staff) think of your current design? If you are not sure, ask them. This can be done through a simple online survey. Another method is to provide images of a typical page in your current system or the new system as you design it, and ask patrons to simply circle design elements they like, cross out elements they do not like, and add anything that might be missing. You will receive a wealth of information about your users’ perceptions of your design in short order and can begin identifying parts of the design that work well and those that do not. Once you have this basic information about the site’s design needs you can start working on a theme. Themes are the way Drupal separates the “look and feel” of the site from the functionality of the site. They are written largely in HTML and CSS, although some PHP is needed to import the content for a particular page type display. As with modules, there are hundreds of
www.neal-schuman.com
Planning
31
community-contributed themes to start from, so, if you don’t see one you like, you can build your own from scratch or modify an existing theme that has most of what you need.
DEVELOP FUNCTIONALITY
This is where the rubber meets the road. What do you want users to do when they are on your Drupal site? They might want to search the catalog, reserve a meeting room, renew a book, get reference help, connect to a database, enroll in a class or workshop, or perform any number of other tasks. Figuring out the functions you want should be based significantly on the goals you are setting out to achieve. As in other stages of planning, perform a needs assessment to explore what your patrons would like to do if they could and what they use on your current site and listen to feedback (either actively solicited for this purpose or already submitted through other channels). Some goals may be met by a single function; others may require multiple functions or features to achieve. As you develop the list of functions, you can begin to compare them with both your goals and the pool of community modules. You will thus build a model of what you need and how you will achieve it and begin calculating the time needed to do any custom work. This exploration could be done through a simple table with a few columns: Function—What would this function do, who will use it, and how often will it be used? Goals Met—Of the goals you established, which ones does this function enable? Priority—How important is this function to the overall function of the site? Is this a must-have item, a nice-to-have item, or a bonus if you achieve it? Community Modules—Are there community modules that (in whole or in part) achieve this goal? Scope of Work—How much will it take to make the community module behave the way you would like or to develop your own module from scratch? At this early stage of your exploration, you may want to characterize this broadly as a small, moderate, or significant effort and then refine these estimates to actual development time as you learn more. Now comes the hard part—making decisions about priorities based on the information you have gathered. Having some consistency in the inputs will make these decisions understandable and communicable to other staff and to
www.neal-schuman.com
32
Drupal in Libraries
whatever constituencies are following the web redesign effort. As we’ll explore in the following chapter, keeping these constituencies informed about what is going on, and having consistent and open rationales for decisions, will go a long way toward smoothing the inevitable disagreements among them.
www.neal-schuman.com
INDEX
Page numbers followed by the letter “f” indicate figures; those followed by the letter “t” indicate tables.
A
Accessibility, 10, 30, 43, 102, 115–117 Acquia Drupal, 44 Activating, 50–52, 51f “AddtoAny,” 81 Administrative interface, 44, 45 organic groups, 8, 70–72, 71f reports and, 84–87, 85f, 86f, 87f Adobe Photoshop, 23 AJAX-based, 44–45 Akismet, 78 Alfresco, 6t Alpha testing, 104 Amazon.com, 16–17, 49 Analog, 110 Analytics, 107–111 click path analysis, 110–111 web server log files, 108–109 Ann Arbor (MI) District Library, 115–116 AntiSpam, 78 Apache, 40–41 API. See Application programming interface (API) Apple.com, 109 Application programming interface (API), 116–117 CRUD, 117 Drupal’s API, 87–89, 116–117 Architecture Drupal, 27, 100 information, 35–36
programming, 73 website, 82 Article discovery, 75, 115–116 Askey, Dale, 89 Audio, 113 Authoring group, 36 Available updates report, 101–102, 102f AWStats, 107
B
Backup, 48 hardware, 13–14, 16 safe computing,101–103 Bartik theme administrative interface, 45 colors, 50–52, 51f, 72 default for public view, 25 editing, 72, 74 example, 26f files, regions and blocks, 47t, 53f navigation, 53, 53f structure of, 73–74 Bartik.info, 73 Bartik-test, 74 Berra, Yogi, 4 Best practices content management, 103–104 Drupal way, 100–102, 102f launching site, 104–105 planning, 47t, 74, 99–100 safe computing, 102–103
www.neal-schuman.com
123
124
Drupal in Libraries
Code4lib Journal, 89 Color, activating, 50–52, 51f, 72 Communication, 34–37 Community, giving back to, 26–27, 26f, 89 Configuring library website, 55–61, 57f, 58f, 59f panels and, 65–67, 66f, 67f views and, 61–65, 62f, 63f Content categories, 82–83 creation, 56–59, 57f, 58f, 59f, 60–61, 92–93 creation interface, 45–47, 47t defined, 7 editor, 29 links, 3, 7, 57, 93, 94f, 96f, 97 management, 103–104 themes, 9–10 Content Creation Kit (CCK) constructing, 56–59, 57f, 58f, 59f, 60–61 panels, 65–67, 66f, 67f, 68f SOPAC and, 116 view and, 61–65, 62f, 63f Content management system (CMS) advisory groups, 35–36 buy-in, 35 change management, 34–35 efficiencies, 2–3 feature and functionality matrix, 6t vs. flat file, 1–3 open source vs. closed, 4 selecting, 4–5, 6t Cookies, 111 “Creating Drupal 7.x modules,” 88 Cron jobs, 44, 47t, 55 CRUD, 117 CSS. See Cascading Style Sheets (CSS) cURL, 50 Customize, 9–10, 14t, 24, 44, 73, 100–101 CSS and, 25 e-mail and, 69 functionality, 10 installation and, 48 modules and, 27, 55, 88t theme, 27, 74–75
Beta testing, 104 Bing, 47, 47f, 108 Black box system, 4 Blocks, 10, 45, 53–54, 53f module creation, 87–89 navigation, 53 panels and, 65, 67 tagging and, 78–80,79f, 80f themes and, 52 views and, 61, 65 Blogs, 2, 96 activating, 50–52, 51f RSS feed, 46, 81–82 software, 15 Blyberg, Jon, 115–116 Book page nodes, 45–46 Broken links, 93, 94f Browsers, 5, 50–51, 69, 73, 96, 111 analytics and, 108–109 Buytaert, Dries, 117
C
Calendars, 8 CAPTCHA, 78 Cascading Style Sheets (CSS), 2–3, 10, 30, 73, 92–93 customization, 25 defaults, 64 forthcoming updates, 117 ID fields, 65–66 module components, 88t panels and, 65–66 theme structure and, 73 Catalog (OPAC), 116 access, 75 integrating, 13, 39, 115 modules, 49 searching, 23, 31 serials and, 116 Cell phone, QR codes, 96, 97f Click path analysis, 110–111 Closed (proprietary) system, 4, 77 Cloud computing, 16–17, 117 Amazon Web Services, 16 CMS. See Content management system (CMS) Code sharing, 103 “Coder” module, 88
www.neal-schuman.com
Index
125
D
Daisy, 6t Darien (CT) Public Library, 115–116 Dashboard, 4, 50–52, 51f Databases activating, 50–52, 51f application, 40–42 backup, 101–103 connecting to, 31 CMSs and, 2 creation, 42, 43f Drupal, 74–76 entry, 8, 27 files, 48, 60 finder, 23 IP address and, 110 migration, 83–84 MyPHPAdmin, 42, 43 structure, 103 tables and, 7–8 Delicious, 81 Development community, 6t CMS and, 6t environment, 101 hosting options, 14t website, 17–20 Digg, 81 Digital Information Services Librarian, 36 Director of Communications, 36 Drupal activating, 50–52, 51f administrative interface, 59f, 65 architecture, 27, 35–36, 100 backup, 101–103 blocks, 10, 45, 53–54, 53f “Coder” module, 88 community giveback, 89 concepts, 2, 7–11, 23–25 configuring, 55–59, 57f, 58f, 59f, 60–65, 62f, 63f Content Creation Kit (CCK), 56–59, 57f, 58f, 59f, 60–61, 92–93, 116 content management, 4–5, 7–8, 10–11 customized, 9–10 database, 42, 43f, 74–75 defined, 5–6 development, 14t, 17–20, 24, 101
feature and function matrix, 6t file system and, 1–3, 47–49, 47f filter, 63–64, 78, 85–87 functions, 8, 31–32 Groups website, 7 installation, 8, 41–45, 41f, 52–54 integrating library resources, 74–76 library developer community and, 6–7 maintenance, 29 operating system creation, 40–41 outsourcing, 13, 14t, 18–19, 28–31 reports and, 45, 55f, 84–87, 85f, 86f, 87f script installation, 43 security, 34, 43–44, 77–78, 117 selecting, 4–5, 6t site design, 9–10, 29–31 SOPAC and CCK, 116 tagging, 78–80, 79f, 80f tools, 6t trends, 115–117 tutorials, 88 versions, 12, 115–117 vocabulary, 7, 17, 49 web root, 47–49, 47t See also Installation; Modules; Themes Drupal API, 87–89, 116–117 Drupal 5 migration, 12, 83–84 out-of-the-box, 25–26, 25f, 45 Drupal 6 Acquia, 44 administrative interface, 44 Content Creation Kit (CCK), 56 installation, 40–42 modules, 12, 48 Drupal 7 Content Creation Kit (CCK), 56 files, where to find them, 47t installation, 40–45 integrating library resources, 74–76 modules, 12, 48–49, 115 regions and blocks in Bartik theme, 53f reports, 25 themes, 72–73 trends, 115–117 tutorials, 88 Drupal 8, 116–117 Drupal 9, 116–117
www.neal-schuman.com
126
Drupal in Libraries
outsourcing, 18, 28 QR codes, 96, 97f Guides, 75–76
DrupalCon, 116–117 Drupalib, 7 Drupal.org, 41, 44, 46, 49–50, 82, 88, 89
E
E-mail form, 69 Etches, Amanda, 24 Evaluation. See Measuring achievement Event calendar, 23 EZproxy, 7
H
Hardware collaboration, 33 hosting and developing options, 13, 14t, 17–20 maintaining, 111 options, 14–16, 40 protection, 48 Harlan Hatcher Graduate Library, 3f Harvard University, 34 Headers, 65 Heterogeneous site, example of, 3f Homepage, 2, 3f Hosting cloud, 16–17 commercial, 40 developer, 17–21, 101 hardware, 13, 14t, 17–20 options, 14t, 13–17 server, 15–16 web server log files, 109–110, 109f HTML accessing data, 75 content management and, 1–3, 28, 30, 82 creating a document, 61 Drupal and, 10, 84, 92–93, 101, 117 file system, 47t filter, 61 modules and, 88 web server log files, 108–109
F
Facebook, 76, 81, 96, 115 Faculty Advisory Group, 35 FAQ interface, 9 Fast Company (magazine), 34 FCKeditor, 8 Feature and Functionality Matrix for Selecting a CMS, 6t FedEx, 34 Feedback, 31 social media and, 76–80, 77f, 79f, 80f Webform module, 67–69, 68f, 69f Feeds, 76, 83 Fields, 7–8, 56–61, 64–65, 69, 79–80, 87 activating, 50–52, 51f File system, 41–45, 47–49, 47f Filter, 63–64, 78, 85–87 Firefox, 5 Flash Player, 110 Flat file system, 1–3, 28 Flickr, 67, 115 Focus groups, 36 Footer, 53, 65 Functionality, 31–32
I
Icons, 66, 73–74 Images, 7, 11 adding, 42 backing up, 103 file system, 47t libraries, 30 themes and, 73–74 Implementation. See Installation; Methods and practices Information Architecture Advisory Group, 35 Inline, 80
G
Garland theme, 25, 25f, 47t Git, 48 Global Comment Settings Window, 71f Google, 47f, 82, 108–109 Google Analytics, 23, 49, 107, 110–111 Googlebot, 109 Graphics Drupal and, 65 file system and, 47f identity and, 2–3, 3f, 18, 22
www.neal-schuman.com
Index
Installation administrator interface, 44–45 configuring website, 55–61, 57f, 58f, 59f panels and, 65–67, 66f, 67f views and, 61–65, 62f, 63f content creating, 42–43, 43f, 45–46 files, 41–45, 41f, 47–49, 47f hardware, 39–41 modules, 49–52, 51f, 87–89, 88t operating environment, 40–41 panels, 65–67, 66f, 67f script, 43 security, 34, 43–44, 77–78, 117 setup, 42–44 themes, 52–54, 53f updates, 54–55, 55f web root, 47–49, 47t website download, 41 Institutional Review Board (IRB), 112 Interactive design, 23–24 site, 9–10, 29–31 tagging, 78–80, 79f, 80f Interface administrative, 57–62, 66, 57f, 58f, 59f, 62f, 63f, 66f content management systems and, 3–4 Drupal and, 11–12, 14t, 26, 40, 103 installing, 42, 44–47, 47t, 48–49 LibGuides, 75 modules and, 116–117 organic groups, 72 staff and, 93–94, 94f themes, 52–56, 55f URL and, 49–52 Webform page, 68f website and, 7, 9, 97, 101, 107 Internal developer, 19–20 Internet Explorer, 73 Internet provider, 15 IP address, 69 spam and, 78 web log files, 109f, 110 IT department, 33–34, 44
127
L
J
JavaScript, 47, 108 Joomla!, 6t
LAMP, 40, 48 Launch, 36–37 marketing, 91–92, 94–98 testing, 104–105 Layout, page, 2 Legacy application, 2 LibGuides, 75–76 Library administration, 15, 35, 112 categories, 82–83 contact, 3, 7, 23, 93, 94f, 96f, 97, 115 content creation, 56–59, 57f, 58f, 59f, 60–61 content creation management, 103–104 developer community and, 6–7, 101 interactive design needs, 23–24, 30 IT department, 33–34, 44 LibGuides, 75–76 migration, 83–84 newsletter, 23 patron accounts, 23 site, 9–10, 29–31 staff, 34, 92–95, 94f web team, 36 Library branch, 56–61, 70, 86 panels and, 65–67 social media and, 76, 79 theme customization, 74 views and, 61–65, 63f LinkedIn, 81 Links, 2–3, 7, 97 adding, 64 administrative, 45–46 broken, 27, 29, 93, 94f database and, 83–84 downloading, 44 log-in, 56 module and, 52, 54 panels and, 10 resources and, 23, 56–57, 61, 76, 87 social media and, 76, 78, 81 Linux, 40, 42, 44, 48 Localhost, 109 Log analysis, 107, 109–110 Logo, 3, 10, 22, 53, 53f, 56 logo.png, 73
www.neal-schuman.com
128
Drupal in Libraries
installation, 40–43, 41f integrating resources into, 83–84 LibGuides, 75–76 organic groups, 8, 70–72, 71f page layout, 2 panels, 65–67, 66f, 67f reports and, 45, 55f, 84–87, 85f, 86f, 87f RSS feeds, 81–82 search engine optimization (SEO), 82 security, 34, 43–44, 77–78, 117 setup, 43–44 social media enabling, 76–78, 77f sharing, 80–81, 81f tagging, 78–80, 79f, 80f style, 72–73 theme installation, 9–10, 52–54, 53f, 73 theme installation, customization of, 74–75 up-to-date, 54–55, 55f, 84–87, 85f, 86f, 87f See also Installation; Modules Metrics. See Measuring achievement Microsoft Word, 93 Migration, 83–84 Mobile, 117 Modules activating, 50–52, 51f, 77 blocks, 87–89 community, 26–27, 26f, 31, 89 creation, 87–89, 88t customized, 27, 55–56, 88t environment, 101–103 file system, 47–49, 47f functions, 2, 6t, 7–8, 10–12, 11f, 31, 75 installation, 40, 49–52, 51f, 75, 77–81 interface, 116–117 options, 4, 24–27, 42, 45–46, 83 organic groups, 8, 70–72, 71f out-of-the-box, 24–27, 25f panels, 10–11, 27, 65–67, 66f, 67f, 80 reports, 54–55, 55f, 88–89, 111 up-to-date, 53–55, 55f, 102f, 115–117 views, 11, 11f, 40, 52, 61–66, 62f, 63f, 66f integrating, 75–76 updating, 84–87, 116–117 web root, 47–49, 47t See also Themes MODx, 6t
M
Macintosh, 109 Maintenance, 29 Malicious software, 50 See also Security Marketing change and, 34–35, 91–92, 94, 96, 98 external, 91–92 integrating library resources, 74–76 interface, easy, 93 links and, 93, 94f, 96f, 97 plan, 97–98 public, 95–97 QR codes, 96, 97f search engine optimization (SEO), 82 social media, 95–97 staff, 91–95, 94f Measuring achievement analytics, 107–111 AWStats, 107 click path analysis, 110–111 Google Analytics, 107–108 log files, 108–110, 109f observation, 112–113 questions, 108 selecting a CMS, 6t server log analysis, 109–110 surveys, 111–112 testing, 113 user feedback, 31, 67–69, 68f, 69f, 108–109 social media and, 76–80, 77f tagging, 79–80, 79f, 80f web analytics, 108–111, 109f web log files, 108–110, 109f Methods and practices administrator interface, 44–45 Amazon.com, 79 community giveback, 89 configuring, 55–59, 57f, 58f, 59f, 60–65, 62f, 63f content, 45–46, 70, 82–84 creating operating environment, 40–41, 43f database migration, 83–84 feedback, 67–69, 68f, 69f file system, 47–49, 47f HTML, 45, 53, 67, 70, 72, 74, 80, 84
www.neal-schuman.com
Index
Mollom, 78 MyPHPAdmin, 42, 43f MySQL, 17–19, 40–42 Acquia Drupal, 44 Pathauto, 8 Perl, 2 PHP content management and, 2 customization, 74, 84 design and, 30, 88 development and, 19, 100 Drupal and, 10, 17 file system and, 47f operating environment, 40–43 style and structure with, 73 Planning. See Project management Plone, 6t PostgreSQL, 41 Press release, 95 Priority, 31 Product availability, 6t Profiles, 47t Programming, 19, 73, 76 API, 116 staff, 14t, 17, 22, 28 Project management change and, 34–35 communication, 34–37 content, 21–24, 28–29 development, 21–22, 101 functionality, 23–24, 31–32 goals, 23–24 interactive, 23–24 inventory resources, 22–23 IT department, 33–34, 44 modules, 26–27 needs assessment, 31–32 out-of-the-box, 25–26, 25f, 45 planning, 21–22 redesign, 30, 32 scope of, 24–25 site design, 29–31 staffing needs, 28–29 stakeholders, 21, 35 transition, 34 usability assessment, 22–23 web team, 36 See also Best practices; Marketing Public relations. See Marketing
129
N
Navigation content, 2–3, 8, 10, 45, 53, 70, 72, 80, 83 interface, 74 menu, 26–27, 26f, 67 panels, 65 Node, 11, 60–62, 86–87, 93 book page nodes, 46 defined, 8 panel and, 65, 68 social media and, 76–77, 81, 84 themes and, 72–74 views and, 64
O
Observation, 112–113 Online journal finder, 23 OPAC. See Catalog (OPAC) Open source systems black box system, 4 vs. closed systems, 4–5 Drupal and, 5–6, 6t, 8, 40–41, 54, 89 pros and cons, 1–3, 33–34 OpenURL resolver, 7 Operating systems, 17, 40 closed (proprietary), 4, 77 environment, 40–41, 55 open source, 2–6, 5–6, 6t, 8, 33–34, 40–41, 54 Organic groups, 8, 70–72, 71f Orphaned pages, 28 Outdated information, 28–29 Out-of-the-box modules, 25–26, 25f, 45 Outsourcing, 13, 14t developers, 18–19 staffing, 28–31 Overlays, 22
P
Palos Verdes (CA) Library District, 115 Panels. See Modules
Q
QR codes, 96, 97f
www.neal-schuman.com
130
Drupal in Libraries
Social mechanics buy-in, 35 change management, 34–35 colleagues, 34 committees, 35–36 communications, 33, 36 IT department, 33–34, 44 staff, 34–37 web team, 36 Social media commenting, 76–78 enabling, 76–78, 77f RSS feeds, 81–82 sharing, 80–81, 81f tagging, 78–80, 79f, 80f Social OPAC. See SOPAC “Social Share,” 81 Software development project, 13–15, 17–18 internal development, 19–20 malicious, 50 outsourcing, 18–19 See also Drupal; Hosting; Security Sony Music, 34 SOPAC, 75, 115–116 Spam, 78 Springshare, 75 SQLite, 41 Staff development and, 14f, 15, 17–19, 30, 34–36, 99 marketing to, 92–95, 94f needs, 8–9, 22, 28–29, 70, 72 Stark theme design, 25, 47t Statistics. See Measuring achievement Styling, 72–73 Subversion (SVN), 48 Summon article discovery integration, 115–116 Serials Solutions, 116 Sun Microsystems, 34 Support availability, 6t Surveys, 111–112
R
Regions and Blocks in Drupal 7’s Bartik Theme, 53f Release mechanism, 6t Reports, 45, 82, 96, 112 administrative interface, 93–94, 94f Available Updates report, 101–102, 102f modules and, 54–55, 55f, 88–89 views and, 61, 84–87, 85f, 86f, 87f web server log files, 109–110 Robots.txt, 47 Roles, organic groups and, 8, 70–72, 71f RSS feeds, 46, 65, 76, 81–84
S
Safari, 109 Safe computing, 101–103 Sandbox project, 89 Scalability, 6t Schmidt, Aaron, 24 Scope of project, 31 Screenshot.png, 73 Script installation, 43 Search engine optimization (SEO), 82 Search phrases, 93 Security Drupal and, 43–44 holes, 24 malicious software, 50 patches, 15, 117 risks and, 33–34 safeguards, 77–78, 101–102, 102f Serials solutions article discovery integration, 115–116 Summon, 116 Server choosing, 1, 13–16, 14t cloud, 16–17 log analysis, 109–110 Seven theme design, 25, 26f, 47t SilverStripe, 6t Site administrator, 29 design, 9–10, 29–31 Skin, 9 file system, 47t reskin, 26 See also Themes
T
Tagging, 78–80, 79f, 80f Taxonomy Manager, 8 Technology Advisory Group, 35
www.neal-schuman.com
Index
Template.php, 73 Templates, 2–4, 9–10, 54, 80, 110 creating, 27 template.php, 72 themes and, 73–74 Testing, 94, 96, 97, 101–102 Bartik-test, 74 changes, 54–55 development, 18, 48 Institutional Review Board (IRB), 112 launch, 104–105 user, 23, 113 Themes basic, 25–27, 25f, 26f customization, 27, 74–75 default, 9–10 description, 9–10 installation, 52–54, 53f structure, 73–74 style and, 73 up-to-date, 54–55, 55f web root, 47–49, 47t Timeline, 97, 99 Trends, future API, 116 article discovery integration, 115–116 forthcoming, 116–117 modules, forthcoming, 115–116 Serials Solutions, 116 Social OPAC, 115–116 Tutorials, 88 Twitter, 49, 81, 96 TypePad, 78 TYPO3, 6t
131
Unix, 17, 40, 42, 48 Updates, 54–55 Available Updates report, 101–102, 102f installation, 49–50 OpenURL resolver, 7–8 reports and, 45, 55f, 84–87, 85f, 86f, 87f URL, 87, 97 User Experience (UX) Design for Libraries (Schmidt and Etches), 24 Users ID, 108 marketing plan, 97–98 needs, 31–32 organic groups, 8, 70–72, 71f roles, 9 testing, 113
V
Video, 75, 113 Views. See Modules
W
WAMP, 40, 48 Web Content Manager, 36 Web log files, 108–110, 109f Web root, 47–49, 47t Web Systems Manager, 36 Webform module, 67–69, 68f, 69f WebGU, 6t Website accessibility, 10, 30, 43, 102, 115–117 categories, 82–83 configuring, 55–61, 57f, 58f, 59f panels and, 65–67, 66f, 67f views and, 61–65, 62f, 63f content creation, 56–59, 57f, 58f, 59f, 60–61 content creation management, 2, 103–104 customize, 9–10, 14t, 24, 44, 73, 100–101 CSS and, 25 e-mail and, 69 installation and, 48 modules and, 27, 55, 88t theme, 27, 74–75 design, 9–10, 29–31 development, 14t, 17–20, 101 FAQ interface, 9
U
Universally unique identifiers (UUIDs), 117 University of Michigan Library categories, 82–83 committees and, 35–36 Harlan Hatcher Graduate Library, 3f homepage, 3f needs, 28 report, 94f Serials Solutions, Summon, 116 website, 2, 23, 28 XML and, 75–76
www.neal-schuman.com
132
Drupal in Libraries
“We Love Open Source Software. No, You Can’t Have Our Code” (Askey), 89 Wget, 50 White House website, 34 Wiki, 15 Windows, 17, 40, 42, 44, 48 WordPress Import, 45, 76, 83
Website (cont’d.) feedback, 31, 67–69, 68f, 69f social media and, 76–80, 77f tagging, 79–80, 79f, 80f filters, 63–64, 78, 85–87 functionality, 31–32 goals, 23–25 identity and, 2–3, 3f, 18, 22 interactive design, 23–24 LibGuides, 75–76 QR codes, 96, 97f updating, 84–87, 85f, 86f, 87f, 117 user, 31–32, 108 web server log files, 108–109 See also Drupal; Hosting; Measuring achievement
X
XML, 75–76
Y
YouTube, 75
Z
Zen theme, 10, 26f
www.neal-schuman.com
“
This is the series to acquire and share in any institution over the next year. I think of it as a cost-effective way to attend the equivalent of ten excellent technology management courses led by a dream faculty! TECH SET® #11–20 will help librarians stay relevant, thrive, and survive. It is a must-read for all library leaders and planners. — Stephen Abram, MLS, Vice President, Strategic Relations and Markets, Cengage Learning
”
Drupal in Libraries is part of THE TECH SET® VOLUMES 11–20, a series of concise guides edited by Ellyssa Kroski and offering practical instruction from the field’s hottest tech gurus. Each title in the series is a one-stop passport to an emerging technology. If you’re ready to start creating, collaborating, connecting, and communicating through cutting-edge tools and techniques, you’ll want to get primed by all the books in THE TECH SET®. New tech skills for you spell new services for your patrons: • Learn the latest, cutting-edge technologies. • Plan new library services for these popular applications. • Navigate the social mechanics involved with gaining buy-in for these forward-thinking initiatives. • Utilize the social marketing techniques used by info pros. • Assess the benefits of these new technologies to maintain your success. • Follow best practices already established by innovators and libraries using these technologies. Find out more about each topic in THE TECH SET® VOLUMES 11–20 and preview the Tables of Contents online at www.alatechsource.org/techset/. 11. Cloud Computing for Libraries, by Marshall Breeding 12. Building Mobile Library Applications, by Jason A. Clark 13. Location-Aware Services and QR Codes for Libraries, by Joe Murphy 14. Drupal in Libraries, by Kenneth J. Varnum 15. Strategic Planning for Social Media in Libraries, by Sarah K. Steiner 16. Next-Gen Library Redesign, by Michael Lascarides 17. Screencasting for Libraries, by Greg R. Notess 18. User Experience (UX) Design for Libraries, by Aaron Schmidt and Amanda Etches 19. IM and SMS Reference Services for Libraries, by Amanda Bielskas and Kathleen M. Dreyer 20. Semantic Web Technologies and Social Searching for Librarians, by Robin M. Fay and Michael P. Sauers
Each multimedia title features a book, a companion website, and a podcast to fully cover the topic and then keep you up-to-date.
American Library Association 50 E. Huron Street Chicago, IL 60611 1 (866) SHOPALA (866) 746-7252 www.neal-schuman.com
