We’re sure you’ve already had a look at the new and improved XING. Internally the production phase was called X4L as the end product represents a major overhaul of our platform. Our User Experience team took the various feedback we received and extensive user testing we carried out and used them to come up with a new design that also helps to improve usability. The front end team is the last piece in the XING puzzle as we implement the items that our customers actually see in their browser.
The redesign of our site was a welcome opportunity to change our front end architecture from the ground up. Here, I’d like to talk about the steps we all took to arrive at the new XING that was released on June 6. On top of that, we also made the necessary preparations so that we can easily implement the features currently in the pipeline. As a result, we’re ready for the future and new features can be implemented with little effort simply by adding new classes (see below).
Spring clean
When working on a site as comprehensive and complex as XING, you have to bear in mind that it’s growing all the time. Various people are busy producing agile code with releases taking place every Wednesday, meaning that time is everyone’s biggest enemy. Our HTML, CSS and JS files are growing all the time in our efforts to beat the clock with people generally writing data from scratch rather than taking the time to see if it already exists elsewhere. Our X4L project gave us an opportunity to give this process and the data a much-needed spring clean, the first step being to empty all of the CSS files while initially leaving the HTML untouched. The CSS emptying process and several other items (such as developing the grid used as a basis for pages) were carried out during a “preparation camp”. Then it was time to raid the snack cupboard, close the door, and get to work in the editor!
During the initial stages we split templates with each page consisting of a main template and, often, several partial templates. This way, each main template used in X4L is split into a content and page section in order to form the basis for the upcoming page “Ajaxification”. To make this split possible, each template already in use had to be modified.
Pattern library
As the well-known saying goes, “too many cooks spoil the broth”. Here at XING, it’s more a case of a lot of cooks each adding a few spices to the “XING dish”. As we all know, there are many ways of building something in HTML and CSS, so to avoid duplicates, accumulations and overlapping, we came up with a pattern library.
As the majority of the individual page designs were already available to us, we were able to analyze them and identify any recurring patterns. Any slight differences that cropped up were ironed out together with the User Experience team by giving them parameters to work with. The idea behind this was to make sure that we avoid using thousands of different variations for the very same feature. After that, we set to work on creating the patterns. The main benefit for everyone involved is that once a library with reusable patterns has been set up, all you need to do is copy and paste the pattern you need (put simply of course). By definition, patterns have to appear on at least two pages to ensure that they can be reused from a visual and engineering perspective.
OOCSS is used to create patterns which are then expanded by adding a class selector so they can assume other functions. The basic elements are always reused, which helps to reduce the amount of CSS required while also boosting performance. Here’s an example involving the lists used throughout the entire platform, in particular for marketing purposes. This is what the basic class looks like:
Lists
<dl class="arrow-lime"> <dt>Foo</dt> <dd>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</dd> <dt>Bar</dt> <dd>Aenean commodo ligula eget dolor. Aenean massa.</dd> </dl> |

If we now add, e.g. the medium class, the list then appears like this:
<dl class="arrow-lime medium"> <dt>Foo</dt> <dd>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</dd> <dt>Bar</dt> <dd>Aenean commodo ligula eget dolor. Aenean massa.</dd> </dl> |

And an additional big will make the DL look like this:
<dl class="arrow-lime big"> <dt>Foo</dt> <dd>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</dd> <dt>Bar</dt> <dd>Aenean commodo ligula eget dolor. Aenean massa.</dd> </dl> |

We have lists with checkmarks, arrows and bullet points in front of the text. We can use them on UL as well as on DL.
This is the (reduced) CSS only for the arrow lists. The other CSS specifications for checkmarks and bullet points have been stripped for the sake of readability.
.arrow-lime { line-height: 17px; margin-bottom: 25px; } .arrow-lime li, .arrow-lime dt, .arrow-lime dd { padding-left: 25px; margin: 0 0 10px; } .arrow-lime.big li, .arrow-lime.big dt, .arrow-lime.big dd { padding-left: 35px; } .arrow-lime dt { font-weight: bold; } .arrow-lime.medium, .arrow-lime.big { font-size: 14px; line-height: 19px; } .arrow-lime dt { margin-bottom: 2px; } .arrow-lime.big dt { font-size: 17px; font-weight: normal; line-height: 20px; margin-bottom: 3px; padding-bottom: 5px; padding-top: 1px; } .arrow-lime.big dd { color: #808080; margin-top: -5px; } |
In both of these examples (pagination and lists) we can see a basic set of CSS attributes used time and again in expanded form.
Creating a pattern library was a great help to the front end team as time is always against us. So by having a basic framework available for us to build on, we can code much faster than before. The library will be then turned into an online library once X4L has been launched.
During daily operation, we had to use old-school methods with X4L. What we mean is that patterns were saved in PDF files with images, a description, and HTML code so developers sometimes had to print them out and put them on their desk in order to work with them.
We also had a live overview of all patterns “in a natural environment”, i.e. integrated into our platform. A point worth mentioning here is that some patterns worked well on their own, but unexpectedly caused a conflict when used with other patterns. Any of our developers who spotted such a conflict then sent me a message so I could take action and modify the pattern (usually in the CSS). Anyone who had been using such patterns on a page up until that time without experiencing any conflicts generally didn’t notice the modification at all.
Buzzword patterns
Despite all the positive points mentioned above, there is a small drawback to this pattern approach. At one time, everyone at XING was talking about patterns as if it was the solution to every problem. If someone noticed that the front end developers in his team were experiencing a bottleneck, he’d say “We need a pattern to do that!” However, as mentioned above, a pattern is an HTML framework used on at least two pages so recycling only makes sense if you’ve got at least two pages. Everything else is just a matter of course for us front end developers.
Having said that, the bottom line here is that this approach is definitely beneficial. We can limit the amount of code in use which saves us time and, once the online library is in place, we can supply examples of visuals and code to select suppliers such as advertising agencies who build our microsites and therefore ensure consistency across the platform.
Figures
Here are a few figures showing the work we did prior to shipping X4L:
XING has more than 1,000 pages and page scenarios. There hasn’t been any change to this number as a result of X4L, it merely serves to illustrate the complexity of our work.
- We edited around 200,000 lines of code and deleted 10% of the existing code
- We deleted around 3,500 images
- We modified 2,000 files
- Our markup is estimated to have dropped by about 10%, but this is hard to quantify
- Up to 14 front end engineers spent up to 5 months working very hard to make the project a success (from a front end perspective)
Nils Lauk works as a Frontend Architect at XING. He loves semantics and accessibility. He's also a big fan of microformats.
Love the new front end does that mean you will also opening a new backend set for developers to build intergrate applications on?
Nice usage of HTML patterns… definitely saves time and less coding.
I remember having to clear up some code on a much smaller project once. So only have to take my hat off at you doing it on a much larger scale. Although I have to admit my project was a few years ago. After all it was coded in Pascal!
Pingback: IE6 is no more | Frontend | XING Devblog
Pingback: Great talks at the Developer Conference Hamburg | Frontend | XING Devblog