It started as a hobby. Help keep a project active while its main developer dealt with some real-life issues due to a natural disaster.

My first commit was on February 15, 2018. It was only to upgrade the version of Django used by Mayan EDMS from 1.10.7 to 1.10.8. That was it.

Based on my experience using Mayan EDMS for work, I started looking at the code to see if I could fix some other things. I found myself fixing APIs, writing tests and looking at uncompleted features the main developer had been working on. I was hooked.

Soon after I was joined by Eric Riggs. Eric uses Mayan EDMS as part of his 8–5 job, therefore he was knowledgeable about the code too. With Eric’s help and twelve days since my initial commit, we releasing version 2.8 of our Mayan EDMS fork. We called it Mayan EDMS NG (NG for next generation).

We became more and more thrilled by all the possibilities for improvements. We took the plunge, and we are now working on Mayan EDMS daily.

Two weeks after that initial release and here we are today, about to release a new version with some major improvements and changes.

We are very excited about this upcoming release. Here what’s new. I hope you get you excited too.

Turning Mayan EDMS into a single page app

Historically, Mayan EDMS has steered away from adding too much Javascript in its code. Roberto, the main developer often explains his rationale for this decision. His goal has been to maintain a robust, backend-based page rendering method that will be as future-proof as possible. This approach comes at the cost of some page loading speed, and reduced user interface interactivity.

The Javascript ecosystem is an untamed jungle of competing “standards”. Between JQuery, Angular, React, Ember, CoffeeScript, ES2015, ES2017, Babel, Grunt, Gulp, Bower, Webpack, Vue, Webpack, Rollup, Parcel, among many others, is easy to see why that approach was the correct one at the time. Luckily things have improved thanks to HTML5 and CCS3. The browser can now do many things that often required convoluted Javascript code to achieve.

One of the most common complains about the user interface is that it is slow, heavy, requires users to move around too much. That it requires “too many clicks” to achieve things.

Single Page Applications (SPAs) rewrite the current page dynamically rather than loading the entire page on each click of the mouse. This makes the web application feel and behave more like a desktop application. Because the majority of the styling and Javascript code is loaded only once, there is also the added benefit of less data down the wire. Thus the application becomes lighter and provides a faster response time to user events. Because the style is loaded and interpreted at the beginning, the browser is also able to apply it to the new content faster.

Example of the new page switching and rendering speed

In order to strike a balance with Roberto’s backend heavy philosophy, we stuck to using just HTML5 and jQuery. Aside from two additional jQuery libraries, there are no extra framework dependencies. With the conversion to an SPA, many other petitions for user interface improvements are now possible. We will work on these once the community confirms that all the user interface changes made to create the SPA are working as expected.

Upgrading to Django 1.11

The move to Django 1.11 proved to be a real challenge. Even though Django 1.11 is a minor release, it breaks compatibility and interfaces in several key areas. Among these were templates and form widgets.

Mayan EDMS uses a complex template, form and widget system. The system mimics object-oriented concepts like inheritance at the rendering stage. This allows the more than 300 views to be serviced with just a handful of forms classes and base templates. Testing and auditing all the views and forms after the upgrade was a lot of work. If any member of the Django project is reading this, please adopt stricter version numbering convention, something like Semantic Versioning.

Along with the upgrade to Django 1.11, we fixed many deprecations warning in preparation for an eventual upgrade to Django 2.0.

“A man wearing a protective helmet while welding metal materials.” by Christopher Burns on Unsplash

Notification improvements

In version 2.8 we introduced event notifications. These work by allowing users to subscribe to a particular event like Document Uploads or to an event of a particular document like when an invoice is edited. If these events occur, the user gets a reminder next to the bell icon in the main menu bar. This feature had one important limitation. The notification reminder would only update if the main page updated. That meant that if the user didn’t interact with the user interface they would not get a notification reminder.

We implemented a simple mechanism that checks for notifications periodically without user intervention. We avoided the use of webworkers, websockets and push notifications. The result is almost instant notifications without user interaction and without adding any extra dependencies.