Our team at the Digital Projects Studio is excited to present our web-based ‘field notebook’, designed with humanities and social science researchers in mind. We wanted to offer field researchers a reusable application with enough structure for ease of use but also with options for further customization according to individual needs. The main purpose of the application is to permit researchers to continually add digital objects, then retrieve and automatically group these objects in different ways as their field collections grow larger. Automated grouping is made possible by requiring the user to add some basic metadata to a digital object as soon as they enter it into the application’s database. The kind of metadata used can also be customized according to the user’s needs.
We built and packaged our application using Django. The name of the application package is ‘Django Field Notebook’, but we have also built a demo named ‘Monumental Gifts’ to showcase a customized, populated version of a digital field notebook. Furthermore, the demo also shows how the design of the Field Notebook is ‘responsive’–i.e., capable of re-sizing and rearranging the layout of its interface according to varying screen sizes (laptops, tablets, or smartphones).
The data stored in the demo ‘Monumental Gifts’ concerns monuments that were offered as ‘gifts’ from people in one country to the people of another. This blog post will review the features of our demo application. We will also explain how the particular ‘models‘ and ‘views‘ in the demo were designed (there will be another post on how to download and customize your own ‘Field Notebook’).
To get a better sense of what kind of value our web application is adding to the process of collecting and organizing field data, it’s helpful to be familiar with the capabilities of Django as a web application framework. Django is powered by Python and based on the model-view-controller (MVC) software architectural pattern. Simply speaking, views correspond to pages on a site with assigned URLS. Views comprise the ‘front-end’ of the application: the webpages that you, the user, will see when you open the application. Models are part of the ‘back-end’ of the application. Models manage data and define the logic of the application. How this logic is defined will be explained in more concrete terms below. For our purposes in this application, the controller can be understood as the ‘mind’ activating the views, dispatching URLS (based on regular expressions) to retrieve data from the models and automatically rendering that retrieved data on a webpage ( a ‘view‘).
To populate the demo, our team selected five monuments, each of which was associated with a creator and two countries (the country where the monument was created, i.e., the ‘giver’, and the destination country, i.e., the ‘receiver’). We then created three models: Country, Creator, and Monument.
The screenshot above shows the code for our three models. These models determine the rules and relationships for all the data we entered into the application. From looking at the code, you could guess the fields that appear on the projects ‘admin’ site (the secure site behind the scenes of the application, where you can log on and enter new data to be displayed in the notebook). You can think of each model as a table; you link tables via Foreign Keys, so you don’t have to repeatedly enter the same information.
Since the monuments gifted from one country to another are the main focus of the application, we added the most metadata fields to the ‘Monument’ model. The models for monument creators and countries associated with the monuments are very simple by comparison; each one basically only requires a name to be entered. Every creator also needs to be associated with a country. Every monument, on the other hand, needs to be associated with a creator and two countries (a giver and a receiver).
Once the three models were in place and ready to receive data entries, it was time to implement the structure of the website’s front end: how the template views of our online field notebook would appear as well as how they would be linked. Again, the purpose of the application is to facilitate lookup of monument data by monument, creators, and countries.
There are therefore three ‘indices’ in the application: a monument index, a creator index, and a country index. Each index has its own page. You can navigate to any one of these three main indices by clicking on the navigation bar. If you want to look up a monument by its name, click on ‘Monuments’, and Django’s controller will render a list of all the monuments that have been entered in the Field Notebook. Click on a monument name, and the controller will render that monument’s ‘detail’ view, which will show you a picture of the monument, metadata for the monument, and any notes or descriptions that were entered about that monument. An example of a detail view is shown below:
If you want to see the creators or artists whose works have been entered in the notebook, click on ‘Creators’ and a list of all the creators in the system will appear. When you choose a creator, the controller will render a page with a list of all the monuments in the notebook that the creator made. You can then click on any monument in the list to see that monument’s ‘detail’ view.
Finally, to look up monuments by country, if you click on ‘Countries’, you will be directed to a page that will present you with a list of all the countries that have been included in the notebook via an association with a ‘monumental gift’. When you click on the name of a country in the list, you will see a new page with two lists: (1) Monuments given by that country, and (2) Monuments received by that country. You can then click on a monument name in either list, and see that monument’s ‘detail’ view.
While the idea behind the notebook is simple, our intent is to provide humanities field researchers with an application that is simple and easy to use for storing and retrieving digital artifacts, as well as for gaining insights into how artifacts are related. There is added value in being able to look up monuments according to creators or countries: you can immediately see how different sets of monuments can be grouped together.
Our hope is that this demo will help researchers recognize the potential of the Field Notebook for use in their own research projects. The models could be modified to fit the context of another project, while the idea of having a digital notebook to store and automatically group digital objects under different aspects would remain the same.
If you haven’t already explored the ‘Monumental Gifts’ demo on your own, please click here and have a look! If you are interested in customizing the ‘Field Notebook’ for your own project, or building a similar application from scratch using Django, the following post will provide some guidance.
One thought on “Introducing “Monumental Gifts”: A Web-based Field Notebook powered by Django”