1.1 Overview

The cost of developing a scholarly project using Backdrop is significantly lower than building the same project from scratch. Instead of dedicating funding to a team of programmers who will have to spend some of their time implementing generic things like user logins and integration with geospatial services, in addition to the project-specific work, Backdrop provides you with the equivalent of hundreds of thousands of hours’ worth of “cost share” through the work of the international Backdrop developer community. The work necessary to customize Backdrop to your specific project can be undertaken by individual scholars at any level, even with very little prior technical experience.

This book walks through the steps involved in setting up a Backdrop site, using a single example site throughout. If you want to develop experience with Backdrop before starting on your own project, you can follow the instructions closely to create your own copy of the example site from start to finish. If you want to immediately begin with your own project, you can read through the general description and example site instructions, and undertake a similar but modified process to create your project site.

In practice, creating a Backdrop site is not a linear process; you will likely go back and forth between module installation, content type creation, importing or adding content, and creating displays for that content using Views. The ordering of the chapters provides a reasonable linear path through the site creation process, but the “Summary” section of each chapter includes pointers to other ways to traverse the content.

1.2 Audience and technical approach

This book is written for scholars at any level, from advanced undergraduate through professor emeritus, as well as librarians, museum professionals, and other individuals involved with humanistic research or public engagement. It assumes no technical experience beyond general computer and internet literacy, though some experience using (i.e. adding content to) other content management systems like WordPress or Omeka may be helpful.

The book also takes a “no-code” approach to Backdrop. All the functionality that you will use in creating your Backdrop-based site has already been written by a community of open source developers who build and maintain Backdrop core and modules, bundles of code that allow your site to do additional things. Using Backdrop, you can combine and configure existing modules in order to build robust websites that can include functionality like mapping (modules still under development – Jan 2019); timelines (modules still under development – Jan 2019); image galleries and slideshows; custom tables; and searching, browsing, and sorting data.

The no-code approach not only makes complex web development accessible to a wider range of users who have expertise in a content area but lack programming skills, it also can benefit your project from a sustainability perspective. Custom code is expensive to build and even more expensive to maintain-- a factor worth considering for projects that don’t have an ongoing funding stream after an initial grant. Using Backdrop without custom code, passionate scholars, librarians or museum professionals can make a collection accessible in a compelling, highly customized way, build and publish a directory of resources, or create a community hub around concepts or content, without first seeking grant funding. Because the developers of modules published on backdropcms.org also maintain those modules, site builders can apply these regular updates to ensure their site remains secure.

While you don’t need custom code to build a Backdrop site, there are opportunities to extend your site if you know CSS, JavaScript, and/or PHP. Because of the no-code emphasis of the book itself, pointers for how to make use of those languages are available on the Backdrop for Humanists website.

1.3 Why Backdrop?

Backdrop (and its predecessor, Drupal) has a somewhat steeper learning curve than any of the other content management systems that are commonly used for digital humanities projects. This is due to the extremely high level of customization that it provides, allowing users full control over the kinds of data and metadata that the site stores, the relationships between those kinds of content, and the ways the content is displayed. Most content management systems provide some kind of functionality out-of-the-box that allows users to immediately start adding content. Backdrop providing a WordPress-like level of functionality as soon as you install it – in contrast to Drupal, where, for each site, you have to set up numerous basic things, ranging from nice-looking URLs to URL fields to a module for querying your data. While WordPress has multiple plugins that provide their own framework for developing custom templates for your data and querying that data, Backdrop retains from Drupal a robust, built-in framework for building a data model and querying and displaying your data in a variety of ways. This is by design: Backdrop was developed for a websites that share similarities at the infrastructure level (e.g. inexpensive outsourced hosting, and a small tech staff that may not include programmers), but on the content level there are many differences. Backdrop core includes functionality that many or most sites need. More specialized functionality is made available through modules. Your choice of modules and how you configure them will transform Backdrop from a generic platform into an environment that is highly customized to your particular data and goals-- but without the cost or sustainability risks of custom programming.

Backdrop is not the right technical solution for every project. For building simple websites for publishing general information, updates, and outcomes from your project, WordPress is a better choice. There are also WordPress plugins developed for scholars that support robust text annotation, and developing scholarly networks and communities of practice. WordPress also has the benefit of having a large, international developer community that reaches beyond the academy. Omeka makes it easy to publish standard metadata about objects, and present those objects in curated “exhibits”. The Neatline plugin provides support for maps and related timelines.

For projects that are considering using FileMaker Pro or creating a custom database from scratch, Backdrop is often a better option. FileMaker Pro requires an expensive license, and while it is possible to produce a web-based display of a FileMaker Pro database, it is not very attractive or customizable. The situation is similar with other database software like Microsoft Access. Creating a custom MySQL database requires a higher degree of technical skill than using Backdrop, and it puts the project in the position of having to write custom code to produce a web-based display, which requires technical expertise and puts the project in a more precarious state from a sustainability perspective.

