Following our previous post ‘Revamping Znuny: how we redesigned an Open Source platform to scale’, it is now time to delve into the development aspect of our journey and talk a little bit about some of the challenges and hurdles our team had to navigate through in order to bring functionality to our client’s newfound image, bred to life by our very own design team.
If you are interested in revisiting the complete design process overview, feel free to explore Part 1 of this series. Otherwise, and without further ado, let's dive right into the development journey.
Context Matters
But before really getting into our dev journey, whether you decided to jump right in and skip the previous post or not, here’s some quick and important info for context:
- Our client for this project, Znuny, is a distinct open-source ticketing platform that has been up and running since 2001
- We had the pleasure of working with them between 2021 and 2023, first redesigning their whole platform, and then putting it all into practice, working on deeply extensive code files, with the valued help and guidance of their dev and management team
Brief Technical Insights and Innovations
We embraced the atomic design principle to restructure the CSS class logic, promoting modularity and consistency across the platform. By breaking down the user interface into reusable components – atoms, molecules, organisms, templates, and pages – we laid the foundation for a more cohesive and maintainable design system (more on our previous post ‘Revamping Znuny: how we redesigned an Open Source platform to scale’).
This single design principle would later imply some major changes in code structure, bringing on comprehensive challenges.
Enter the Environment
We had our git access, our plan and our FTP connections all set up and ready to go.
At a glance, our main challenges presented as the following:
- Very deep, very extensive and very numerous code files
Which was to be expected somewhat, given how deep the platform runs. There were many pages, modals and screens to work with.
In the case of CSS files for example, we are talking about an average of 2000 lines of code, sometimes going as high as 3800 (for a single file). If this isn’t a testament to our client’s senior presence in the web, I don’t know what is.
Indeed, there was a lot to organize, and as we continued with our efforts, we uncovered more and more challenges.
Navigating Complexity and Constraints
Central to our challenge was understanding the underlying structure of our client’s system, particularly its reliance on the concept of "Widgets" blocks.
These Widgets served as the building blocks of customization, offering users a high degree of flexibility in tailoring their experience. By accessing the user settings page, users are able to enable or disable a wide range of widgets, as well as installing third-party plugins.
(And by the way, here’s the final, fully-functional version)
Simply speaking, you can think of these Widgets as a superclass which extends multiple types of widget children, each with its own unique functionality and structure, and, in some cases, unique class names as well.
This concept constitutes the very foundation of our client’s platform structure, which has been so since its early development. It is something that is intrinsic to its functionality that it cannot be so easily changed without risking breaking the entire system, therefore it was necessary for us to keep this logic in mind at all times while doing our work (both in terms of design and development).
Every window-like element you see is a widget, but this is where it gets tricky:
Despite every widget having the same parent container logic, that’s about where the consistency in structure stopped.
Visually speaking, every widget looked and behaved like an individual block. Which is great, it’s very much in line with our particle system. However, after looking deeper into the content organization, we found a lot of structures that were not standardized. Almost every widget had unique containers and classes (which in retrospect explains at least in part why CSS files were so large).
We were aiming for a solid, highly unified system that was to be as simple as can be, avoiding unnecessary exceptions in both style and structure, thus making it easier for our client’s team to easily create and manage their platform.
Most of the time we weren’t just reusing CSS selectors and updating stylesheets. Despite preserving all of their original features and functionalities (though we did add some new ones), there were always tweaks here and there to be made, buttons that had to be replaced, fields that had to be added, etc.
We were building something new on top of something that already existed and had to be preserved, and these were the rules:
- Any CSS changes were allowed;
- Most HTML changes were also allowed so long as they followed the Widgets logic;
- We could add new classes as we saw fit;
- Most of their original classes and class combos had to be kept and could not be changed in the slightest, as a lot of them were referenced in several .js files, and the removal of which would inevitably imply loss of functionality;
- JS files were so interconnected that we rarely could change them, except for very small tweaks and new code additions (like the nav bar hide and reveal feature which we added, for example);
But before all this, there was a considerable amount of cleaning up to do.
Cleanup
As previously mentioned, pretty much every CSS file had a good number of lines of code, and some files were organized in terms of the page they connected to, others referred solely to a particular widget or feature. Since we were reorganizing everything under a similar but essentially different logic (again, particle system), we had to break it all down as much as we could, focusing on element-based modular styles rather than page-specific styles, generalizing as much as possible and reducing unnecessary exceptions to a minimum.
Also, the original HTML files included a lot of inline CSS, which we also cleaned up.
Variables are your friends
We also added all kinds of necessary CSS variables to our root with standardized values for different padding sizes (sm, md, lg, etc...), colors, text sizes, among many others, to allow for easy and quick adjustments across the whole platform if (or when) necessary. In terms of colors, this was obviously an important necessity if the client later wished to add a ‘themes’ feature or a dark mode palette, for example.
…And so is Flexbox
Of course, we couldn’t have gotten this far without the mighty Flexbox, which provided us with the necessary flexibility that worked so right with our Widget particle system, and saved us a lot of time and struggle with mobile and tablet views.
Leveraging the flexbox model empowered us to create dynamic layouts that seamlessly adapted to varying screen sizes, enhancing the platform's responsiveness and user experience.
.png)
Final Thoughts
In conclusion, the journey of revamping Znuny’s OTRS platform was a challenging yet rewarding experience for our development team. By embracing the atomic design principle, navigating the complexities of our environment, and implementing strategic cleanup and organization strategies, all the while working with Znuny’s dedicated team, we were able to elevate the user experience and create a more cohesive and maintainable design system.
Through careful consideration of unique structure and requirements, we were able to enhance platform functionality while preserving core features. By leveraging CSS variables, Flexbox, and other modern web development techniques, we were also able to improve responsiveness and user interaction, ultimately delivering a final product that aligned with our client’s vision and goals.
The journey may have been filled with challenges, but the end result speaks for itself - a revamped platform that not only meets the needs of Znuny's users but also sets the stage for future growth and innovation.
