Introduction

As scientists we often want to share our research results and insights to the wider community. This can be done by creating static visualisations such as graphs or infographics (see our tool recommendations for data visualisation) but oftentimes the results are too broad to fit neatly within one image, require interactivity from the user, or need to be updated frequently throughout the project. In such a scenario creating an online environment (website) can be a good solution.

If you plan to go this route, there are a couple of questions you should ask yourself before deciding on a tool and starting the project.

Things to Consider

Who are the target users of your website?
- Are your users domain experts or are you targeting the general public?
- What kind of setting do you expect your users to be in when interacting with your application (e.g., as a byte sized experience after clicking a link on social media, as part of a conference/supplementary material with a paper, to support policy makers, …)?
- What devices are people typically using in that setting (mobile, desktop)?
- Does your website only need to be accessible from within the VUB or to anyone?
- Do you need to limit access to the website (for example only logged in users)?
  - Is this for the whole site, or is more granular control needed for specific actions/collections/resources?
- How accessible does your content need to be for people with disabilities (see the Web Content Accessibility Guidelines)?
What is the goal of your website?
- Do you want users to be able to search for specific information?
- Do you want to entertain users?
- Do you want to convince users of something/tell a story about an analysis you already performed?
- Do you want users to perform analysis/data creation/annotation to gain new insights from your website?
What operational constraints do you face?
- Do you have a budget to pay for the hosting of your infrastructure?
- What infrastructure is provided by your university?
- How long does your website need to remain online?
- How often does the website need to be updated with new content?
- How many users are you expecting and what do you expect their usage pattern to be?
- What technical expertise do you have in-house to maintain and/or modify the platform?
- Who needs to be able to make content modifications to the website? Are end-users only consuming the data or also contributing (for example in Wikipedia)?

In the remainder of this page we will recommend some tools that we feel are worth exploring based on your answers to these questions. But before that we would like to remind you that if you are a VUB researcher, the VUB can assist you with compute and hosting infrastructure (which can be free in many cases). You should definitely check out the DICT Service Catalog. If you would are unsure how to answer the questions above, or would like to have a chat about your ideas/use cases you can also book a free meeting with us and we can help translate your ideas into concrete project needs.

Tools

One of the main questions you should ask yourself when creating a digital website is whether you need an actual server to serve a dynamic website or whether a static site suffices. Some of the advantages and disadvantages are listed here, but a more elaborate explanation can be found here. Another question you should ask yourself is whether you are hosting your data mainly for other people to browse directly, or whether you want to focus on making the data machine readable so developers and scientists can easily query and derive information from your data directly. In this last case publishing your data as linked open data might be a great fit.

Static Websites

Static sites are websites that serve pre-built pages stored on a simple web server. Static sites tend to be easier to create and maintain, and require less back-end programming knowledge than dynamic sites. They are fast, secure, flexible, and scalable for many digital humanities needs. Because of their lower demand for resources, they also leave a smaller carbon footprint than dynamic sites and are cheaper to maintain.

These advantages however also come at a cost. Since websites are no longer created dyamically on the fly, it is not really possible to personalise the website based on who is using the website (no login and only show my posts) and it is also not really possible for end users to create new data, comments, posts, … The user is mostly consuming the content rather than creating new content.

Note that this does not mean that the website cannot react interactively to actions taken by the user on the website. It is still possible for example to only show pins on a map for items that meet certain filter criteria set by the user.

Quarto

AstroJS

Collectionbuilder

https://collectionbuilder.github.io

Wax

https://minicomp.github.io/wax/

Dynamic Websites

Dynamic sites are websites that generate the static content that you end up seeing in your browser by asking a database on a server for information. So every time you visit a dynamic website, it needs to “build” the static files before your browser can download them. The main advantage of this approach is that it really allows the page shown to be adapted to the individual user (think your home page on facebook or x) and to be very interactive, every action taken by a user can make a change in the database and be reflected on the site by the next refresh rather than needing a redeploy as would be the case in static websites.

While dynamic websites are more powerful, this flexibility comes at a cost, they are more difficult to maintain, consume more resources making them more expensive to host and need closer security management.

The LAMP Stack

One of the most popular programming languages on the web is PHP. It is the language of choice for many open source content management systems and is officially supported by the VUB. Hosting environments that work for this language are often referred to as Linux, Apache, MySQL and PHP (LAMP) based on the typical technologie historically used to host php.

Depending on your level of expertise and needs we recommend 3 different technologies that work in this environment.

Paddle

The first recommendation is Paddle. This is a simple online software package (based on drupal) that makes it very easy to configure a basic website to share static content such as news, photo’s, information pages visually. This should be your go-to option for setting up simple websites for conferences, updates about research projects, advertising your research group etc. Researchers at the VUB can request a free paddle instance by contacting DICT.

Drupal

If you need more flexibility than the out of the box paddle installation provides you can consider switching to drupal. Drupal is still a Content Management System (CMS) aimed at allowing content editors to add new content and create new pages without needing to know how to write code. The flexibility of Drupal allows you to stick to a default theme where it makes sense, but if you are willing to learn or are a bit more technical it makes it easier to create new plugins or change some of the default fuctionality to create more of an “in-between” solution between the default paddle experience and a full tailor made website.

Symfony

If you need full control of the website and want to decide exactly what functionality is included and how it is shown it might be worth considering building (or hiring someone else to build) a complete custom solution. The VUB recommends the use of the Symfony PHP framework. Due to the high amount of work needed to implement a system from scratch, and most importantly maintaining the code as the project evolves, you should only consider this option if the functionality you need is not available in one of the pre-existing software platforms. The creation of tailor made server software is out of scope of this document, if you have questions about this you might be best suited scheduling a meeting with us so we can advise you before you proceed.

Python

While it is not a language typically used for developing web platforms, python is one of the most popular languages in the scienitific community. This is in large part due to the vast amount of free libraries and resources available for the language. For example in the field of Natural Language Processing python is quickly becoming the defacto language used for developing and sharing new solutions. As the B-TXT Digital Text Lab python would be our recommended language of choice if you are using NLP or AI techniques to enhance or interact with your content rather than sharing it. Some frameworks exist that allow you to use python to create a web application. In general it is more difficult to find hosting options for python code compared to php, so you should only consider this option if you are already using python for certain scientific computations or analysis, or have a lot of expertise in python over php.

Marimo + FAST API

If you are familiar with python notebooks (jupyter notebooks) to create visualisations/simulations you could look into Marimo to turn your notebook into an interactive web application that can be shared with other researchers. Multiple notebooks can also be bundled together into one interactive server by reading the documentation on embedding marimo in fast API.

NiceGUI

If you really need a more tailor made solution that caters to your specific needs, a custom application could be written in NiceGUI. NiceGUI aims to make it easier to build desktop applications (installable on the user’s machine and can be made available offline) and online interactive webapplications. It does so by abstracting away all the web specific details, allowing you to write the Graphical User Interface (GUI) logic entirely in python. NiceGUI keeps a logical representation of what is shown on the screen on the server, whenever a user interacts with the screen this event is sent to the server which will then execute code to react to the event. If the event causes any changes to the gui, nicegui will send these updates back to your browser so that your browser can update the screen. This approach makes it a lot more accessible to people fairly new to programming, and allows experienced programmers to iterate fast on prototypes but it also has some downsides. Applications made this way typically have a larger memory and compute footprint compared to more full-fledged client-server approaches, and scaling to thousands of users becomes more challenging. That being said, it is a great tool for building internal applications used by your local teams (e.g., between 2 and 50 users).

Online Exhibitions & Digital Storytelling