Navigation TOD: retrospective

Over the last five months, the Theory on Demand Team has been working on developing an online reading platform for academic articles. The project task involved adapting the already existing print and static content of the INC’s ‘Theory on Demand’ series onto the digital screens, more precisely, creating a fully digital version of the book, making use of the advantages and the possibilities of the web-page format.

The project has now finally come to an end, and we have presented it publicly on Thursday 28 January. Of course, there are still some things that could be modified in order to make it work better and smoother, but all things considered we are very satisfied with its final form, as was our audience. Let us take one last retrospective glimpse at the project, and observe the development period and the challenges we have had.

The origin

At the beginning we had to decide how we wanted to interpret the task of ‘redesigning’ the “theory on Demand’ series of publications. Without much hesitation, the team unanimously agreed on designing a website as the current hybrid publishing workflow at the INC was missing such a branch. Redesigning the publications by changing merely the stylistic elements such as the font, the colours and the layout options seemed like an easy and unimpressive alteration. Our idea was to transform the design, rather than just outfit the content in different garments. At the end of our assignment, we would have another format, which would consist of a blend of traditional content and rules together with the ones added by the digital medium and the web-page format. Therefore, we put our efforts into finding ways to represent academic print-based elements, such as footnotes, headings, table of contents, bookmarks etc. as digital counterparts. These would at the same time be used in an effective way, so that the navigation and the browsing of information on the website is facilitated.

CMS or from scratch?


After some consultation, we chose HTML. Source:

Our progress was relatively slow at first, as we had to familiarise ourselves with the tolls and the methods necessary in order to create a website we had in mind. One of the first dilemmas regarding the website was whether it should be constructed using a CMS such as WordPress, or should it be built from scratch and carefully assembled by. After some discussions and conversations with people with previous experience in such field, we concluded it would be wiser and safer to built it ourselves from the beginning, in order to have bigger control over our work.

Git conflict

Once we started building parts of the webpage, we needed input from the actual users of such websites, which lead us to creating a survey in order to collect information about people’s reading preferences. Having obtained that, we concentrated on implementing some of the desired features onto our website. However, we noticed that having two people simultaneously working on a single website could be more complicated than we expected.


These notifications were definitely not welcomed with joy and exaltations

We put our project on GitHub so that we could easily synchronise the changes that one of us made. Yet, this would sometimes increase the amount of problems and incongruences than it would solve. Since we worked on the same files, these would sometimes have two different versions at the same time, which could cause conflicts and loss of data if not solved properly. We were not too familiar with the git technology, and, in the initial stage, we had to rewrite some parts again, because we did not manage to solve the conflicts in the correct manner.

Responsiveness and race with time

In the final stage of our project we noticed that or website does not appear ideal on smaller devices. Structurally, the web platform we created was appearing relatively well as we had organised it using bootstrap framework. However, some other functional features, such as the ones depending on mouse as opposed to touch events, and landscape/portrait layout orientation still needed some attention. For instance, the hover event needed to be expressed differently on touch devices, which do not have such option, as well as some other desktop-specific events. Our website had a lot of text content, and our goal was to organise it logically and without distractions on the screen. This worked relatively simply on bigger screens, but on the smaller ones it proved to be a sizable obstacle, especially if one wanted to keep all the content present without eliminating any information. In the end we had to compromise and trade amount of information for readability and clean design.

Lastly, the final revision and organisation (and re-organisation) of the code took longer than we expected, and the concluding two weeks of our project were a bit hurried. Sadly we were forced to leave a couple of features working but not completely realised as we had imagined.

We have learned a lot from this project and we hope it will be taken on again in the future. It looked and still looks promising, and working on it was exciting and fulfilling.

We hope we will be able to give you an update very soon! Until then!

Tags: , , , ,