I am frequently asked about the Rutgers environment for creating scholarly websites. I am always happy to come to classes to guide people through this terrain, but in the interest of serving the broader Rutgers DH community, I am sharing these slightly opinionated thoughts about web publishing here. I mostly presume a Rutgers audience, although I do include some external recommendations that would be good for anybody looking to publish their scholarship to the web. This post borrows from Andrew Goldstone’s “Notes on Using Digital Media for First-Year Graduate Students,” which goes into further detail on DH and on being an academic on the web.

For a variety of reasons, mostly having to do with maintenance costs, the landscape for web publishing at Rutgers is not exactly hospitable. As somebody who is responsible for maintaining several digital projects, I get the maintenance problem viscerally.1 These days, I tend to avoid content management systems (CMSs) like WordPress that require constant security patches and updates. Off-the-shelf tools like these are appealing—at least at first—because they are easier to learn, but over the long run the costs add up. There are the aforementioned security and software updates, which are frequent and must be kept up with. Using an institutional WordPress installation means that quite a lot of control is lost upfront (e.g. functionality is disabled, there is little to no control over style or design, or worse—servers get decommissioned and then not replaced). Lastly but significantly, the dashboards of these tools obscure the fundamentals of the web, meaning the user learns very little about computational systems and standards and the modes of production they enable.2 I put that ignorance in the cost column because the user will become dependent on technology partners whose investment in the work may not be what the user hopes or expects. With all that said, CMSs do have their appropriate uses. All of the options I list below have tradeoffs. I try to be transparent about those so that the reader can select the best option given their resources, time, level of technical skill, and expected outcomes.

Making a website

The Content Management Systems

They are everywhere, and we may as well start here. Rutgers uses Drupal for departmental websites, except for SAS which uses Joomla! (don’t ask). OIT’s Sites@Rutgers project is a WordPress Multisite installation. And the Libraries, under very select circumstances, will approve installations of WordPress and Omeka.3 WordPress, Omeka, and Drupal are all open source software solutions with slightly different strengths. They can be good for pedagogical or research projects. Since they all rely on LAMP stack technology, they need constant tending.4 Expect maintenance issues. On the plus side, group authorship tends to be much easier here than with static sites.

WordPress is the quintessential blogging platform, which is to say it has post functionality in which your posts will appear in reverse chronological order. But it can be used to create a non-blog site (structure your content with pages instead). The dashboard is fairly straightforward and easy to learn. WordPress is customizable—depending on your host—with themes (style) and plugins (functionality). It is probably the easiest to learn of the options presented here and offers the shortest pathway to a professional looking site. Group-authorship is easily managed with user roles.

Omeka Classic is explicitly designed for the GLAM (galleries, libraries, archives, museums) community for the creation of digital collections and exhibits. There’s yet another dashboard tool that is similar in feel to WordPress’s, however the metadata entry interface for describing media is fairly robust and distinctive. Omeka will be a better choice for projects a user expects to build over multiple semesters, as newcomers may find the descriptive metadata and Exhibit Builder plugin require careful planning and time to use effectively. Group authorship is managed via the admin dashboard.

