Frontend objectives and characteristic features during the relaunch of sbb.ch
What Frontend-specific objectives have been the driving forces of your work?
The objective was to obtain a visually condensed, attractive, robust and accessible Frontend. The user interface was to be both high-performance and resource-efficient – irrespective of whether the user would use an older smartphone model or an end device equipped with a 5K display unit. The Frontend framework established by Unic was to ensure that the different channels would present a uniform look and a consistent interactive behaviour in spite of different release cycles and backend technologies. At the same time, it was to reduce the outlays for creating the basic barrier-free components.
The Unic’s Frontend Team has so far devoted over 1200 working days to the relaunch and further development of sbb.ch. What were the Frontend-specific features in this Project looking from your perspective?
The team size was certainly specific: at times, the Project Team consisted of up to six Frontend designers working on the WCMS site alone. Additionally, there were interfaces being maintained with the designers of the Webshop Team and of other peripheral systems. They continued the development work within their respective areas using the framework provided by Unic or were applying components of the basic framework as the starting point for their work. In order to ensure rigorous and efficient work progress in a team of this size, trust is needed as well as clear and open communication and a strong dedication to detail of all the parties involved.
The complexity of the Project is also reflected in the number of various disciplines, which were employed in the Project. How did the Project Team manage to have the different disciplines working together hand in hand?
Understandably, not everything was always running smoothly for us either. A project of this size and duration is subject to various factors, currents and changes, which cannot always be fully controlled with one’s own resources. Using the agile approach, we were constantly striving to put added value for SBB Customers in the centre of attention, and to align our work with that approach.
The constant on-site presence of the Frontend Team at the SBB’s premises has been the key element of the successful cooperation. The physical proximity and daily exchanges build, amongst others, the basis for a transparent, open and honest communication. This allows all the Scrum Team members at all times to critically scrutinise the decisions and to express their concerns.
At the same time, from the very beginning of the Relaunch Project, the Team was seeking and striving to employ active communication both internally and externally in order to engage all the parties involved in the Project as early as possible wherever possible.
Areas of conflict and challenges during the Project
What areas of conflict did you have to cope with during the Project?
Practically every person in Switzerland has an established opinion about what sbb.ch should look like and on its operation. Finding the right solution here was tricky: too many compromises would eventually please nobody. Finally, we decided to go for a forward-looking, progressive approach, which intentionally meant scrapping the old website. Of course, we knew all too well that this would polarise the opinions.
The second conflict area came forward at the interface between Design, Concept Building and Frontend Development: while the Design and the Concept Building would sometimes push the boundaries of the feasible, in the Frontend implementation we would more often decide for a more pragmatic approach as part of the agile development process. In this way, we managed to successfully tackle the cost/ benefit aspect and also maintain general stability of the project steps.
What were the biggest challenges during the Project from the Frontend point of view?
Our task was to unify the three existing sbb.ch websites based on a joint code. The goal was to ensure availability of all contents and functionalities on all sorts of end devices and for all screen sizes. Furthermore, in order to ensure accessibility for people with disabilities, the entire website needs to be operated with a keyboard and using a screen reader software. Implementation of this requirement requires a lot of expertise and experience. The differentiation of various possibilities of an entry alone can sometimes save some unexpected problems.
In order to deliver a possibly most resource-efficient but still attractive Frontend, on many occasions we had to reach deep into our ‘box of tricks’ and apply the latest browser APIs wherever possible. In browsers supporting the new Intersection Observer API, the clock shows up in the footer of the sbb.ch site only when it comes into the visible field. In this way, we avoid the unnecessary overload of the battery and the graphic card in mobile telephones.
The website contains multiple smaller and bigger performance enhancements, which are not noticeable to the user. The goal was to enable the upload of only as much information on each page as can be seen and absorbed by the visitor at a time. Even though we have managed that quite well already, we are still working on one or two improvements, which will be implemented in the coming months.
Ongoing performance enhancements for sbb.ch
You have made performance your key requirement in the Project. What impact did it have on your designer activity?
Initially, it was important to raise the awareness amongst all the Project participants as to why performance must be allocated such key importance. For those who do not deal with this subject on a daily basis, it may sometimes be difficult to understand at first why it is that investments leading to performance improvement by just seconds or milliseconds are considered worthwhile. However, thanks to the statistical data and tools (e.g. https://www.webpagetest.org/), so widely available these days and allowing for simple visualisation and comparison of the load behaviour, one can relatively easily explain the usage patterns of the respective interest groups.
In view of the possible application of http2 at a later stage, already at the beginning of January 2016 we pushed for a complete transition and encryption of all connections on the SSL for the purpose of the sbb.ch relaunch. Apart from that, we initiated a Content Delivery Network (CDN), which enables the usage of certain assets, such as SBB own Web fonts, by other channels and in other applications. In this way, the visitors can benefit from temporarily buffered data when surfing through the SBB Universe, while SBB can save itself some unnecessary data traffic.
Generally, we evaluate all new features from the performance point of view, and try to find resource-efficient and high-performance solutions. In consequence, in the course of the Project, we developed and applied the CDN mentioned earlier based on http2, together with brotli compression, different caching and speculative preloading mechanisms, asynchronous reloading of pictures and scripts, automated code splitting per page space and many other enhancements.
For a few months now, we have been actively monitoring the Frontend performance, and we are trying to improve it further with each release. In doing so, we often challenge the existing «Best Practices» using the latest knowledge, and we test solutions directly on the System. At present, we are working together with the Backend designers from One Inside on the integration of an external Image-CDN, which in the near future will deliver images to visitors in a more efficient and more optimised way.
Key requirement: Accessibility
The subject accessibility has a high priority at sbb.ch. How did you manage to integrate these requirements? Where did you encounter the biggest challenges?
Generally, Unic strives to design all its applications in as much barrier-free manner as possible. However, with a project of the size and complexity of the sbb.ch one, the challenges are quite different. The development of the operation function of the various screen readers has been a big learning curve for the designers, as it requires a lot of patience and empathy from them. Furthermore, experience is needed there to be able to tell what the expected output of the particular screen reader should be - especially as this can vary by browser- and screen reader combinations as well as by selected languages.
The common understanding of accessibility is that it involves obtaining the certification as this is a check point that must be passed and ticked off. Yet, in the agile development process, the product undergoes constant transformation. Numerous steps need to be taken between the Frontend development and the productive deployment – which will allow the room for errors. Therefore, if validation is applied for prematurely, one ends up with further re-validation applications being necessary after each step. For this reason, I do not think that certification is necessary at a specific point in time, but I look at the barrier-free accessibility as a requirement which is constantly present in the agile process.
In order to better respond to this situation in the future, a much wider support is necessary in the knowledge area. Achieving good accessibility requires teamwork, and this combines all the digital production roles from concept building through programming up to content creation and compilation. At the moment, in many cases, both the knowledge and the responsibility tend to rest too strongly on the shoulders of Frontend Development.
Agile Project Methodology
How has the agile project methodology impacted your work as FE developers?
Just as stated in the #unterwegsmitdersbb hashtag, together with the Backend designers from One Inside and the in-house SBB employees we are building a cross-company scrum team. The agile development process requires a lot of free space, engagement, transparency and trust of the involved designers and of the Management. The agile process provides us with the space to critically scrutinise the requirements from the customer point of view and to place the customer value in the centre of attention. It allows us to evaluate our work results with the stakeholders at short intervals, reflect upon our efforts and undertake the necessary adjustments. Only in this way are we able, the existing structures permitting, to continue our development both on the personal level and as a team.