The relationship between Backdrop and TEI (Text Encoding Initiative) markup is more complex. If the project’s goal is to annotate the structure and/or content of a text, while treating it as a text, a traditional TEI workflow is usually a better choice. For a simple web presentation, there are ways to ingest TEI into Backdrop (still under development). In situations where text is being treated more like data (e.g. encoding historical financial records), Backdrop may provide a much more efficient workflow, and may also make it easier to present the data in interesting and insightful ways.

1.4 Backdrop’s strengths and weaknesses

1.4.1 Flexibility

Backdrop’s greatest strength lies in its flexibility. Because Backdrop allows users to create their own content types as well as how their content is displayed, it’s possible to create a wide range of vastly different kinds of projects, or work with very diverse data, all using the same basic Backdrop skill set and modules.

For users who are new to Backdrop and don’t know what they’re doing, it’s possible to create a site that’s an unusable mess in ways that simply aren’t possible with other content management systems. Following the steps laid out in this book should prevent most or all of these mistakes, but some things -- such as mastering the art of crafting good content types and complex displays -- only come with hands-on experience and practice.

Finally, Backdrop’s flexibility can also give users the “freedom” to avoid standards and misdirect their time and resources to creating ad hoc systems when existing vocabularies, metadata profiles, and other approaches would have been perfectly effective, and would have improved the project’s sustainability and interoperability. For that reason, it is important to research and assess the suitability of existing standards relevant to your project before embarking on defining your content types.

1.4.2 Developer community and module ecosystem

Backdrop split off from Drupal, which had one of the largest open source developer communities, when counting the number of individuals who have committed code to the project, as part of Backdrop core, or modules and themes. The underlying code that developed into Backdrop was well-vetted and time-tested over hundreds of thousands of websites and the eight years of Drupal 7’s existence. Backdrop continues to benefit from Drupal’s ongoing development, with developers applying Drupal 7 security patches to Backdrop where issues would impact Backdrop as well.

Backdrop itself has a small user base, relative to the team of committed developers. The Backdrop developers are passionate about developing this platform in ways that continue to push the boundaries of user experience and functionality for non-coders. The stated audience for Backdrop is businesses and non-profits, but they welcome adoption by any users who benefit from the approach they’ve taken. While some of the modules that are well-established in Drupal have not yet been released in a stable version for Backdrop (or ported at all yet), there is an opportunity for digital humanists, and digital humanities developers, to play a role in shaping a tool with significant potential value for humanities scholars.

The Backdrop developer community is one of the friendliest that you’re likely to find outside of projects that are explicitly developed by and for digital humanities. For the most part, they are very accustomed to talking with people who are not developers (which is less common than you might expect!). While a lot of discussion happens in a chat room connected to Github (the code repository where Backdrop code is stored, and where issues are filed; also increasingly adopted for publishing tools, code, and even texts in digital humanities), Backdrop also offers a user-friendly forum environment for asking questions, and developers do follow up to make sure forum posts get answered. In contrast to Drupal, the Backdrop developer community is much warmer and more responsive towards beginners, and the kinds of questions they inevitably ask.

1.4.3 Modest infrastructure requirements

While there is no free or super-low-cost hosted Backdrop service similar to what omeka.net offers for Omeka, Backdrop has modest infrastructure requirements and can easily be hosted on inexpensive shared hosting services, or on a server or virtual machine that you already run for other purposes.

1.4.4 Strengths and shortcomings of “no-code” Backdrop

Building a Backdrop site that uses no custom code can significantly reduce the extent to which you need to worry about maintaining the code base of your site. Unless a module has been abandoned, its developer (or their successor) will periodically issue module updates, which you can simply install on the site (see section 20.3). Sometimes one module update can cause a conflict with another module, but in many cases, these problems will be posted to the issue queue for one of the modules (see section 20.9.1), and other users will offer workarounds or patches to the code that resolve the issues. In contrast, any custom code that you develop for your project has to be maintained by your project, unless you release it for other projects to use, and those projects are willing to help with the maintenance if something breaks due to another module’s update.

As described in section 1.3.9, no-code Backdrop can generally get you to 80-90% of your ideal vision for the project, but you will likely have to make some small compromises in functionality, user interface, etc. if you don’t want to or can’t pay for theming or custom module development to close that gap.

1.5 About the example site

The example site that this book uses is inspired by CHAAMP (Consortium on the History of African Americans in the Medical Professions) Resources, built by SHANTI at the University of Virginia, and used with their generous permission. It uses many of the same types of content (profiles of individuals, events in their lives, and images related to the overall theme of the site.) While the example site does not include some of the pedagogy-oriented capabilities of the real It is significantly simplified from the real CHAAMP site, but it shares its topic and general organization.

1.6 Summary

This chapter has highlighted the strengths and weaknesses of Backdrop as a content management system, and briefly compared it to other open source systems and approaches. It has also introduced the example site, as well as the Backdrop for Humanists website, which can serve as a supplementary resource. Chapter 2 will describe Backdrop from a technical perspective and will provide an overview of the process of building a site with Backdrop.