Evolving Styling of Large Existing WebSite

As a mature Telco brand the website must balance consistency and improvements

Being on a modern Web-App focused project we had the opportunity to contribute a common styling code-base. Going from 2 to 13 projects sharing the styling exposed some of the challenges with real-world styling of large websites.

The Scene

Our Client a large Swiss telecoms provider was extending their web-site with an application for partners to order products for end-customers and had settled on Bootstrap CSS and Angular JS when I joined as a UI Specialist.

The starting point was the responsive breakpoints in Bootstrap which matched the layout in a sister project, but was different from the Adaptive styling on older projects.

The existing site design was made grounding in graphic design with no details about how to render the site on mobile devices. The site was made to render depending on the detected device, guessing between phone, tablet and desktop. As with other sites the challenge here is that you end up implementing multiple a complex mix of up to 3 separate websites. Day to day the design for tables is never considered so it just has to be made up, so it is really about making a desktop version and add variations where the phone should show something different.

What do you try to move forward, and where do you stay with status-quo as a new project.

The Choices

We created a common library to share styling and common visual components. It was made to be dropped into a web-page unmodified or be included as needed piece by piece by the projects that use the library.

Initially we shared the library with our sister project that used Bootstrap and Angular as well. As a single library to keep maintained and use as a single dependency it worked well. The expectations of what should be in the library or not we’re easy as the projects are similar.

After the application was implemented as responsive it was decided that consistency across the company website was the most important we had to change the layout to be adaptive. Since this was quite a change I added Sass mixins to our common library allowing the adaptive/responsive parameters to be configurable. This means that the library doesn’t dictate adaptive HTML attributes or responsive breakpoints. It turned out that the distinction compact vs regular layout is sufficient for the differences needed.

@mixin regular-or-desktop-only(...) {
    // styling rules

Is all you have to put in the application styling to provide special styling for tablets and desktops.

The default is an adaptive setup with classes applied to the documentElement(html). The values are phone, tablet, and desktop. An alternative configuration can be to set an attribute on the body instead. Or you can configure a compact breakpoint.

Initially we avoided browser specific targeting, but as in the old days we hit a snag with special behaviour on Internet Explorer. Following the usual solution we added the class ie to the documentElement.

The date picker is an example of something that has to be treated differently depending on device and web browser. On most mobile devices the native date picker is idea as it gives the best touch control. Unfortunately Internet Explorer doesn’t support the date input on Mobile so it needs a special case. On desktop browser you really wan’t a JavaScript implementation. So the implementation is picked based on the device, more on that later.

Common header and footers have a small amount of language specific text. We went for an approach that includes all versions within the HTML served and using CSS to show the correct one. The switching can be done with standard HTML language attributes leaving the easiest possible bundling of the components.

After an architect review the client decided to shift away from Adaptive to Responsive design. This led to some challenges,

Our current thinking of breakpoints is to break between compact and regular at a 480px width. While few phones are above 400px, there rarely is a better way to render in that grey zone.

Picking based on browser sniffing is well known as a bad idea, so the shift back to responsive is our opportunity to use feature detection. If the device is touch and supports the date type it should use the native control, otherwise it should use a JavaScript implementation.

The migration towards responsive means keeping the support for adaptive configuration around. Keeping both supported is an inherent overhead as, but migrating 3 projects at the same time is quite disruptive, so it is the better choice. The second reason is that projects can switch back to adaptive and keep using the latest common library functionality, one of the main points of using libraries.

One approach to support both adaptive and responsive styling would be to have two separate sets of styles which would double maintenance. When reviewing the fundamental rules it became clear that most styling is either layout which switches based on browser width or controls which switch based on touch/non-touch distinction. The pragmatic approach was to revise most differences to be on the touch/non-touch distinction and keep it common to responsive and adaptive. In the end the common styling needed around a week of development work to support the transition.

Using a common reset and scaffolding……. …

Interview questions

Would you split Oil-ui into smaller repos How do you find the framework free principle Should there be a common Angular library interfacing OIL UI for Angular projects As Swisscom moves to responsive layout should OIL Ui support adaptive and responsive letting projects decide? Should

Common Component Library Structure

Initially the component library contained full baked components usable from Angular. In retrospect that assumes that all projects will move to Angular. No transition or alternative frameworks are possible. There was no such policy. Future projects might use other frameworks.

Creating a single library means a battleground for ideas where all projects will submit their view of what’s needed, anything added is hard to retire and competing approaches are not possible. The forking principle [https://guides.github.com/activities/forking/] made possible by GitHub would allow for competing approaches to hash it out based on popularity and allow projects to pick the right solution at the time.


The Good And The Bad

Sharing at the library level vs sharing at the component level is a tradeoff. It is very hard to manage dependencies if individual components are changed. You can make tests for a library of all common components ensuring that they work in unison, but if the components are independent the incompatibilities between them will have to be caught in the app testing.

Keeping all translation texts for headers and footers in the HTML turned out to appeal to others implementing the subsequent style change, so it lived on.

The mixins for device specific styling were a useful shortcut, but it didn’t seem to stick with developers so we will keep looking for alternative ways to organise.

The overall lesson is that an existing website provides a strong force against adopting modern browser capabilities as consistency with the existing site is considered desirable, and the great cost estimate for making the improvement across all projects usually kill such ideas early. As a business you want to know what rate of change you want to strive for and clearly state it so projects can plan changes accordingly.

When big or difficult changes needed to be made to the common codebase a succesful approach was to hold full day open-source style sprints with a person from each project. It allowed quick feedback from everyone and by working hands on all day with 5 developers a lot of work was achieved.

Automatic ci build of forked libs, zro config libs….

TODO survey on what you are looking for in a case study