Before starting to build the frontend, I assumed that the biggest decision a tech person needs to make in a DH project is which technical approach to take to build the actual website/map/model etc. However, in the process of creating the webpage and seriously thinking about how I want to display the data, I realized that there are a lot more equally important decisions to make, and some of them can be tough. Therefore, in the reflection section of this website, I would like to focus on what decisions I made and I will try to explain why I made those decisions.
Technical approaches
As mentioned in the section Methodologies – Web Frameworks, the two web frameworks Django and Node/Angular both have advantages and disadvantages. Therefore, when making the decision of which framework to use, it is necessary to consider the project’s life cycle, project maintenance expectations, as well as current project needs. As for the Almanacs project, Node/Angular is apparently a more sustainable choice. First, as students continue to collect data from more years, unexpected data types or data formats may appear (either in almanacs that are too early or too late). As a result, the backend and the frontend may frequently need to be improved. If the backend and the frontend are separated, it is more convenient to make changes in either end without affecting the performance of another end than having them all messed together. Second, we can also publish the API and allow other web developers to use it to interact with the database in the ways they want. This can even be an instructive opportunity in a digital humanities class when teaching/introducing frontend development. Last but not least, since Angular is more specialized in frontend development, its webpage has more flexibility and interactivity than a Django webpage. Consequently, the Node/Angular framework is more ideal than a flat website.
How to display the data
How to display the data – or more specifically, how to name the data as it is displayed – is a big issue I have encountered when building the frontend. For institutions, for example, there are two possible options to display their name. One, to give each institution a generic name, use that name to represent the institution, and display each institution individually; or alternatively, to display the combination of institution and year, and display the institution’s name as it is in the almanac record. In the previous Django site, I chose to use the latter way of naming and representing the data. However, users cannot have a more comprehensive view of the metadata of a specific institution across several years. They can only browse one institution in one year at a time. This makes it very hard to really track the change in the metadata of the institutions throughout different years. Moreover, after discussing with Dave, Ashlyn, and Joanna, I realized that displaying the combination of institution and year is not very intuitive, and users may expect to be able to browse institutions (with unique instIDs) individually. As a consequence, in this new database website, I decided to make each institution with a unique ID as an individual entity, and name/represent it with the most up-to-date name in the almanac record. Even though each ID is represented by one single name, it is worth mentioning that in this database, a user is still able to search for an institution with its old names, and they will be able to trace the change of the institution’s name once they hit the institution detail page as well.
Other thoughts: about teamwork and working on the Almanacs project
I am very glad that I can work on the Catholic Almanacs Database and learn about web development as part of a large team. Having access to a huge amount of already collected and very neatly refined data affords me the opportunity to seriously think about how to name the data, how to design the backend structure, how to improve the website’s performance (for example, the speed of searching), and how to design the database in the most sustainable and reusable way (considering that the database will continue to expand in future years). Additionally, being able to discuss with others when making decisions is also highly helpful. As each person thinks of a certain issue from different perspectives, the decisions that we make collaboratively are always more well-considered.
What’s more, I really appreciate that I can work on a real DH project instead of just learning web development skills and playing with a small or impractical dataset. When building this database website, I have learned to be responsible for the data in terms of decision making – for instance, how to display the data so that most users can benefit from the website, and how to design the webpage so that it is as intuitive as possible. Apart from that, I also learned that there are always some unexpected scenarios that require me to redesign part of the data structure or add more functions to handle them. For example, I never expected that a church could split into two, or that two churches could combine into one. If we want the child church to show up in the search of the parent church, then we need to come up with an additional rule of assigning the instIDs and potentially think of a new function in the API. After running into similar situations, I knew better than before that a DH project always requests attention, care, maintenance, and improvement.
Acknowledgement
I would like to thank the digital scholarship group for all their instruction, help, and support. I would especially like to thank David Thomas for teaching me web development skills and for being so patient and supportive. I would also like to thank Ashlyn Stewart and Joanna Schroeder for being willing to share the data will me and for giving me so many wonderful suggestions on frontend design. It’s been such a pleasant journey.