Drupal tends to be preferred for digital humanities projects requiring custom databases, which is to say more-than-basic data entry or data presentation projects that support searching, browsing, and sorting operations. I will admit that I am almost no help at all when it comes to Drupal and consequently will refer users to Quinn Dombrowski’s Drupal for Humanists (available through the Libraries at https://bit.ly/3WecupH). The software’s strength, according to Quinn, is it’s flexibility. That is also its downside; expect to spend more time getting up and running with Drupal than with WordPress. Drupal’s dashboard and user roles will behave much as any other CMS’s.

Speaking of things I don’t know much about, there’s also Scalar, PubPub, and relative newcomer Manifold, all open source projects that got started in the academic community. Depending on your project, one of these may make sense.

There are other tools out there, like Wix and Squarespace. They usually combine site building software with hosting. They tend to be much more commercial in focus and are not widely used in the DH community. No judgement if you like them!5

Static sites

In the past ten years or so, many digital humanists have returned to the lightweight standards of the 1990s, albeit through the intermediary of static site generators (SSGs) like Jekyll, Hugo, Gatsby, Eleventy, and others. None of that Linux, Apache, MySQL, PHP stuff here.6 Sites made with these tools are comprised of just HTML, CSS, and JavaScript. They therefore present none of the security risks of the CMSs, making long term maintenance and preservation much easier and cost effective, but they do frontload a lot of labor onto the site developer. For starters, the dashboards and WYSIWYG editors are gone. Sites built using these tools require authoring content in Markdown syntax, using the command line, and occasionally using git and GitHub Pages for version control and publishing. Don’t be alarmed, though. It is usually the same commands that get used over and over again, which can be summarized in a cheat sheet. Group authorship is tricky because it means either that everyone on the project team needs to be familiar with these tools or that the one proficient person ends up with all web development tasks.

SSGs represent the deeper end of the web development pool and they are recommended only for those with the willingness and patience to learn the technical tools. Once the user has a grasp of these, however, the rewards are much greater freedom and flexibility in online publishing.

If you think this all sounds horribly nostalgic, I include some examples of static sites below so that you can see them in action.

(mmkay, so I have a bias towards Jekyll…)

Hosts and domains

Web development software (described above) and the files comprising your website need to be hosted on a web server somewhere in order to be accessible on the internet. A web hosting service provides the user with access to server(s) and domain name registration (i.e. a web address or URL). While all of the recommended web development software described above is free and open source, web hosting is never free. If you aren’t paying, then someone else is. I mention this because it can become a point of vulnerability over your project’s lifecycle.

Humanities Commons is a project of the Modern Language Association, but it is not required to be an MLA member to use it. They support individual website creation using a WordPress Multisite installation. Read about it at https://support.hcommons.org/guides/sites/creating-a-site-or-blog/. There are numerous but finite options for customization. Humanities Commons would be a good place to host a course website, a research project, or a personal portfolio.

If you are teaching at Rutgers, then Sites@Rutgers may be a good option. This is another WordPress Multisite installation. As of this writing, it is not possible to request the installation of themes (use of their custom Rutgers theme is required) or plugins. Some of the familiar functionality of WordPress, e.g. commenting, has been disabled across the platform. This is a common sense decision for overstretched system administrators looking to manage security vulnerabilities. Otherwise, OIT pledges to maintain this project for the foreseeable future, which is a plus for Rutgers users wanting a simple hosting solution.

If you need greater freedom and customization, then paying for a personal shared hosting plan may make the most sense. There will usually be separate yearly costs for both the domain registration and the hosting. A custom domain is possible (e.g. jackthescholar.org), as long as someone else hasn’t registered it. You can have any type of site (WordPress, Omeka, Drupal, static HTML, whatever!), but the support and ease-of-use for various types will vary. My personal recommendation is to use Reclaim Hosting, which is a longstanding favorite within DH and academic circles. I use them for my own web hosting. (Not an ad, just a happy customer.)

GitHub Pages can be used for static site hosting. With the caveat that Microsoft owns GitHub, GitHub Pages is free to use (for now). Your site’s URL will be in the form of [acccountname].github.io unless you register another domain separately. GitHub Pages is configured to work with the Jekyll static site generator, but you can use any SSG you like and just save the generated website files to your GitHub repository and hit publish.

Quite a lot of DH people I know use Netlify to host websites, often getting away with the $0 Starter package. You only pay for what you use here, and despite our wishes to the contrary, most academic websites just don’t generate a ton of traffic. Probably only recommended for more skilled web developers.

Other Less Appealing Options

  • “Free” wordpress.com. There will be ads.
  • I see a fair number of academics on Substack these days, but the idea of paying to read someone’s blog is repellant to me. It’s not required to make readers pay, but it’s the default option.
  • Tumblr: is that still a thing? Medium, eh… okay.

Things to keep in mind

It probably goes without saying, but in the context of academic writing online, it is good practice to get permission to reuse images, video, etc., and to cite sources. When working with students, I usually suggest the use of Google Advanced Image Search (https://www.google.com/advanced_image_search) or Creative Commons Search (https://ccsearch.creativecommons.org/) to find media licensed for reuse.

Accessibility

I never get into the weeds of web design, preferring to leave that to the experts. Most of the themes you would be tempted to use will do a decent job of making your website accessible to users with low vision or color blindness. But as needed, I recommend the use of a tool like WAVE (https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh) to evaluate the accessibility of your site.

Teaching yourself

There are lots of ways to learn more about using the features of the above-mentioned software, e.g.:

You can also feel free to give me a shout if I can help in any way!

  1. If you are tempted to rail against IT professionals and librarians who won’t maintain your digital project in perpetuity, may I point you to “Managing the Digital Backlist: Sustaining, Preserving, and Deleting Old Projects” by Jessica Otis for the reasons why this is a much bigger ask than you probably think?↩︎
  2. Read Alex Gil’s “Design for Diversity: The Case of Ed” for an eloquent argument for a return to 90s web (a.k.a. minimal computing).↩︎
  3. The condition to satisfy: there must be a substantive researcher-library collaboration, which is to say the site features Rutgers University Libraries sources and/or a productive knowledge exchange occurs between librarian(s), students, and/or academic faculty.↩︎
  4. Linux, Apache, MySQL, and PHP. Non-proprietary and open source, LAMP architecture is behind a lot of popular web applications like WordPress and Drupal. LAMP also exposes users to cyber attacks that add overhead to any project built with these tools. It’s the job of a system administrator to stay on top of these risks, but not every DH project has access to such a person.↩︎
  5. Erm… at least not too much judgment. You do what you have to do!↩︎
  6. LAMP stack applications have the capacity to generate pages dynamically. A good example would be Amazon.com search results. There’s so much stuff that it is not feasible or desirable to pre-generate pages matching every single search. In my experience, relatively few projects in the humanities are big enough to justify this functionality. Static site generators integrate basic search indexing using open source tools like lunr.js.↩︎