Skosmos 3.0 Roadmap
The current major version of Skosmos, 2.0, was released in August 2018. The current visual design was created with the help of Hahmo Design studio in 2014, in time for the Skosmos 0.4 release. The frontend and backend architecture is even older, dating from the early days around 2011-2012, when the codebase was created at the SeCo research group and was called ONKI Light. In more than 10 years, the application has grown and gained new functionalities as well as accumulated technical debt. We believe it is time for an architectural refresh especially on the frontend side. The visual design is also starting to look a bit dated, it is limiting the implementation of new features and better accessibility, and it does not work very well on mobile devices, so a redesign is sorely needed.
Skosmos currently follow a quite traditional server-side Model-View-Controller architecture for web applications. The Model classes (in PHP) rely on data from the triple store (usually Fuseki). Most HTML code is generated on the server side using Twig templates, but some dynamic functionality has been implemented on the frontend side with JavaScript libraries including jQuery, jsTree and Typeahead.js. Skosmos is clearly not a single page application, but there are some partial updates; for example, when clicking on concepts from the alphabetical index or the concept hierarchy, only the main area contents (with concept information) are changed instead of performing a full page load.
There are several benefits to this approach:
- Server side HTML generation is a well established paradigm and relatively simple to understand. The Twig templates can call Model methods directly. Page generation is generally fast nowadays, after many performance refinements.
- State handling is simple. There is no server side state, for example in sessions. All client side state that needs to persist across page reloads (mainly language choices) is kept in cookies, but these are only used by JS frontend code. The HTML code for a particular URL is always the same (unless the vocabulary data has changed), which simplifies caching a lot and makes it efficient.
- As the main information on Skosmos HTML pages is generated on the server side, it is readily available for non-browser agents such as search engine bots. There is no need to interpret JavaScript to get access to the most important content. This also brings good accessibility for non-traditional browsers, including text-based browsers such as Lynx and w3m.
We would like to keep these benefits. However, there are obvious downsides that we want to address as well:
- The JS code is quite messy and relies too much on DOM surgery performed via jQuery calls. Most JS code is stored in two large files, of which docready.js has bloated beyond its intended use. There is no principled way (for example defined UI components) of performing partial page updates, which has often caused bugs.
- Many JS libraries we use are old and unmaintained. We have upgraded or replaced some of them, but there is still major tech debt in the JS area. In particular, the Typeahead.js library needs to be replaced, but the whole jQuery style approach is questionable.
- The Twig templates have also grown organically. Their structure is not ideal and there is some duplication, for example the sidebar navigation. The naming conventions of the hierarchical use of the twig templates are such, that it's not clear which template is included in which.
- The HTML and CSS code has become more complex over the years. CSS files just keep growing and it's likely that many rules have become unnecessary, but we don't know which ones!
- Customization of the Skosmos instance has been handled via .inc -templates, plugins, and used-defined CSS. Currently, some of the user-defined JS code has been in footer.inc. There should be another, dedicated way for including custom JS code.
The main goals for Skosmos 3.0 are:
- Rebuild the frontend implementation practically from scratch, but keeping most HTML code generation on the server side. There should be new Twig templates, a new JS framework (see below) and a new visual HTML+CSS layout. As part of this:
- organize the Twig templates so that it is easier to see what is shared, what is inherited etc.
- redesign the HTML and CSS, based on a new look (designed by Hahmo), with modern, mobile friendly code (but not a separate mobile UI)
- organize the JS code in a sensible way, avoiding global variables (probably there should be a SKOSMOS object/namespace instead)
- make it possible to override parts of the JS code without resorting to the footer.inc trick currently used in Finto.fi
- Keep the PHP backend mostly intact. Only change what has to be done to support the new frontend and to stay up to date with new PHP versions and libraries.
- Adapt all Skosmos plugins as well as Finto customizations to support the new frontend.
On the backend side, we will still use PHP 8.x (dropping 7.x support) and Twig templates. Backend (PHP) dependencies will be managed by Composer. We will use PHP-CS-Fixer to manage PHP code style.
The frontend will be rebuilt. We will still use Bootstrap CSS for layout. Partial page updates will be handled by Vue.js JavaScript framework (version 3), replacing jQuery. Frontend (JS, CSS etc.) dependencies will be managed using npm. We will use StandardJS to manage JavaScript code linting and style.
To handle REST API calls, we will most likely use Axios. Internationalization on the UI side may require a separate JS library such as i18next or FormatJS. For UI components such as the hierarchy view and concept mappings, other libraries may be needed.
- Landing Page
- Global Search Results
- Vocabulary Home
- Vocabulary Search Results
- Concept Page
- Error Page
- About Page
- base-template.twig
- .twig (e.g. vocab-home.twig)
- .inc files
- .twig (e.g. vocab-home.twig)
