Progress compared to project calendar
The goals for this milestone were:
- A first draft of the GUI (Graphical User Interface) and its features are implemented. The general structure stands and can be easily extended.
- Though the GUI looks quite ugly at the moment, many of the required functionalities (as choosing the correct year, drawing, insert text, etc.) are already implemented. The biggest missing part is to save inputted data to the database.
- Our predecessor’s data has been inserted into Olivier’s database, such that we have frontiers to work with.
Both of them have been reached (see “Intermediate Results”). As opposed to the start of the project, where we had to readjust all the time, it feels good to be on a smooth path now and to clearly see the final goals (see “Next Steps”).
Finding an intuitive Website User Interface
During the design process of the GUI, we tried to imagine the workflow of historians when they are using the website.In a first scenario, the historian might have found an interesting object, say a church, and wants to follow it through all of its history: He starts with exploring the building’s shape at a certain time and then wants to jump in time to the next step of the building’s evolution, e.g. when a new tower was built.
For this case, we decided to include buttons that allow to browse through an entity‘s evolution, back and forth in time. The difficulty thereby is that one entity can become multiple entities in the future or the reverse, multiple entities can merge into one. In the example above this would be the case, if the existing church and a nearby lying existing chapel (two different entities) would be merged into a cathedral (one entity).
An other example, which is actually closer to our project’s topic, are frontiers: The frontier of a country is not saved as a whole, but is separated into border sections. (E.g. the frontier of Switzerland consists of the border between Switzerland and France, the border between Switzerland and Germany, etc.) Now, in case of a war, when countries annex land, it is easily imaginable that two border sections become one.
For the GUI this means that the relationship from one time slice to the next is not always clearly defined. In the cases where it’s not, a drop-down menu will appear offering all the possibilities.
A second scenario is that a historian would like to digitize an existing analogue source. He uses the slider to choose the right time and localizes on the map the entity he wishes to edit or the place where he wants to create a new entity. In the first case, he clicks the entity and then on the “edit” button in the appearing popup. In the second case, he clicks on the “create” button on the top right of his view.
In both cases a new window will pop up, where the historian can draw the entity on the map, enter textual information and the source where the information comes from. Finally he clicks the “Save” button for storing everything on the database.
The third scenario was that the historian has a mess on his desk, randomly chooses a source and an object to edit. Even in this case, the GUI will offer him an intuitive workflow.
Insertion of our predecessor’s data into the new database
- The GUI is functional: a user should be able to create and edit the lines of a frontier and skip forward/step back to the next entity or the next geometry of an entity. It works on our testing database.
- The code is documented, nicely formatted and ready to merge into master.
- We started preparing a showcase scenario for the final presentation: How would a historian use our tool?
- We started thinking about what to put on our poster.