Building the New PZU Portal: A Front-End Developer's perspective
PZU’s new online service is the largest portal project in e-point’s history. For 12 months, it kept a team of programmers, testers, UX designers, project managers, architects, and content managers busy.
I’d like to share a front-end developer’s perspective on the challenges and outcomes of this project. How did we build a coherent, transparent, user-friendly service that can easily be edited by PZU’s personnel?
Why e-point CMS?
The PZU portal is based on 70 components, including 53 new ones that were designed specifically for this project. We employed e-point CMS to handle the complexity of this portal. The PZU SA portal is a ‘living organism’ of high complexity. It consists of 700 pages, and content is added on a daily basis. It is crucial for PZU’s content team to quickly add news, present new promotional content and products, and generally edit the site without the help of our programmers or front-end developers. At the same time, though, the site needs to maintain a consistent creative line.
e-point CMS is based on components, i.e. elements which display content in an appropriate graphic form. Thanks to them, PZU editors need only enter content in corresponding CMS squares or upload content using integrated external systems. The content is presented in an appealing way that remains consistent with the entire portal and that automatically adapts to various screen resolutions.
Components are placed in containers which limit page width and handle the division of content into columns. In e-point CMS, a page may be divided into any number of columns. Editors are not constrained by a fixed page layout but can adjust it as they wish. This offers plenty of freedom to decide on the mode of content presentation; at the same time, it guarantees the new content will match the entire portal's look and feel.
Key 1: Consistency
Consistency is a key requirement for any successful front-end design. And a critical step in ensuring portal consistency is working out the underlying styles for the whole portal. The following values must be embedded in the code:
- Basic colors
- Fonts
- Font sizes
- Repetitive elements (buttons, text styling, frames)
Establishing these elements early makes it easier to create subsequent elements and ensures the visual integrity of the portal. Using predefined elements also helps editors later on, when they add new content to the site.
Another essential part of maintaining a consistent appearance is setting a basic page width. To do this, we first analyze what devices end users will use to access the portal, then we choose adequate width bands for the portal design to use while adjusting to various screen sizes. This can significantly improve the end user’s experience.
Key 2: Responsiveness
The PZU portal was built using the principles of RWD (Responsive Web Design), which means content is adjusted to the size of the device on which it is displayed. e-point CMS supports portals built with this technology. But how is RWD done?
First, all designed pages are set on a 12-column lattice, which is based on the Bootstrap 4 framework. A 12-column layout makes it easy to divide the page into two, three, or four columns of various sizes, and the division can easily be made in the CMS panel. The columns are defined in such a way that their content will be visible and accessible on any screen size.
Page components – not just the page layout – are also responsive. Their design and behavior may differ on various devices. Content displayed on a desktop monitor as a row of boxes becomes a carousel on a mobile screen; carousels are easy to handle on touchscreen devices and take up less space than columns or rows of boxes. In the design process, any differences in the page view caused by screen resolution should be identified as soon as possible. This will facilitate the development of the project.
Front-end developers keep component responsiveness in mind when creating styles and writing JavaScript codes. Editors don’t need to worry how content on the site will be presented; all they need to do is complete suitable squares within the configuration, paying attention to prompts regarding graphics size or text length, and the component will be displayed correctly on all devices – even if this includes scaling the photos or changing font sizes.
Front-end developers style the component templates as well, which are later filled with content by the content editors. Frequently, both of these operations can be carried on simultaneously. The front-end developer must anticipate what kind of content the editor will choose and the space it will need; knowing this, the developer can design the components to ensure the content is always readable.
Technology and methodology roundup
The front-end development team which created the PZU portal comprised five front-end developers, two of which worked full-time on the project and three of which provided support as needed. This division of labor was possible because suitable tools were chosen for the job. One front-end developer acted as the project leader and was responsible for the choice of technologies and plug-ins and for implementing basic graphic elements; this developer also allocated tasks to the other front-end developers, supervised their work, and discussed proposed solutions with UX designers.
Styling the components was done using a SASS preprocessor, which allows developers to record repeating visual elements, colors, and fonts in a separate file and reference them by name during the project.
Each component has its own files containing styles and scripts and titled in accordance with the component name. These techniques enable the development team as a whole to move faster and also make onboarding a new developer easier.
Another methodology used in the project was the BEM (Block Element Modifier) methodology, which is based on creating modular CSS code. Its core advantage, apart from a flat code structure, is the encapsulation of styles inside a component. Using this methodology prevents styles written for different components from overwriting.
To achieve even greater code clarity and readability, several code-checking tools were used. Specifically, we used CSS linting tools to identify code syntax mistakes, impose correct formatting and embedding, and protect code coherence. These technologies supported our work pre-implementation, and they will facilitate future development work. Plus, they too will speed up the induction process for any new developers that may join our team.
Aside from choosing the right technologies, careful task analysis and allocation was a tremendous help to smooth cooperation between developers. We identified several areas that could be handled by developers outside the main team. These areas included personalizing components, designing and implementing template styles, and designing styles and implementing agents.
A note about Front-End Development
It should be noted that front-end development starts long before the first piece of code is written. It is crucially important to get to know the specifics of the industry for which the portal is to be created. It’s also essential to study any selected graphic elements at the mock-up/model stage. This pays off during the later stages of the project: it is easier to spot any divergence from the chosen creative line or to understand which elements may cause problems during implementation.
Each new project presents a front-end developer with new challenges and allows them to implement new solutions. All tools and techniques employed in designing a portal should ensure its consistency and modularity. They should also lower the entry barriers for new developers. The practices which work become part of your proven repertoire and can be applied to future projects.